Na co nezapomínat při zrychlování stránek

O zrychlování načítání stránek se toho ví poměrně hodně. Ale i přesto se na webových stránkách objevují stále ty stejné chyby neustále dokola. Pojďme si je tedy ukázat a říct si, jak je opravit.

Příliš dlouhá doba odezvy?

Častý problém, často přehlíženo. Bohužel.

Čas, za který server odešle potřebná data do prohlížeče se poměrně liší napříč systémy. Statické stránky v tomto mají jasnou výhodu. Na serveru se nic nemusí generovat a jen se návštěvníku odešle požadovaná stránka. To trvá většinou okolo 50 milisekund, což je skvělé.

Složitější stránky jsou na tom už hůře. Hodně dobře odladěný web na redakčním systému WordPress má většinou dobu odezvy kolem 200 ms. To je čtyřnásobek času, který stačí statické stránce. Složité PHP a databáze si zkrátka berou svou daň.

To ovšem hovoříme o dobře odladěných stránkách. Tak například mé oblíbené stránky Web Designer Wall jsou na tom opravdu špatně. Doba odezvy se pohybuje od 300 ms do jedné vteřiny. Něco takového je naprosto nepřijatelné a je třeba to řešit.

Z druhé strany barikády mohu určitě zmínit Smashing Magazine, což je naprosto perfekcionisticky optimalizovaná stránka. Doba odezvy se pohybuje kolem 150 ms. Na webu, který obsahuje více jak 5.000 stránek a běží na WordPressu. To je fenomenální. Ani Interval.cz se nemusí za nic stydět. Běžně odezva kolem 180 ms na redakčním systému WordPress, když na něj naložíte více jak 4.000 článků? Klobouk dolů.

Zjednodušeně řečeno – cokoliv pod 200 ms je skvělé. Pokud máte odezvu větší, zkuste své stránky vyladit.

Smažte nepotřebné pluginy, optimalizujte databázi, smažte z ní zbytečné záznamy a maximálně zjednodušte skládání stránky. Nahlédněte do PHP, zvažte přechod na rychlejší hosting. Hodně vám také pomůže takzvaná opcode cache.

Ve starších verzích můžete zkusit APC, novější verze PHP (od 5.5) mají již dodávaný Zend Opcache. V takovém případě nic nemusíte řešit. Pokud však váš web stále běží na starších verzích a hosting podporuje APC, určitě si jej zapněte.

Ale jak dobu odezvy změřit? Snadno. Spusťte si prohlížeč Google Chrome, otevřete si požadovanou stránku a na ní zvolte do prázdného místa pravé tlačítko. Následně vyberte „Prozkoumat“. Otevře se vám konzole. V horní záložce zvolte „Network“ a v dolním sloupečku vyberte „Doc“.

To vám vyfiltruje pouze dokumenty. Teď můžete stránku znovu načíst. Ihned uvidíte podrobnosti. V nich můžete vyčíst velikost stahovaného dokumentu, dobu odezvy a další zajímavá fakta. Jestliže stránku několikrát znovu načtete, můžete si snadno udělat představu o době odezvy.

A jestli se vám to všechno zdá nějak moc složité, otevřete si Check GZIP compression a po zadání stránky dole najdete Execution time of HTTP request, což je totéž. Osobně tento nástroj používám mnohem raději. Je to rychlejší.

Hromada HTTP požadavků

V současné době dokáže prohlížeč stahovat pouze několik souborů najednou, ostatní je v té době blokováno. Každý si to uvědomuje, ale málokdo na to hledí. Běžně se tak stává, že stránka má 6 CSS stylů a dalších 8 JS souborů. To je nepřijatelné, protože už jen tato hromada dokáže prohlížeč solidně zahltit, což zbytečně brzdí načítání stránky.

Úsměvné pak bývá, když zmiňované soubory mají kupříkladu jen 2 kB. To není moc, řeknete si. Tady ovšem nejde o velikost, ale o zbytečný HTTP požadavek. Tak malý soubor je lepší sloučit s jiným či jeho obsah vložit takzvaně inline. Tedy přímo do HTML.

Nebude se tak tvořit zbytečný HTTP požadavek, stránky budou rychlejší a vaši návštěvníci spokojenější.

Když se podíváme na dříve zmiňované stránky, zjistíme že Interval.cz používá 7 CSS souborů. 5 z nich však nemá ani 5 kB. Efektivnější by tak bylo soubory sloučit do jednoho. Sice by CSS mělo nějakých 70 kB, ale ušetřilo by se tak 6 zbytečných požadavků. A to by už na pomalejších připojeních mohlo být znát.

Dobře tak dělá Web Designer Wall, který používá jen jeden CSS styl. Zkuste se v tom inspirovat.

Zkrátka z pluginů psaných v PHP smažte řádek, který se stará o přidání onoho CSS stylu do vaší stránky. Jeho obsah pak zkopírujte do toho svého (hlavního) a klidně si u toho udělejte poznámku. Ušetříte požadavky, zrychlíte své stránky a není to zas tak složité, jak se zpočátku mohlo zdát.

HTTP požadavky však netvoří jen styly, ale také například obrázky. Užívejte je z rozvahou, vyzkoušejte data URI u těch menších a celkově se snažte zbytečně nezahlcovat prohlížeč. Ať jsou stránky rychlé.

S daty to také nepřehánějte

Respektive s jejich velikostí. Je sice hezké, když budete dodržovat všechny osvědčené postupy pro rychlé stránky, ale když vaše obrázky budou mít 4 MB, CSS styl 400 kB a JS dalších 800 – stránky budou zoufale pomalé. I když budou mít skóre 100 v PageSpeed Insights.

Už jsem viděl tuny stránek, kterým chyběla jen pořádná optimalizace obrázků k jejich dokonalosti. Jenže třeba i špatně optimalizovaný obrázek může zapříčinit to, že necháte uživatele stahovat 2 MB naprosto zbytečně.

Znám i jednoho podnikatele, který měl na své stránce řadu fotek a jejich velikost činila dohromady přes 70 MB. Byl jsem tehdy „moc rád“, když mi jedno načtení jeho stránky doslova sežralo čtvrtinu mého limitu a já ihned po načtení dostal SMS od svého operátora, že bych si měl jako připlatit za datový balíček.

Pokud se budu držet příkladů, stránka Web Designer Wall nechá návštěvníky naprosto zbytečně stahovat při každém načtení 350 kB. Jen kvůli tomu, že majitel zapomněl zapnout gzip. Přitom jde jen o jednoduchý zápis do .htaccess souboru. Návod na zapnutí komprese jsem napsal už v roce 2011. A podpora ze strany poskytovatelů hostingu je skvělá.

Dalším příkladem může být jeden nejmenovaný herní server. Ten to naopak neskutečně nezvládá s optimalizací obrázků.

A teď se podržte. Jenom hlavní stránka vás nechá zbytečně stahovat celých 1.8 MB. A to počítám jen obrázky. I bezztrátovou kompresí (která nezmění vzhledově kvalitu obrázku) jdou některé obrázky zmenšit i o 60 % své velikosti. Zde má stránka jasně prostor pro zlepšení. Pokud máte na počítači hodně svižný internet, tyto chyby nepostřehnete, ale na mobilu je to od prvního okamžiku patrné.

Udělal jsem test i jednotlivých podstránek, abych provozovatelům nekřivdil, ale je to totéž. Dvě náhodně vybrané stránky (recenze) by šlo jen v oblasti optimalizaci obrázků zmenšit o 700 kB. Což je pořád hodně. I na rychlém mobilním internetu to může představovat klidně dvě vteřiny navíc. Naprosto zbytečně.

Rychlost načítání by mělo být stejně důležité téma jako design webu či jeho obsah. Protože když dobrý obsah doručíte běžnou rychlostí k návštěvníkům, na zadek se z toho neposadí. Když ovšem návštěvníkům doručíte fantastický obsah a to skvělou rychlostí, budou neskutečně rádi. A budou se k vám vracet.

Nespoléhejte proto na to, že všichni sedí u super-bleskového internetu. Tak to není. Uživatel by neměl stahovat zbytečnosti jen proto, že je majitel stránek líný. To by se mělo tesat do kamene.

A co kód třetích stran?

Při optimalizaci je třeba hledět i na obsah od třetích stran. Jako jsou třeba obrázky v komentářích od služby Gravatar, reklamy AdSense či tlačítka na sdílení.

V současnosti jsou na tom nejhůře tlačítka na sdílení. S čistým svědomím je nemohu doporučit nikomu. Nevkládáte si totiž na stránky jen tlačítko na sdílení, ale také stovky kB JS kódu určeného pro sledování návštěvníků.

Aby například Facebook věděl, na které stránky pravidelně chodíte, aby vám následně nabídl odpovídající reklamu.

Jen pro představu, na naprosto prázdnou stránku jsem vložil tlačítka na sdílení od Twitteru, Facebooku, Google+ a tlačítko LinkedIn. Výsledek? 630 kB dat a 29 HTTP požadavků. Přitom to jde řešit lépe. Udělat si tlačítka vlastní a odkazovat pomocí parametrů, které sociální sítě uvádí ve svých dokumentacích. Návod na uvedení do praxe najdete na blogu Tomáše Dvořáka.

V poslední době se taktéž Facebook rozhodl na některých serverech vypnout kompresi, což má za následek stahování dalších zbytečných dat. Jen tlačítko na sdílení vás nyní vyjde na zbytečných 350 kB. Pokud přitom vezmete jen třetinu této velikosti, v pořádku se do ní vejdete s vlastním řešením.