Případovka: jak jsme zrychlovali starší Drupal web bez kompletního přepisu

Ještě než jsem na jaře skončil v agentuře Lesensky.cz, pustil jsem se na přelomu roku s kolegy do optimalizace rychlosti načítání jednoho z prvního webů, který jsme za mého působení v roli Web Development Directora v agentuře stavěli. Svého času vyhrál WebTop100 coby nejlepší firemní web v České republice.

Původní stav webu

Čtyři roky provozu jsou na firemní a marketingový web docela dlouhá doba. Obsahově oproti původnímu stavu docela narostl, přibylo hned několik obsahových sekcí, stejně jako další jazykové mutace.

• Klasický sdílený webhosting na Websupportu s SSH přístupem pro snadný deploy a údržbu
• Redakční systém Drupal postupně upgradovaný do verze 10
• Tradiční téma vzhledu s velkým JavaScriptem
• SCSS spojené ve výsledku do obřího CSS monolitu
• Kritické CSS načítané přímo v těle HTML
• V průběhu života webu několik úprav s cílem zlepšit přístupnost
• Optimalizace obrázků v podobě automatického převodu do WebP s fallbackem na originál u nepodporovaných prohlížečů

Problémy s rychlostí a jejich analýza

Postupem doby nás začaly trápit především dvě věci:

Pomalá odezva už na serveru. Přestože má Drupal poměrně efektivní cacheování, stával se web pomalejším a pomalejším. Problém způsobovala především databáze sdíleného webhostingu a komunikace s ní. Ve chvíli, kdy Drupal sice má cache, ale ta je uložena v databázi a nejpomalejší SQL dotazy jsou ty sahající si do cache, je to nešťastné.

Uvadající Core Web Vitals. Jasně, drtivá většina webů, které mi opustí klávesnici nebo u kterých jsem se účastnil vývoje s kolegy v okamžiku spuštění těmto metrikám vyhovuje. Ale s přibývajícím obsahem a nutnými zásahy do kódu, například kvůli dalším obsahovým komponentám, ztrácí kondičku.

Nechtěli jsme jít cestou ad hoc testů v PageSpeed Insights od Google, takže jsem doporučil český nástroj PageSpeed.one, sáhli jsme po základní placené verzi bez poradenství (aktuálně 5400 Kč ročně) a začali web nejprve sledovat.

Na PageSpeed.one se mi líbí možnost sledovat konkurenční weby a vývoj jejich rychlostních metrik. S klientem jsme tak pětici největších konkurentů vytipovali a do nástroje přidali. Stejně tak jsme si určili stěžejní obsahové stránky. V našem případě to byly:

• Homepage
• Poptávkový formulář – pro web naprosto zásadní
• Produktová stránka, coby cíl reklamních kampaní a SEO optimalizací
• Druhá, jinak strukturovaná produktová stránka
• Detail pobočky, cíl lokálního SEO

💡 Tip: pro svoje potřeby rovněž používám PageSpeed.one, kde monitoruji tento blog, kromě toho občas koukám do základní neplacené verze GTmetrix a s pomocí vlastního konzolového udělátka na data z Chrome UX Reportu.

Přechod na dedikovaný server / VPS

Jako nejzásadnější problém jsme vyhodnotili pomalou odezvu na serveru. I stránka s poptávkovým fomulářem, na které vlastně není žádný jiný obsah, se načítala docela pomalu. Navíc nás v té době trápili časté, byť jen v řádech minut trvající výpadky a nedostupnost webu. 

💡 Tip: pro monitoring fungování webů používám nástroj Pulsetic.

Po komunikaci s několika serverhostingy jsme se nakonec domluvili s Igloonet.hosting, který nabídl vyhovující cenu zahrnující jak server samotný, tak jeho správu, zálohování a technickou podporu. Coby především marketingová a PR agentura jsme neměli kapacitu řešit správu serveru a toto bylo ideální řešení. Igloonet jsme využili u více projektů a komunikaci s nimi si nemohu vynachválit.

Zvýšení rychlosti a odezvy webu bylo znát prakticky okamžitě. V grafu s roční historií, který jsme vytáhli z PageSpeed.one ten schodek není tak dramatický kvůli vysokému přetížení původního hostingu během podzimu, ale v tříměsíčním srovnání to bylo hodně pěkné.

Image

Optimalizace v administraci Drupalu

V administraci Drupalu tolik úkolů k úpravám kupodivu nebylo. Používám osvědčenou sadu nezbytných modulů, díky letem zkušeností weby nezatěžuji zkoušením všech možných i nemožných rozšíření. Na všech webech mám automatickou optimalizaci obrázků do WebP. V případě Lomaxu šlo ještě o doplňkový modul, u novějších webů využívám možnost konverze zabudovanou přímo v jádře.

Spoustu let v Drupalu využívám komponentový přístup pomocí modulu Paragraphs. Výhody jsou zřejmé – majitel webu nebo marketingový tým si poskládá nové obsahové stránky a landing pages bez potřeby cokoli řešit s vývojářem a web zároveň není omezený na pevně danou strukturu nadpis – obrázek – text.

Naopak, není to taková flexibilita jako s klasickým builderem. Jistá míra nesvobody uživatele ale zajistí konzistentní vzhled webu z komponent odpovídajících grafickému zadání.

Optimalizace v tématu vzhledu Drupalu

Když Drupal přišel nejprve s experimentálním modulem, později se součástí jádra v podobě Single Directory Components, okamžitě jsem po tom sáhl a spojil je s Paragraphy. Pro každý paragraph v obsahu volám odpovídající komponentu. Podobně mám nachystané komponenty pro typy obsahu v různých režimech zobrazení, pro Views a pro formuláře.

Do většího rozpadu už obvykle nechodím. Mít samostatné komponenty například pro tlačítka a základní ovládací prvky mi nepřijde výhodné z poměru stráveného času. Alespoň u webů, které stavím.

Single Directory Components netřeba zapínat, je to vlastnost Drupalu a projeví se tím, že CSS, JavaScript a další položky ve složce komponenty se do stránky začlení jen v případě, že se na ní příslušná komponenta opravdu vyskytuje.

Lomax byl původně postaven sice s Paragraphy, ale tehdy ještě bez komponent, které Drupal neuměl. V rámci optimalizací jsme se tedy pustili právě do vytvoření komponent pro každý paragraph a kolega frontendista strávil pár desítek hodin rozpadem CSS do dílčích souborů v komponentách.

Podobně jsme se pustili do rozpadu JavaScriptu, který měl stejný problém jako CSS. Tedy, že na každé stránce webu se načítala spousta přebytečného kódu, který tam nebyl potřeba a využíval se například jen na dvou konkrétních podstránkách.

Větší zásah byl nutný i do kritického CSS, na většině webů máme určeno, které komponenty jsou vykresleny před zlomem stránky a z jejich CSS se kritické styly vygenerují.

Rychlejší web po pár měsících

Zmínil jsem, že jsme upřednostnili průběžný monitoring namísto ad hoc testů. Ty jsou samozřejmě prima jako rychlá reference pro vývojáře, ale je potřeba sledovat, jak je web rychlý u reálných uživatelů, kteří na něj přijdou. Proto využíváme PageSpeed.one, který nás i upozorní, pokud nastane nějaký výkyv.

A samozřejmě díky kontinuálnímu měření rychlosti jsme mohli sledovat, jak se provedené technické změny na webu reálně dotkly uživatelské zkušenosti.

První vykreslení obsahu (FCP) se opravilo se změnou serveru, je vidět, že původní hosting nestíhal včas servírovat ani běžné obrázky a podobné soubory. Přestože se na webu mění texty i data, podařilo se nám to po změnách udržet stále v zelených číslech.

Image

Kde jsme naopak dosáhli jen malého zlepšení a je prostor pro další optimalizaci, je metrika sledující Vykreslení největšího obsahu (LCP). Na desktopu je vše jakžtakž, v mobilu nás některý obsah zlobí. Koukneme se na videa a atributy fetchpriority u obrázků v hero sekcích.

Image

Naopak optimalizace JavaScriptu na straně webu neměla z pohledu naměřených čísel téměř žádný dopad na Celkový čas blokování JS (TBT). Dalším krokem bude analýza skriptů nasazených marketingem v TagManageru.

Image

Poměrně příznivě se ale přechod na Single Directory Components a úprava kritických stylů v Drupalu projevily v metrice Kumulativního posunu layoutu (CLS). Vyřešili jsme tedy ono nepříjemné poskakování obsahu při načtení stránky.

Image

Rád bych také zmínil, že je potřeba se soustředit nejenom na celková čísla pro celý web, ale i pro konkrétní stránky. Když totiž srovnám, co nám PageSpeed.one ukazuje za problémy s LCP u celkového pohledu a u rozpadu na sledované podstránky, tak špatně to už nevychází. Naopak, je ta vidět výrazné zlepšení. Poučení? Vyhledat konkrétní stránky, kde optimalizace nezabrala a identifikovat problém.

Image

Z dalších ukazatelů, na které v PageSpeed.one koukám, zmíním Technické přehledy. Zde jsou vidět například velikosti HTML kódu, skriptů, fontů atd. Za všechny přehledy vybírám ukázku, co vše může provést nasazení skriptů do TagManageru bez nějaké konzultace s vývojářem. Aneb hlídejte si, zda nemáte na webu zapomenutá měřidla nebo nevyužívanou analytiku.

Image

Co nás čeká dál?

Považuji za důležité, aby se rychlostní optimalizace dělala průběžně. Na webu je pár věcí, které mě i po provedených úpravách frustrují, protože se zatím nepodařily plně vyřešit:

• Použitá cookies lišta je jedním z problémů v LCP
• Rádi bychom zmenšili velikost HTML a počet uzlů, u CSS jsme klesli na polovinu
• Optimalizace datového objemu JavaScriptu
• Zlepšení komunikace mezi marketingem a vývojem

💡Tip: Kromě analýzy a průběžného sledování rychlosti samozřejmě vyhodnocujeme i chování uživatelů na webu. Pomáhá nám s tím Clarity. Samozřejmě se snažíme, aby nebylo aktivní neustále, ale jen pro sběr dat v určitém časovém úseku.