Zvyšte výkon vašeho webu

14.14 - 5. června 2008 | Webdesign

Výkon webových stránek můžeme obecně zvýšit snížením počtu dotazů na server, snížením objemu přenášených dat, optimalizacemi HTML kódu a v neposlední řadě optimalizací výkonného kódu aplikace. První tři pravidla lze uplatnit i na obyčejných prezentacích, proto se na ně podíváme blížeji.

Snížení počtu dotazů na server

Prvním krokem v optimalizaci by mělo být snížení počtu dotazů na server. Čím víc dotazů, tím více se musí přenášet dat, tím více musí server vynaložit prostředků na jejich obsloužení.

Snažte se snížit počet souborů, které vaše stránka tahá s sebou. Pokuste se sloučit externí skripty do jednoho souboru, stejně tak stylopisy. Místo toho, abyste měli zvláštní stylopis pro tisk, využijte pravidla @media print. Dále omezte @import pravidla na minimum. Další spoustu dotazů mají jistě na svědomí obrázky. Využijte chytře techniku spojování obrázků a snižte tak počet dotazů na minimum.

Dalším krokem ke snížení počtu dotazů je správně nastavené kešování. Většinou se setkávám s tím, že kešování není řízeno vůbec nebo je rovnou zakázáno. To považuju za velikou chybu. Místo zakázání kešování, zkuste nastavit cache na minutu, dvě. Nedělejte to však pomocí meta tagů, to nemá žádný význam. Posílejte HTTP hlavičky. Např. Cache-Control: public, must-revalidate, proxy-revalidate, max-age=120 nastavuje veřejné kešování na dvě minuty a za tuto dobu musí jak lokální, tak proxy cache stránku obnovit.

Dalším účinným pomocníkem je Entity Tag – ETag. ETag je hash obsahu. Pokud se obsah změní, změní se i hash. Tento hash je posílán v hlavičce klientovi a ten ho může připojit do opětovného dotazu. Pokud se obsah na serveru nezměnil, server odpoví kódem 304 Not Modified. V takovém případě je odpověď krátká a přenáší se jen několik bajtů a klient ví, že může použít lokální verzi.

Správným nastavením hlaviček Cache-Control a ETag můžete svému serveru hodně odlehčit.

Snížení objemu přenášených dat

Když už máme snížený počet dotazů – tedy zátěž serveru, ve druhém kroku bychom se měli pokusit snížit trafic – množství přenášených dat. Zkoušel jsem několik technik. Rád používám XHTML protože ho pak můžu zpracovávat pomocí obecného XML readeru. A XHTML vyžaduje oproti HTML o dost bajtů navíc. Proto jsem si udělal takový malý benchmark mojí titulní stránky. Rozdíl mezi HTML a XHTML verzí je cca 3 %. Pak jsem zkusil ořezat přebytečné bílé znaky. Tam už to bylo o něco lepší úspora 13 %. Kombinace HTML bez bílých znaků pak je na šestnácti 16%. Je to sice pěkné číslo, ale zase taková úspora to není.

Proto jsem nasadil kompresi. Ta konečně přinesla kýžený výsledek – úspora 64 %. Docela zajímavý nástroj, který vám zjistí, zda kompresi používáte a kolik byste byli schopní uspořit, najdete na stránkách www.aspnetresources.com. Zkoušel jsem pokusně české portály a kompresi používá pouze Seznam.cz. Přitom zcela jistě ji dříve používal i Atlas.cz, nechápu, proč už není zapnutá.

Jak zprovoznit kompresi na vašem serveru? Pokud máte IIS 6 a možnost nastavit si server sám, tak detaily najdete v článku Enabling HTTP Compression (IIS 6.0), v případě IIS 7 zase v článku Changes to compression in IIS7. Pokud k nastavení serveru přístup nemáte, můžete použít HttpModul pro kompresi. Uživatelé Apache jistě znají mod_deflate a mod_gzip.

Správně nastavenou kompresí ušetříte trafik. Ať už platíte vy nebo váš poskytovatel, je nejen ekonomické ale i solidární mít kompresi zapnutou.

Optimalizace kódu stránky

Správně napsaným kódem se dá zrychlit vykreslování stránky.

Pokud je vaše stránka well-formed a je validní, může být její vykreslení mnohem rychlejší.
Pokud nastavíte obrázkům rozměry, bude vykreslování stránky plynulejší a nebude se nepříjemně natahovat.
Pokud u dlouhých tabulek správně použijete thead, tfoot a vícero tbody, taktéž docílíte rychlejšího zpracování stránky.
Pokud externí skripty a jiné větší objekty, na jejichž zpracování musí prohlížeč čekat, připojíte až na konec stránky, nebude se na ně zbytečně čekat na začátku nebo uprostřed. Je to třeba častý nešvar magazínů, kde se vám načte perex, pod ním se 20 sekund načítá reklama a pak najednou nablikne zbytek stránky.

Spoustu zajímavých tipů na zrychlení najdete ve vývojářské části Yahoo v článku Best Practices for Speeding Up Your Web Site. Užitečný nástroj ze stejné dílny, který vám stránku zkontroluje přímo ve vašem prohlížeči je Add-on do Firebugu s názvem Y-Slow.

Mnoho z vás si jistě řekně, „k čemu bych měl optimalizovat, když moje stránky navštěvuje pár lidí denně?“ Já jsem toho názoru, že plýtvat se nemá. Doma taky určitě nemáte neustále otevřený vodovodní kohoutek…

Související

Autor: Aleš Roubíček | Web feed s komentáři | Přidej komentář | del.icio.us | Linkuj!

Komentáře

Daniel Dočekal

14.34 - 5. června 2008 | #

Komprese je hezká věc, bohužel má několik nepříjemných vedlejších jevů – v IE6 a některých prohlížečích blbne (proslulý je tím Blogspot, na jehož blogy se v IE6 občas nedá vůbec dostat). Minoritní nepříjemnost.

Hlavní problém je, že vznikne obrovská zátěž na server. A pak je lepší kompresi nemít.
Aleš Roubíček

14.55 - 5. června 2008 | #

IE6 má hlavně problémy s komprimovanými javascripty a obrázky. Není zas tak těžké, nastavit, aby se tomuto prohlížeče tato data nekoprimovala.

Co se týče zátěže procesoru, je to vždy věc, toho jak je vytížen. Pokud máte procesory servery vytížené na 60% a více, tak už stejně přemejšlejte o upgradu nebo optimalizaci aplikací na něm běžících. Druhou možností je komprimovaný výstup cachovat nebo mít předkomprimované statické části.
Zdeněk

15.53 - 5. června 2008 | #

Take jsem pri cteni sekce o kompresi pomyslel, ze jeji pouziti nese predevsim zvyseni zateze procesoru, ktera muze na serverech, kde krom „standardnich webovych stranek“ bezi i nejake komplexnejsi aplikace, pusobit pri velkem poctu soucasnych navstev vetsi problem nez kapacita linky.

Vzdy si pri premysleni o moznych optimalizacich vybavim google, ktery napr. pro ajaxove requesty vyuziva jednopismenne parametry a usetri tim urcite spoustu giga nez kdyby pouzil cele slovo :-).
Pavel Šindelka

15.55 - 5. června 2008 | #

O výhodách a nevýhodách spojování externích souborů a obecně zrychlování načítání stránek jsem pár měsíců nazad psal na http://www.sindelka.cz/…-javacriptu/

Mám pocit, že některé důležité postřehy zde nezazněly – externí soubory spojené do jednoho velkého mohou přinést i potíže cachování, verzování atp.
Timy

16.15 - 5. června 2008 | #

Můžu se zeptat, z čeho vyvozuješ, že validní stránka se načítá rychleji? A také proč je tabulka s thead, tbody a tfoot zpracována rychleji?
Aleš Roubíček

16.46 - 5. června 2008 | #

[4] Pavel Šindelka díky za doplnění, samozžejmě se musí tohle všechno hlídat. Verzování se dá snadno udělat třeba přidáním query stringu. Velikost obrázků se taky musí hlídat a použít optimální volbu.

[5] Timy píšou o tom někde na mozdevu… A je to i logické, browser nemá při sestavování problémy, nemusí nic dopočítávat atak.

Rozhodně to není tak, že když jen tak uděláte optimalizace, že si pomůžete. Je to věda, závisí to na mnoha faktorech a je to o nalezení optimálních nastavení. Ale obecně se dá říct, že většinou to pomůže výrazně.
Timy

17.50 - 5. června 2008 | #

[6] Aleš Roubíček Opravdu je to domýšlení značek tak znatelné? A co třeba odmýšlení lomítek v XHTML dokumentech? Nebo odmýšlení XML deklarace? Mně to všechno přijde jako docela zanedbatelné…

A jak jsi to myslel s tfoot a thead? Tbody bych ještě chápal, tenhle element musí obsahovat každá tabulka, ale tfoot a thead ne.
Aleš Roubíček

18.48 - 5. června 2008 | #

[7] Timy Nic odmýšlet nemusí, prohlížeč dostává to, čemu rozumí.

K tabulkám: pokud máš nastavený table-layout:fixed a šířky sloupců, může se tabulka bezproblémů načítat postupně. S tim thead a tfoot jsem to někde četl, ale neověřoval, možná jsem přestřelil.
Timy

19.17 - 5. června 2008 | #

[8] Aleš Roubíček „Nic odmýšlet nemusí, prohlížeč dostává to, čemu rozumí.“ To si právě myslím, že není pravda. Vem třeba Firefox a zobraz si generovaný zdroják přes webdevel.: „View source → View generated source“, což je zdrojový kód po zpracování prohlížečem. Žádná lomítka ani XML deklarace tam neuvidíš.
Aleš Roubíček

19.29 - 5. června 2008 | #

XML prolog tam sice není, ale když pošleš XHTML tak s ním pracuje jako XHTML (tudíš lomítka zůstanou). Naproti tomu IE dostává HTML. Každý to, čemu rozumí. Schválně si to na mojí HP vyzkoušej.
Timy

19.46 - 5. června 2008 | #

[10] Aleš Roubíček Aha, já jsem se špatně vyjádřil :-). Myslel jsem XHTML poslané jako text/html.

BTW: Nevím proč nebo jak to, ale můj Firefox tuhle stránku dostává jako text/html.
Timy

19.50 - 5. června 2008 | #

[11] Timy Aha, ono se tak děje pouze na HP, tady ne.
Aleš Roubíček

20.17 - 5. června 2008 | #

No blog je prozatím v rozkladu…
sector

09.37 - 6. června 2008 | #

Jaky vyznam ma dnesni komprese XHTML a CSS – zadny…

skoro kazdy ma 512Kbps/s pripojeni k internetu a tak 100KB index stranky vubec nema zadny vliv – protoze se stahuje 3–4 vteriny (coz je samozrejme pohoda)

do ma mobilni pripojeni, musi pochopit a nejak to prekousout, protoze musi vedet, ze stranky se specialne pro jedince nebudou optimalizovat.

Co se tyce PHP a MySQL

u php se da nastavi Gzip a usetrit tak prenost dat az u nekterych pripadech o 70% a navic pokusit se psat takove scripty, ktere maji malo connection s DB

u MySQL naopak je vhodne uz od zacatku spravne navrhnout tabulky databaze a spravne nastavit INDEXy tabulky (kde si usetrite take hodne moc dotazu k DB

vyse napsane pomaha maly az stredne velkym webum jev co se tyce prenosu dat… snizeni zateze serveru bude tak 0,5 – 1% Nejlepsi je to u mega velkych aplikaci – kde se tedy ma pocitat ze DB bude davat nekolikset tisic dotazu za vterinu – ale zde uz se vetsinou pocita s hodne vykonnym HW.

Obecne optimalizace zdrojaku XHTML v dnesni dobe nema vubec zadny smysl. Clovek kdyz potrebuje neco na strance tak si ji stejne stahne i kdyby stahovani trvalo 10–20 vterin (treba flash nebo nejake videa) vetsina lidi si taky taha ruzne illegal filmy, hry, kouka na videa – co tim jako maji pak usetrit. Specialne pro ne srat se oprimalizaci kodu a usetrit 5–30KB je k nicemu.
optimalista

12.28 - 6. června 2008 | #

Sikovne shrnuti diky
Aleš Roubíček

16.29 - 6. června 2008 | #

[14] sector Díky za poznámky k PHP a MySQL, jenže kdo to myslí s výkonností aplikace skutečně vážně, vyhne se jim mílovým obloukem ;)

Optimalizace stránek jak na velikost, tak na rychlost podlě mě naopak má veliký význam. Mám rád plynulé browsdání a čekat na stránky i 3 sekundy se mi už moc nechce, natož minutové čekání na nahrání flashů a podobných věci.

Navíc, omezením velikosti, snížíme trafik na sítí a vzhledem k tomu, že neustále roste a někde musí mít své limity, tak je lepší chovat se preventivně úsporně. Ale to už je o tom, jak každý přemýšlí.
David Grudl

23.49 - 7. června 2008 | #

Komprimování stránek v PHP dělá problémy s IE6. Občas se stránka nezobrazí – je vidět jen bílá plocha. Pomůže reload.

Nepodařilo se mi přesně odsledovat, za jaké konstelace se to děje (třeba na svém blogu jsem takové projevy nezaznamenal a přitom je komprimovaný), nejspíš to koliduje s nějakou jinou hlavičkou.
Robin Raszka

01.05 - 8. června 2008 | #

Hezký článek, díky za souhrn :-)
Jakub Vrána

13.42 - 9. června 2008 | #

Hezký článek. Zájemce o tuto problematiku bych rád pozval na školení, které zanedlouho pořádám v Brně.
Ján Varhol

07.37 - 13. června 2008 | #

Vďaka za súhrn, hlavne s tými hlavičkami :)

A rád by som doplnil, ako napríklad zrýchliť načítanie obrázkov cez CSS:

Veľa stránok má na pozadí minitextúrky veľkosti 10×10 pixelov, ktoré dávajú prehliadaču zabrať oveľa viac, ako pozadie o veľkosti 100×100 pixelov (na pozadie sa umiestni 10× menej obrázkov). Takže je otázka, čo sa ušetrí.

Trošku mi vadí, že neboli spomenuté techniky spoločných ikoniek (keď sú všetky ikonky pokope a vďaka CSS sa zobrazuje iba jedna na jednom mieste).

Ale to asi nebolo cieľom článku.