Hlavní navigace

Google mod_pagespeed: rychlejší komunikace s webovým serverem

Adam Štrauch 12. 10. 2012

Google ve středu prohlásil modul mod_pagespeed do webového serveru Apache za stabilní, což může nejednoho administrátora přivést k myšlence, zda by to nepomohlo také jeho serverům. V tomto článku se na mod_pagespeed podíváme a změříme si, jaký vliv mají jeho optimalizace na komunikaci mezi serverem a prohlížečem.

Google už dlouho část svých aktivit věnuje zrychlování komunikace webového prohlížeče a webového serveru. Google Chrome byl prvním prohlížečem podporujícím například protokol SPDY, který dovolí prohlížeči v jednom požadavku stáhnout více souborů a aby měl protokol smysl, přinesl jeho podporu i do webového serveru Apache. SPDY ale řeší jen část problému. Tou druhou jsou samotné webové stránky a jejich statický obsah, které nebývají optimalizované pro pomalejší připojení. Vývojáři se snaží ve zdrojovém kódu držet pořádek, což zvětšuje kód a zvyšuje počet spojení mezi prohlížečem a serverem.

Jak se postupem času zrychlovalo připojení našich počítačů do internetu, přestávalo mít smysl starat se o masivní optimalizace. Nicméně přišla éra chytrých telefonů a tabletů s mobilním připojením, které mění své vlastnosti s každým krokem svého uživatele. Opět se dostáváme do situace, kdy je třeba řešit pomalé linky. Dříve byli uživatelé zvyklí, když se jim obrázek načítal 40 sekund, dneska už mají jiné standardy a když se nepodvolí technologie, je třeba zapracovat na optimalizaci. 

Google část portfólia svých služeb založil na mobilních aplikacích a mobilních webových službách. Čím víc uživatelé uvidí stránek, tím víc reklamy se podaří naservírovat, nemluvě o určitém komfortu, díky kterému se uživatelé rozhodnou právě pro Google. Jeho servery možná vrací pro lidské oko nepřehlednou směs HTML, CSS, JavaScriptu a obrázků v jednom souboru, ale jeho weby se načítají opravdu rychle i s horším připojením.

Naštěstí není potřeba složitě kompilovat webové aplikace do efektivní směsi pro prohlížeče, ale ve středu stabilizovaný mod_pagespeed to udělá za vás. Je to modul určený pro server Apache a obsahuje 40 konfigurovatelných filtrů, které se postarají o efektivní výstup směrem k webovému prohlížeči. Filtry zasahují do obsahu stránky, provedou tzv. minify, tedy odstraní z kódu zbytečné mezery a odřádkování, malé CSS/JS soubory vloží přímo do HTML a to samé udělají u malých obrázků. Místo deseti souborů pak prohlížeč stahuje pouze jeden, což znamená méně režie a uživatel se dostane dřív k požadovaným informacím.

Modul mod_pagespeed vypadá jako bezchybný nástroj, který by měl mít každý web server, ale ne každý web z něj dokáže těžit a i v případě, že s ním vývojáři webu počítají a modul nastaví tak, aby vyhovoval konkrétní aplikaci, tak stále nemusí být zrychlení natolik významné, aby mělo smysl si komplikovat konfiguraci serveru a zatěžovat procesor serveru výpočty navíc.

Instalace

Google distribuuje mod_pagespeed stejně jako prohlížeč Google Chrome nebo mod_spdy, tedy v deb nebo rpm balíčcích. Ty najdete na developers.google.com. Po stažení stačí balíček nainstalovat jak jste zvyklí a restartovat Apache. Modul mod_pagespeed bude hned poté aktivní. Jeho výchozí konfigurace se snaží být co nejméně konfliktní, takže funkčnost webových aplikací by neměla být nějak narušena.

Druhou možností, jak mod_pagespeed do Apache dostat, je kompilace ze zdrojových kódů. Ta je trochu komplikovanější a vzhledem k tomu, že ji má Google velmi dobře popsanou v dokumentaci, nebudu se k této možnosti rozepisovat.

Filtry

Modul mod_pagespeed je založen na filtrech, kterých má více než 40. Každý filtr nějakým způsobem mění HTML stránku, o kterou si klientská strana požádala. Základnímu balíku filtrů se říká CoreFilters a obsahuje následující:

add_head Přidá tag head pokud neexistuje
combine_css Spojí CSS elementy do jednoho
convert_meta_tags Obsah metatagů http-eqiv bude vložen do hlavičky
extend_cache Zvětší cache pro CSS/JS soubory a obrázky
inline_css Malé CSS soubory vloží přímo do HTML
inline_import_to_link @imports bude převedeno na tag link
inline_javascript Malé JS soubory vloží přímo do HTML
rewrite_css Vymaže v CSS souborech nepotřebné znaky (mezery, odřádkování, ..) a když je povoleno rewrite_images, zpracuje i obrázky
rewrite_images Souvisí s dalšími filtry, když je povoleno recompress_images vymaže z obrázků metadata, resize_images změní velikost uvedenou v atributech width a height tagu img, inline_images vloží malé obrázky přímo do HTML
rewrite_javascript Odstraní z JS souborů nadbytečné znaky (mezery, odřádkování, taby, ..)
rewrite_style_attributes_with_url Aplikuje rewrite_css na styly v url(

Seznam všech modulů najdete na developers.google.com. Filtry, které nejsou uvedeny v tabulce, mohou nějakým způsobem narušit fungování aplikace nebo způsobit opačný efekt, než je požadované zrychlení. Například defer_javascript zpozdí JavaScriptový kód tak, aby se neprovedl dokud není stránka načtená, což může ovlivnit například funkci pro vizualizaci načtenosti stránky. Filtry, které nejsou zapnuty ve výchozím stavu mohou na správném místě v mnohém pomoci, ale je lepší jejich zapnutí testovat na konkrétních aplikacích a podle toho se rozhodnout, zda jejich použití má smysl či ne. Rozhodně se nedá doporučit agresivnější konfigurace mod_pagespeed na web servery, kde běží několik odlišných aplikací.

Konfigurace mod_pagespeed se nachází v souboru /etc/apache2/mods-enabled/pagespeed.conf (na Debianu/Ubuntu). Nejdůležitějšími direktivami jsou:

ModPagespeed Zapnutí či vypnutí modulu
AddOutputFilterByType Na jaké mime/type bude modul reagovat (výchozí je text/html)
ModPagespeedRewriteLevel Výchozí seznam filtrů, použitelné hodnoty jsou CoreFilters (základní filtry) nebo PassThrough (žádné filtry)
ModPagespeedDisableFilters Seznam vypnutých filtrů oddělených čárkou
ModPagespeedEnableFilters Seznam zapnutých filtrů oddělených čárkou

Filtry pro vkládání CSS/JS/obrázků přímo do HTML nebo změnu velikosti obrázků mají vlastní direktivy neuvedené v tabulce. Je s nimi možné vyladit jejich chování. Všechny direktivy mají bohatý komentář a ukázky použití, takže se určitě neztratíte.

Chování v praxi

O mod_pagespeed hodně prozradí pár jednoduchých testů. Je třeba zajímavé sledovat, jak s neoptimalizovanou stránkou popere prohlížeč a jak moc mu mod_pagespeed pomáhá. Nejdříve jsem se rozhodl použít pro testování čistou instalaci WordPressu, do kterého jsem nahrál pár obrázků a testoval stránku s jejich výpisem. Ukázalo se, že WordPress je už dostatečně optimalizovaný od svých vývojářů, takže základní pravidla, která jsem se rozhodl pro testování použít, měly na rychlost načítání zanedbatelný vliv. Navíc v naměřených hodnotách byla vidět spíše rychlost PHP než nějaký vliv mod_pagespeed. I tak zde uvedu výsledky. Pro jejich získání jsem použil rozšíření Page Benchmarker do prohlížeče Chrome. Ten umí sám o sobě měřit, jak dlouho se stránka načítá, ale Page Benchmarker měření usnadňuje automatickým opakováním a mazáním cache prohlížeče.

Nejdůležitější je sloupec total load mean, který říká, jak dlouho se načítala stránka se všemi statickými daty. Hodnoty jsou uvedeny v milisekundách. Prvních a druhých 10 měření je s vypnutým mod_pagespeed a poslední se zapnutým mod_pagespeed. Rozdíl mezi druhou a poslední skupinou měření je mizivý.

Rozhodl jsem se tedy stáhnout větší weby a uložit je jako statickou stránku. Vybral jsem si Root.cz, iDnes.cz a web o herní sérii Fallout Madbrahmin.cz, který se ukázal být jako nejlepší materiál pro testování. Začal jsem s Root.cz, kde do měření zasahovaly měřící kódy. I tak byl výsledek o 1 až 2 sekundy lepší s mod_pagespeed než bez něj.

U iDnes.cz je méně měřících kódů a tak jsou měření vyrovnanější. Bez mod_pagespeed vychází stažení stránky na 3,5 sekundy, zatímco s mod_pagespeed jsou to zhruba 2 sekundy.

Madbrahmin.cz měl sice jen jeden měřící kód, ale za to skripty od herního obchodu Xzone.cz. Ty měly na načítání největší vliv, takže musely jít společně s kódem Google Analytics pryč. Podařilo se mi web osekat tak, že se na cizí servery nepřipojoval, takže mohu měření s Madbrahmin.cz označit za nejpřesnější. Celkem se při stahování provede 33 požadavků a přenese 1,08 MB. V případě použití cache v prohlížeči je přenos pouhých 6 kB.

Když se po každém jednotlivém testu vymazala cache prohlížeče, trvalo stažení stránky 3,5 sekundy bez použití mod_pagespeed. Když se mod_pagespeed zapnul, spadl čas přibližně na 2 sekundy. Rozhodl jsem se do procesu zapojit cache v prohlížeči, abych zjistil, jak dokáže vlastnosti mod_pagespeed zastoupit. V takovém případě prohlížeč provede dotaz na každý statický soubor, zda se od určitého data nezměnil. Pokud ne, je vrácen kód 304 a velikost požadavku závisí víceméně jen na cookies a velikosti URL. Zde je důležité upozornit, že pokud by mod_pagespeed vkládal statický obsah do HTML dokumentu, bude tento obsah přenášen při každém požadavku na tento dokument. Na druhou stranu nebude proveden žádný požadavek a ušetří se jedno spojení, které v testech zabralo 60 až 100 ms. Nicméně na všech 30 statických souborů šly požadavky k serveru téměř ve shodný čas, takže toto vadí spíše webovému serveru než prohlížeči a nemusí to být nutné úzké hrdlo celého přenosu.

Provedl jsem tedy stejný test při využití cache prohlížeče.

Časy jsou téměř shodné jak při použití mod_pagespeed, tak bez něj.

Shrnutí

Ať už se řídíte testy v tomto článku nebo si uděláte vlastní s vlastními podmínkami, tak zjistíte, že mod_pagespeed není samospásný. Rozhodně to není nástroj, který by měl být jen tak puštěn na server, protože ve skutečnosti nemusí komunikaci mezi prohlížečem a webovým serverem významně urychlit. Jeho nastavení se pak jeví jako balancování na tom, o co se postará sám prohlížeč a co se provede již na serveru.

Kde najde mod_pagespeed uplatnění jsou mobilní webové aplikace, kde má každé spojení k serveru vyšší cenu a snížením jejich počtu lze dosáhnout pozorovatelného výsledku. Přidáním dalších filtrů lze zmenšit i datový tok. I tak se mi ale jeví jako lepší cesta připravit si skript, který aplikaci pod taktovkou vývojáře optimalizuje. Výsledek je méně dynamický, takže předvídatelný a možná i rychlejší.

Našli jste v článku chybu?

12. 10. 2012 9:21

azurit (neregistrovaný)

Mna by zaujimal aj dopad na server, minimalne sa zvysi zatazenie procesorov (o kolko?).

Lupa.cz: Avast po spojení s AVG propustí 700 lidí

Avast po spojení s AVG propustí 700 lidí

Měšec.cz: Kdy vám stát dá na stěhování 50 000 Kč?

Kdy vám stát dá na stěhování 50 000 Kč?

Lupa.cz: Seznam mění vedení. Pavel Zima v čele končí

Seznam mění vedení. Pavel Zima v čele končí

Podnikatel.cz: Přehledná titulka, průvodci, responzivita

Přehledná titulka, průvodci, responzivita

Root.cz: 250 Mbit/s po telefonní lince, když máte štěstí

250 Mbit/s po telefonní lince, když máte štěstí

Root.cz: Certifikáty zadarmo jsou horší než za peníze?

Certifikáty zadarmo jsou horší než za peníze?

Podnikatel.cz: Víme první výsledky doby odezvy #EET

Víme první výsledky doby odezvy #EET

DigiZone.cz: Recenze Westworld: zavraždit a...

Recenze Westworld: zavraždit a...

Vitalia.cz: To není kašel! Správná diagnóza zachrání život

To není kašel! Správná diagnóza zachrání život

Lupa.cz: Google měl výpadek, nejel Gmail ani YouTube

Google měl výpadek, nejel Gmail ani YouTube

Vitalia.cz: Jsou čajové sáčky toxické?

Jsou čajové sáčky toxické?

Vitalia.cz: Paštiky plné masa ho zatím neuživí

Paštiky plné masa ho zatím neuživí

DigiZone.cz: Sony KD-55XD8005 s Android 6.0

Sony KD-55XD8005 s Android 6.0

DigiZone.cz: Rádio Šlágr má licenci pro digi vysílání

Rádio Šlágr má licenci pro digi vysílání

Podnikatel.cz: Na poslední chvíli šokuje výjimkami v EET

Na poslední chvíli šokuje výjimkami v EET

Lupa.cz: UX přestává pro firmy být magie

UX přestává pro firmy být magie

Vitalia.cz: Chtějí si léčit kvasinky. Lék je jen v Německu

Chtějí si léčit kvasinky. Lék je jen v Německu

Podnikatel.cz: Podnikatelům dorazí varování od BSA

Podnikatelům dorazí varování od BSA

Vitalia.cz: Znáte „černý detox“? Ani to nezkoušejte

Znáte „černý detox“? Ani to nezkoušejte

Vitalia.cz: Tesco: Chudá rodina si koupí levné polské kuře

Tesco: Chudá rodina si koupí levné polské kuře