Praktické zkušenosti s optimalizací frontendové části Drupalu a rychlosti načítání

Drupal je obecně známý jako docela velký bumbrlíček, pokud přijde na počet souborů, velikost databáze i jeho rychlost. Na levném hostingu s ním parádu nenaděláte. Drupal 8 přinesl celou řadu optimalizací, takže poté, co jsem předělal jeden web právě na osmičku, chtěl jsem zjistit, kam až mohu zajít a jakých výsledků dosáhnu v různých testovacích programech pro měření rychlosti webu.

Teď vás možná zklamu – nebudu uvádět adresu na web, který je předmětem tohoto článku. Nechci, aby pak řada z vás pouštěla testy a případně web shodila. Stejně tak netuším, zda naměřené údaje z doby přípravy článku by odpovídaly aktuální situaci. Berme je ale jako orientační pro danou chvíli s tím, že nám poskytnou obrázek o tom, která úprava má jak velký podíl na zrychlení webu.

Testovací web pro měření a optimalizaci rychlosti

Webová prezentace, na které jsem testy prováděl, je menší web s firemní prezentací a v součtu 140 články v blogu a běžnými stránkami. Běží na Drupalu 8, do kterého byl web zmigrován ze sedmičky pomocí standardních modulů. Téma vzhledu se snaží využívat SVG ikonky, FontAwesome a občas samozřejmě nechybí běžné JPG a PNG. Web běží na virtuálním serveru u Linode. Styly jsou postaveny okolo Pure CSS.

Ve výchozím stavu web běžel na http, tedy bez SSL certifikátu i bez http/2. Žádná speciální optimalizace neproběhla. Pouze bylo zapnuté standardní cacheování v Drupalu 8.

Pro měření rychlosti načítání jsem použil dvojici nástrojů. PageSpeed Insights od Google poskytuje bodovou škálu od jedničky do stovky, která reflektuje splněná optimalizační pravidla. Čím více, tím lépe. Rozlišuje mobil a desktop.

Druhým testovacím nástrojem byl WebPageTest.org, rovněž od Google. Umí změřit rychlost načítání webů z různých míst při různé rychlosti připojení a nahrávat sekvenci načítání stránky do videa. Jednoduše tedy uvidíte, jak se web objevuje uživateli na displeji. A samozřejmě, čím déle je zobrazena bílá plocha, než naskočí alespoň část stránky, tím hůře pro konverze, návštěvnost a všechny tyto metriky.

Moje nastavení pro WebPageTest bylo následující: Praha, Chrome, rychlost připojení Mobile Fast a zapnutá volba Capture Video.

Prvotní výsledky měření, které jsem chtěl zlepšit

PageSpeed Insights:

• mobil 60/100
• počítač: 71/100

V obou případech mi Google doporučoval, abych optimalizoval obrázky, vyřešil blokující CSS a JavaScript, začal používat mezipaměť a abych minifikoval JavaScript. To, co v základu Drupal dělá, se mu tedy moc nelíbilo.

WebPageTest.org:

• LoadTime: 4,214 s
• FirstByte: 0,501 s
• Start Render: 2,922 s
• Speed Index: 3066
• Interactive: 6,5 s
• A A A D F X

Jinými slovy, rychlost načtení stránky přes čtyři sekundy, což není úplně dobré. První bajt přenesený ze serveru po půl sekundě. Tedy vše nad to už bylo záležitostí tahání zbytečně velkých dat, nikoli generování stránky na straně serveru a PHP. První vykreslení nějakého prvku v prohlížeči nastalo až téměř po třech sekundách čekání a stránka začala v prohlížeči reagovat po 6,5 sekundách. Rychlostní index je vnitřní index WebPageTestu, vyjadřuje čas v milisekundách, během kterých je stránka zpožděna. Závisí na velikosti view portu. Čím nižší, tím lepší.

Sada písmenek abecedy vyjadřuje v daném pořadí tyto údaje:

• čas pro načtení prvního bajtu,
• zda je spojení se stránkou aktivní (keep-alive povoleno),
• zda je zapnutá komprese přenosu obsahu ze serveru (obvykle gzip),
• zda jsou komprimovány obrázky,
• zda je cacheován statický obsah
• a zda je efektivně využíváno CDN.

Máte-li áčko, je vše v pořádku, čím horší písmenko, tím větší problém podle Google.

Zapnutí BigPipe

Okolo BigPipe a cacheování se v drupalovské komunitě hodně mluvilo. V případě tohoto konkrétního webu však zapnutí modulu BigPipe nepřineslo prakticky žádný měřitelný efekt. Apache Benchmark jsem však do hry nezapojoval, pak by se zřejmě přínos BigPipe projevil. Případně by byl rozpoznatelný u mnohem většího webu.

Zapnutí SSL a HTTP/2

Jak je dnes dobrým zvykem a jak nám všechny webové prohlížeče radí, zapnul jsem pro daný web SSL certifikát (od Let’s Encryptu). Díky tomu jsem mohl aktivovat http/2, tedy rychlejší a souběžné stahování více zdrojů stránky. Znáte jej možná pod dřívějším názvem Google SPDY, kdy jej podporoval na straně klienta jenom Chrome. Vývoj šel dál ve prospěch http/2 a dnes jej podporují všechny moderní webové prohlížeče. Zda web http/2 využívá, otestujete jednoduše doplňkem či rozšířením pro svůj prohlížeč.

Moje výsledky pro WebPageTest pak byly následující:

• LoadTime: 4,605 s
• FirstByte: 1,027 s
• Start Render: 3,113 s
• Speed Index: 3296
• Interactive: 7,01 s
• F A A D F X

Jak vidíte, vše se naopak zhoršilo, místo zlepšení. Zakopaný pes byl v tom, že jsem na WebPageTestu ponechal test na http. Na webu bylo po instalaci SSL certifikátu nastaveno přesměrování na https verzi přes .htaccess. Docela mě zarazilo, k jak výraznému zpoždění při přesměrování dochází.

Tyto výsledky WebPageTest s SSL a http/2 už jsou správně:

• LoadTime: 4,752 s
• FirstByte: 0,688 s
• Start Render: 3,518 s
• Speed Index: 3662
• Interactive: 7,5 s
• A A A D F X

Mírně prodloužené časy přikládám na vrub potřebě zvýšeného výkonu při šifrování, jinak si to nedovedu vysvětlit.

AdvAgg a Guetzli

V další fázi jsem v Drupalu zapnul modul AdvAgg, který lépe minifikuje nacacheované CSS a JavaScript v Drupalu. Ponechal jsem základní nastavení. Nový optimalizátor obrázků od Google, Guetzli, jsem použil pro fotky umístěné na webu.

Výsledek WebPageTestu po této úpravě:

• LoadTime: 3,6 s
• FirstByte: 0,710 s
• Start Render: 1,001 s
• Speed Index: 3711
• Interactive: 7,5 s
• A A A C F X

Zde je patrné, že došlo k výraznému snížení doby, po které se začne v prohlížeči něco renderovat. Tedy i základní nastavení modulu AdvAgg má velký vliv na uživatelský prožitek z webu.

Zapnutí mod_expire, agresivnější nastavení AdvAgg

Trochu jsem pátral, jak vyřešit hodnocení F(ail) u cacheování statického obsahu. Vyřešilo to zapnutí mod_expire v nastavení webového serveru Apache. Rozhodl jsem si pohrát s trochu agresivnějším nastavením modulu AdvAgg a zapnul jsem v něm Cache Settings na hodnotu High a dále aktivoval volbu Combine CSS using media queries.

WebPageTest mi pak ukázal následující:

• LoadTime: 3,654 s
• FirstByte: 0,717 s
• Start Render: 0,9 s
• Speed Index: 3695
• Interactive: 7,5 s
• A A A C A X

Cacheování u Apache se tedy opravilo, agresivnější nastavení AdvAgg zase takový efekt nemělo. Možná by se více projevilo u složitějšího webu.

Další ladění na maximum a 100/100

S dalším laděním už jsem zcela experimentoval a netušil, zda bude mít nějaký podstatný vliv. U JPEG obrázků jsem použil knihovnu ImageMagick a zkonvertoval fotky na progresivní JPEG s 85 % kvalitou (což asi dělá test PageSpeed Insights, když obrázky vyhodnocuje). Pro minifikaci JavaScriptu jsem použil Uglifyjs a pustil se do měření:

PageSpeed Insights:

• Mobil: 100/100
• Desktop: 100/100

To byl úžasný výsledek. Měl jsem ohromnou radost, že i v Drupalu je opravdu při troše snahy možné docílit skvělých výsledků. Vzápětí mi radost zkazil fakt, že minifikace javascriptů přes Uglifyjs způsobila nefunkčnost administrační lišty v Drupalu. Je tedy potřeba to vždy vyzkoušet.

Místo Uglifyjs jsem použil minifikaci přes JSMin+. Do webu jsem dále zahrnul Critical CSS vygenerované přes Critical Path CSS Generator.

Finální výsledek zaručující bezproblémové fungování webu, byl následující:

PageSpeed Insights:

• Mobil: 100/100
• Desktop: 83/100

WebPageTest:

• LoadTime: 2,826 s
• FirstByte: 0,713 s
• Start Render: 1,015 s
• Speed Index: 1464
• Interactive: 6,5 s
• A A A A A X

Shrnuto a podtrženo: načítání stránky i dobu, po které se uživateli něco začne před očima dít, jsem snížil na polovinu. Absolutní čísla mi přijdou více než v pohodě. V písmenkovém hodnocení X na konci znamená, že nepoužívám CDN. Nevidím k tomu ale u daného webu důvod.

Pokud mohu doporučit, určitě se do optimalizací pusťte. Ten čas, který s tím strávíte, je možná poprvé trochu delší, ale jakmile se to naučíte, budete to dělat automaticky. V případě Drupalu je potřeba pečlivě vyzkoušet, zda po zapnutí modulu AdvAgg zůstane vše funkční, jak má, následně se pusťte do postupného zapínání agresivnějších nastavení.

Hledáte-li tipy, jak web na frontendové části zrychlit, doporučuji knihu Martina Michálka Vzhůru do (responzivního) webdesignu, taktéž i jeho školení, ze kterého jsem čerpal především.