Optimalizace rychlosti webu: Odmítáme neslušné HTTP požadavky

Emka — Sat, 14 Aug 2010 16:34:47 +0000

Každý soubor, který se použije při vykreslení webové stránky (obrázek, CSSko, javascriptová knihovna atd.) představuje jeden HTTP požadavek na server. Dle doporučení HTTP protokolu 1.1 by prohlížeče neměly vyřizovat více jak 2 tyto požadavky zároveň na jednom hostiteli. Současné browsery na to víceméně kašlou a vyřizují jich více. Pro účely tohoto seriálu budeme předpokládat 6 paralelních požadavků (tak je to u většiny současných prohlížečů). Pokud máte na stránce například 5 souborů s CSSkem, 3 javascriptové knihovny, 3 obrázky v HTML kódu a 4 obrázky nahráváte v CSSku, je třeba vyřídit celkem 16 požadavků (tím prvním je samotný HTML dokument). Ty se však nestáhnou zároveň, ale vyřídí se postupně. Nejdříve se začne stahovat prvních šest HTTP požadavků a teprve až první z nich doběhne, může se začít stahovat další. A zde se naskýtá prostor pro optimalizaci. Dneska si povíme konkrétní kroky, jak zvýšit rychlost načítání stránky prostřednictvím snížení počtu HTTP požadavků.

Ukázkový příklad před optimalizací

Začneme příkladem, kde si můžete ověřit, že jsem vám v prvním odstavci příliš nelhal. Zapněte si ve Firebugu záložku Síť a navštivte tuto ukázku. Pokud dáte na stránce reload (Ctrl+F5), měli byste dostat nějaký obdobný přehled HTTP požadavků na časové ose:

Jak vyřizuje prohlížeč HTTP Požadavky - příklad před optimalizací

Po načtení HTML dokumentu se vezme prvních 6 požadavků a začnou se stahovat. Na obrázku je vidět, jak soubory jquery-ui-min.js a script.js musí čekat, až se uvolní místo ve frontě na stažení dalších požadavků a začnou se vyřizovat teprve až doběhnou první dva z balíku předchozích šesti. Dále je vidět, že obrázky se začnou načítat až po načtení jquery.min.js. Toho si zatím nebudeme všímat, dostaneme se k tomu později. Po stažení následuje další balík 6ti požadavků na obrázky a tak poslední obrázek musí chvíli počkat. Tento příklad si pro porovnání ukážeme ještě jednou na konci dnešního dílu, ale už s provedenými optimalizacemi.

Optimalizace CSS

Nemusíme zrovna chodit do Mensy na obědy, aby nám došlo, kde s optimalizací začneme. Nejdříve všechny CSS soubory spojíme do jednoho (zvlášť pokud je stejně máme přilinkovány ke každé stránce webu). Jestliže používáte různé styly pro různá zařízení a odlišujete je přes atribut media, můžete specifikovat typ zařízení až ve spojeném souboru přes pravidlo @media. Vše si ukážeme na příkladu. Nejdříve původní podoba hlavičky před optimalizací:

Nyní spojíme všechny soubory do jednoho a nazveme jej třeba styles.css. Zároveň se vyhneme zápisu pomocí @import. V některých verzích IE tento zápis způsobí to samé, jako kdybychom připojili CSSko až na konec dokumentu. Stránka by se začala vykreslovat až po načtení tohoto posledního stylu a do té doby by na nás zela bílá obrazovka. Všechny CSS soubory tedy umístíme do hlavičky dokumentu a spojíme je do jednoho následovně:

Soubor styles.css pak bude vypadat takto:

@media all {
	/* obsah souboru general.css */
}

@media screen {
	/* obsah souboru screen.css a lightbox.css*/
}

@media print {
	/* obsah souboru print.css*/
}

@media handheld {
	/* obsah souboru handheld.css*/
}

Tímto jsme z pěti HTTP požadavků udělali jeden a máme první krok v daleké cestě za svištícím webem.

Nyní se podíváme do CSS souboru a provedeme audit toho, co obsahuje. Pokud používáte v CSSku obrázky na pozadí, vytváříte další HTTP požadavky na jejich stáhnutí. Dalším krokem optimalizace bude snaha o pospojování obrázků z CSS do jednoho.

CSS Sprite - ukázka

Tato technika se nazývá CSS sprites a vychází z Pixyho vynálezu Rychlé rollovery bez načítání. Dále se o ní můžete dočíst např. v článku CSS Sprites: Image Slicing’s Kiss of Death magazínu A List Apart. Vlevo se můžete podívat, jak takový sprajt vypadá třeba na Googlu. Všechny objekty, které vidíte na obrázku, mají tento sprajt nastaven jako svůj background-image. Liší se svými rozměry a nastavením pozice obrázku na pozadí přes background-position. Pravda, tato technika není zrovna jednoduchá na spravování a kodérovi může přinést trochu práce navíc. Zvláště pokud se web často mění. Riziko vzniká především tehdy, pokud budete muset změnit rozměry obrázku, který se nachází uvnitř sprajtu. Budete pak muset upravit nastavení background-position všem objektům, kterým se pozadí díky změně tohoto obrázku posunulo uvnitř sprajtu. Proto, než vytvoříme CSS sprajt, je dobré si vše pořádně rozmyslet a vytipovat vhodné kandidáty. Příliš se nespálíte, pokud vyberete obrázky, které splňují následující:

Mají fixní rozměry a obrázek je přes celý objekt – typicky logo, pozadí obrázkového hlavního menu, opakující se obrázkové nadpisy,u e-shopu tlačítka Koupit, fixní ikonky apod.
Často se opakují napříč webem (nemá smysl, aby si návštěvník nahrával dopředu obrázky, které se mu pak vůbec nezobrazí)
Je pravděpodobné, že se nebudou příliš měnit (jinak z toho buď zešílíte nebo začnete používat nějaký lepší nástroj než kalkulačku)

Použití sprajtů není omezeno jen na objekty s fixními rozměry. Vyzkoušejte si na svém webu šikovnou utilitku SpriteMe, která sama vytipuje vhodné obrázky z vašeho CSSka ke sprajtování a vygeneruje je včetně CSS.

Optimalizace Javascriptu

Zde platí stejně jako pro CSSka, spojte JS soubory do jednoho. Na rozdíl od CSS však pokud možno umístěte odkazy na javascripty až na konec HTML dokumentu před značku . Pokud bychom nechali javascripty v hlavičce, blokovali bychom stažení všeho co po skriptech následuje v těle stránky. Prohlížeč totiž neví, co je obsahem javascriptu a netroufne si stahovat další soubory, když to může být třeba zbytečné. Představte si, že by javascript obsahoval kód, který přesměruje stránku nebo přes document.write úplně změní DOM stránky. Toto vysvětluje čekání na javascript v prvním příkladu. Umístění skriptů až na konec HTML dokumentu občas nemusí být úplně jednoduché, ale pokud vytváříme web na zelené louce a není třeba přepisovat již funkční rozsáhlý web prošpikovaný javasciptovou nirvánou (nebo peklem), určitě bych tento přístup doporučil. Pokud musíte vkládat javascript v hlavičce dokumentu, dodržujte alespoň pořadí nejdříve CSS a až pak soubory s javasciptem. Co jsem testoval, tak Opera (10.60) narozdíl třeba od Firefoxu blokuje i stahování CSSka, dokud se nenahraje javascipt. Na Operu ani nezabírá umístění JS až na konec dokumentu. Pro pokročilé kodéry doporučuji prostudovat také zajímavou studii na téma nahrávání javascriptu javascriptem v článku Loading Scripts Without Blocking, případně LABjs – jednu z mnoha knihoven, která se na to specializuje.

Pokud si myslíte, že je pravděpodobnější, že spadne Váš web než Google, mám pro vás další tip. Jestliže používáte nějakou známou JS knihovnu, jako je jQuery, YUI, Prototype a podobně, můžete využít Google Libraries API. Zjednodušeně jde o to, že tyto knihovny netaháte ze svého serveru, ale ze serveru od Googlu. Knihovny jsou tam umístěny v různých verzích, stačí si vybrat tu kterou potřebujete a připojit ji do vaší stránky např. takto:

Toto má své výhody i nevýhody. Mezi výhody patří, že HTTP požadavek je na jiný server než váš, a tak se vyhnete omezení počtu HTTP požadavků ze stejného zdroje a stahování dalších souborů poběží paralelně. Další nespornou výhodou je cachování. Pokud Váš návštěvník již v minulosti navštívil některou stránku, která stahuje knihovnu ze stejné adresy, bude mít již při první návštěvě vašich stránek tuto knihovnu ve své cache a nebude si tedy muset knihovnu znovu načítat. Navíc knihovny jsou GZIPované a mají správně nastavené hlavičky – o tomto v dalších dílech seriálu. V poslední řadě také ušetříte nějaký ten kilobajt z provozu serveru. Nevýhoda je nasnadě: důvěřujete nějaké třetí straně, že vám do stránek naservíruje to, co slibuje, a ještě k tomu v nějakém rozumném čase. Dále vznikne určitá časová režie na vyhledání DNS záznamu.

Ukázkový příklad po optimalizaci

Nastal čas podívat se na to, jak dopadl náš ukázkový příklad po optimalizaci. Pokud se podíváte do zdrojového kódu, uvidíte následující změny: 5 CSS souborů bylo spojeno do jednoho stejně tak jako 3 soubory s javascripty. Vzniklý soubor s javascripty byl přilinkován až na konci HTML dokumentu. A nakonec 4 obrázky z CSSka byly spojeny do jednoho sprajtu a CSSko následně upraveno. Podívejme se jak to dopadlo:

Jak vyřizuje prohlížeč HTTP požadavky - příklad po optimalizaci

Jak je vidět, počet požadavků jsme srazili z 16 na 7. Ač časy nejde úplně srovnávat (načtení obou stránek s příklady proběhlo v jiný čas a za jiné konstelace hvězd), je optimalizace patrná na první pohled. V druhém příkladě se nečeká na načtení javascriptu, aby se mohly stáhnout obrázky z dokumentu. Zároveň díky CSS sprajtu a pospojování souborů, jsme ušetřili čekání na vyřízení balíku po šesti požadavcích.

Pokud jste dočetli až sem, zasloužíte si odměnu v podobě kontrolní otázky. Proč se v druhém příkladě soubor img_css_sprite.png nenahraje společně s ostatními v rámci jednoho balíku po šesti? Odpovědi zasílejte na adresu Studio kamarád, nebo je napište do komentářů.

Cachování a konfigurace hlaviček

Doposud jsme se zabývali optimalizací rychlosti pro všechny návštěvníky webu. Nyní vytvoříme pár optimalizací pro návštěvníky, kteří navštěvují váš web opakovaně.

Představte si, že poprvé navštívíte úvodní stránku nějakého webu. V ten moment váš prohlížeč vytvoří spoustu HTTP požadavků na všechny komponenty webu: obrázky, CSSka, javascripty a tak dále. Tyto komponenty si prohlížeč uloží k sobě na disk. Z homepage si následně odskočíte na nějakou podstránku, kde budou některé jiné obrázky a soubory, ale spousta jich bude stejných: logo, CSSko, obrázek na pozadí hlavičky apod. Byla by škoda znovu čekat, než se vyřídí opakující se požadavky. Proto existuje mechanismus cachování v prohlížeči, který umí rozhodnout, co nahrávat znovu, a co si vzít z lokální kopie na vašem disku. Abyste prohlížeči pomohli v rozhodování, je třeba správně nakonfigurovat Váš server, aby do hlaviček přidával některé další informace. To lze buď pomocí ETagů nebo nastavením časové platnosti. My se budeme zabývat druhým jmenovaným způsobem.

Nyní si ukážeme, jak bude zhruba probíhat komunikace se serverem při vyžádání si loga:

Prohlížeč se zeptá: Nazdar mašino, mám tu požadavek na stáhnutí loga. Žádné u sebe na disku nemám, jsem u tebe asi poprvé. Hoď mi zpátky to své úžasné logo. Server odpovídá: Jasně draku, tady ho máš s kódem 200. Naposled se změnilo Last-Modified: Fri, 06 Aug 2010 17:02:37 GMT. Ale tohle logo tady bude stejný ještě tak měsíc. Naštěstí si webmaster přečet jeden návod na netu, tak ti to posílám i s hlavičkou Expires: Tue, 07 Sep 2010 13:21:05 GMT, ať už se příště tak blbě neptáš. Za datum u Expires si dosaďte dnes + 1 měsíc.

Logo jsme tedy na úvodní stránce obdrželi a navštívíme podstránku. Prohlížeč si mumlá sám pro sebe: Hmm, mám stáhnout logo. Kouknu se k sobě na disk, zda ho tam mám. Á tady je, mrška. A platnost koukám má podle Expires ještě skoro jeden měsíc. Tak to už server nebudu otravovat, minule byl nějakej nabubřelej.

Jenže co se nestane, škodolibý uživatel stiskne F5 (pozor, ne Ctrl + F5) a vynutí si znovunahrání stránky. Prohlížeč se ptá: Nazdar mašino, tak jsem tu zpět pro logo. Mám ho sice u sebe, platnost má mít ještě skoro měsíc, ale co nadělám, šéf zmáčknul F5ku. Si snad myslí, že se ta rychlost udělá sama nebo co. Posílám ti to i s hlavičkou If-Modified-Since: Fri, 06 Aug 2010 17:02:37 GMT. Server odpovídá: Nazdar draku, a cos mu na to řek? No nic, kouknu do Last-Modified a porovnám to s If-Modified-Since. Hele, tak to vypadá, že se nic nezměnilo, posílám kód 304 Not Modified.

Takže takto zhruba probíhá komunikace mezi serverem a prohlížečem. Je třeba říct, že vedle cache v prohlížečích existují další možnosti cachování. Může se vám stát, že prohlížeč takto nebude komunikovat přímo se serverem, ale předtím ještě třeba s proxy cache ve vaší firemní síti. Pokud Vás toto téma zajímá detailněji, doporučuji např. článek Kešovací návod pro autory webu a webmastery. My se podíváme jak nakonfigurovat správně server.

Jak je vidět z našeho zachyceného dialogu, ideální stav pro snížení počtu HTTP požadavků je monolog prohlížeče, kdy se serveru vůbec na nic neptá a vezme soubor přímo ze své cache. Toho docílíme správným nastavením hlavičky Expires. Předtím je třeba si ujasnit, co a jak budeme cachovat. Určitě obrázky, flashe, zipy a další soubory. Ty se na webu obvykle často nemění a můžeme jim nastavit expiraci např. za 1 měsíc nebo ještě později. Podle specifikace HTTP 1.1 by expirace neměla být nastavena na více jak jeden rok (i když je toto doporučení často ignorováno). Javascripty a CSSka už se mění častěji a tak dáme expiraci třeba 1 týden (pro účely ukázky). Naopak HTML dokument cachovat nebudeme.

Různé webservery mají různé způsoby konfigurace, my si ukážeme jeden ze způsobů, jak si nastavit Expires hlavičku pomocí .htaccess souboru na serveru Apache s nainstalovaným modulem mod_expires:


ExpiresActive On

ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/jpg "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType application/x-shockwave-flash "access plus 1 month" 

ExpiresByType text/css "access plus 1 week"
ExpiresByType application/javascript "access plus 1 week"

Pokud upravíte CSS nebo soubor s javascriptem a chcete, aby se všem návštěvníkům nahrál znovu, pomůže soubor přejmenovat. Můžete do názvu souboru inkrementálně zvyšovat jeho verzi např. styles_v001.css. Jiným řešením může být přidání parametru s verzí CSSka za název souboru např. styles.css?v=001. Avšak zde hrozí, že takovou URL s parametrem na konci můžou některé proxy cache ignorovat. Na druhou stranu je verze s parametrem daleko snadněji spravovatelná.

Co se jinam nevešlo

Ohlídejte si, aby se na stránce nevyskytovaly požadavky na neexistující soubory. Ať už jde o obrázky v dokumentu, špatně zadanou cestu k obrázku v CSSku atd. Dokonce i když můžete mít vše v pořádku, prohlížeč občas požaduje neexistující soubor. Typickým příkladem je Opera, která hledá soubor favicon.ico i v případě, když jej v dokumentu vůbec nelinkujete. Je proto dobré faviconu vytvořit či alespoň nahrát na server prázdný soubor favicon.ico.

Dříve už jsem naznačil, že počet paralelně stahovaných souborů lze zvýšit, pokud soubory taháme z jiného hostitele. Teoreticky bychom mohli např. 6 obrázků umístit na i1.example.com, dalších 6 na i2.example.com a mohli bychom všech dvanáct vyřídit zároveň.

Použité zdroje a další počtení

Mekkou všech návodů jak zrychlit web je jednak Page Speed od Googlu a Best Practices for Speeding Up Your Web Site od Yahoo!, kde také naleznete YUIBlog s články na toto téma.

Obě společnosti spojuje jméno Steva Souderse (pozor, to není ten z Beverly Hills 90210), autora knih High Performance Web Sites a Even Faster Web Sites, který byl do Googlu „draftován“ právě z Yahoo!. Na jeho blogu najdete spoustu zajímavých výzkumů a mimo jiné i nástroj Cuzillion, ve kterém lze provádět různé hrátky s HTTP požadavky a testovat je v různých prohlížečích. Pravda je, že nástroj se občas choval podivně a nevracel mi úplně stejné výsledky jako v ukázkách z tohoto článku. Například zde jsem se pokusil nasimulovat podobné podmínky, jako v úvodním neoptimalizovaném příkladu, ale vůbec tam není vidět čekání na nahrání javascriptů – ještě to budu muset prozkoumat. Pokud si hrát nechcete, ale chtěli byste mít pohromadě hotové výsledky měření, jak se různé prohlížeče vypořádají s pořadím požadavků, kolik jich zvládají najednou a podobně, doporučuji web Browserscope, převážně záložku Network.

Závěrem

Tak jsme dospěli na konec dnešního dílu. Pokud máte nějaké dotazy nebo jste v článku nalezli nějaké chybky či nepřesnosti, pište do komentářů. V příštím dílu se zaměříme na optimalizaci prostřednictvím zmenšení objemu přenášených dat.

Optimalizace rychlosti webu: Úvod

Emka — Sun, 08 Aug 2010 21:40:47 +0000

V tomto seriálu představím několik tipů, jak si zrychlit webovou prezentaci. Nebudu se zabývat optimalizací výkonu z pohledu programátora aplikace, ale hlavně z pohledu kodéra. V jednotlivých tématických blocích si představíme konkrétní kroky, po jejichž následování bude váš web svištět viditelně rychleji (pokud nemáte stejně loudavý hosting jako momentálně já).

Proč je důležité, aby se vaše stránky načítaly rychle?

Zvýšíte uživatelský komfort svých návštěvníků
Optimalizací snížíte objem kilobytů provozu svého webserveru
Můžete si trošičku šplhnout u Googlu, který zahrnuje rychlost načítání stránky do svého algoritmu při řazení stránek v SERP

Nástroje optimalizace webu

Než začneme s optimalizací, je dobré si představit nástroje, které nám s optimalizací pomůžou. Předpokládám, že Firebug netřeba představovat a pro kodéra by to bylo nošení dříví do Athén (nebo sov do lesa). Zde nás bude hlavně zajímat záložka Síť, která ukazuje průběh načítaní stránky včetně jednotlivých HTTP požadavků. Pokud uctíváte jiný prohlížeč než Firefox, najdete obdobné nástroje i u nich. V Chrome jsou to Nástroje pro vývojáře, záložka Resources. Nebo si pro tento prohlížeč můžete stáhnout ultimátní rozšíření na ladění výkonu SpeedTracer. Opera zas nabízí Opera Dragonfly (Ctrl + Shift + I), záložka Připojení. Pro Internet Explorer můžete použít aplikaci HttpWatch, která je ve své základní verzi zdarma a kromě IE existuje i pro Firefox.

Dále si nainstalujeme dva pluginy do Firebugu: YSlow od Yahoo! a PageSpeed od Google. Oba pluginy ohodnotí stránku na stupnici od 0 do 100 z hlediska optimalizace výkonu a sdělí doporučení, co ještě vylepšit. Dále obsahují rozličné utilitky, které nám při optimalizaci usnadní práci.

Posledním nástrojem, který budeme používat, jsou Google Webmaster Tools. Pravděpodobně je již dávno používáte a pokud ne, tak je vřele doporučuji. Dozvíte se z nich spoustu užitečných informacích, jak Google vidí vaše stránky a pokud se zajímáte o SEO, stanou se vaším věrným pomocníkem. Z pohledu optimalizace rychlosti nás však bude nejvíc zajímat záložka Laboratoř Google > Výkon webu:

Google Webmaster Tools - Graf výkonu webu

Na grafu uvidíte, jak rychle se v čase načítají vaše stránky v porovnání s ostatními weby. Pozor, na vertikální ose je průměrný čas potřebný k načtení stránek v sekundách, tj. čím menší tím lepší. Data si Google nesbírá z údajů svého robota, ale od lidí, kteří mají nainstalován Google Toolbar se zobrazením Page Ranku. Stránky ohodnocené jako rychlé se načítají pod 1,5 sekundy. Tam někde se budeme pohybovat po skončení seriálu :-).

Nyní jsme vybaveni ohněm i mečem a můžeme se vydat bojovat s valícími se hordami HTTP požadavků, nabobtnalými javascripty a krotit nepoddajnou cache v našich prohlížečích. Příští díly už budou ryze praktické a krok po kroku si projdeme jednotlivé tipy a doporučení. Brzy naviděnou!

Lukáš Zeman