100 bodů v PageSpeed: Co jsme pro to změnili

Výchozí hodnota byla 58 ze 100 na mobilu. Není to špatná hodnota pro web s 3D efektem v záhlaví, ale hodnota, kterou Google v mobilním vyhledávání znatelně trestá. Nakonec stálo 100 bodů na desktopu a 98 na mobilu, při rovněž 100 za přístupnost.

Co následuje, není obecný kontrolní seznam, ale skutečný průběh – včetně míst, kde jsme se zmýlili.

Výchozí stav

Pět zásahů, které skutečně rozhodly

1. Knihovnu nahradit, ne optimalizovat

Záhlaví ukazuje oblak částic v 3D. K tomu běžela známá grafická knihovna – 458 KB po zmenšení. Měření ukázalo, že 51 KB z toho se nikdy vůbec nespustilo.

Rozhodujícím pohledem byla otázka, kolik toho skutečně potřebujeme. Bylo to jedenáct stavebních prvků: renderer, scéna, kamera, geometrie, materiál a pár pomocných tříd. Všechno z toho se dá naprogramovat přímo proti grafickému rozhraní prohlížeče.

Výsledek: ze 458 KB se stalo 6 KB. Zobrazení je totožné – převzali jsme tytéž shadery.

2. Komprese byla zapnutá jen napůl

V konfiguraci serveru stála komprese na «zapnuto» – ale řádek s tím, které typy souborů se mají komprimovat, byl zakomentovaný. To je výchozí nastavení mnoha distribucí. Výsledek: komprimovalo se výhradně HTML.

Grafická knihovna tedy šla po lince nekomprimovaná. Po zapnutí: z 1243 KB se stalo 251 KB. Komprimované verze navíc nyní ukládáme předpočítané vedle, aby server nepočítal znovu při každém vyžádání.

Námaha: dva řádky konfigurace. Účinek: necelý megabajt při prvním načtení.

3. Animační knihovnu odstranit úplně

Pro prolínání při rolování běžela další knihovna, 114 KB. Měření ji navíc označilo za původkyni vynucených přepočtů rozvržení – během rolování se dotazovala na geometrii a nutila prohlížeč přepočítat rozvržení uprostřed pohybu.

Nahrazeno IntersectionObserver, který pouze nastaví třídu. Vlastní pohyb dělá CSS. O 114 KB méně, žádné přepočty, zhruba 40 řádků vlastního kódu.

4. Favicon měl 205 KB

Maličkost s překvapivým účinkem, protože se načítá velmi brzy. Nahrazena souborem SVG o 6 KB, vytvořeným ze stávajícího loga.

5. Dotazovat se na geometrii v animačním snímku

Jeden skript při každé události rolování četl celkovou výšku dokumentu. Tuto vlastnost prohlížeč nemůže zodpovědět z paměti – musí kvůli ní přepočítat rozvržení celé stránky, uprostřed rolování.

Pravidlo, které z toho plyne a které platí všude: v události číst, v následujícím snímku zapisovat. Nikdy naopak. Od té doby se výška stránky změří jednou a zapamatuje, místo aby se zjišťovala šedesátkrát za sekundu znovu.

Chyba, která stála 24 bodů

Co přineslo málo

Pro úplnost opatření, která stojí v každém návodu a u nás byla sotva měřitelná:

Formáty obrázků. Naše úvodní stránka má obrázků málo – logo je soubor SVG. Kde se obrázky vyskytují, se převod samozřejmě vyplatí; jako hlavní páka slouží jen u stránek bohatých na obrázky.

Další zmenšování písem. Dvě rodiny písem hostujeme sami a ty potřebné ve viditelné oblasti přednačítáme. Další optimalizace by byla možná, hodnotou ale nepohne.

Umístění serveru. Často doporučované, v našem případě nepodstatné: doba do prvního bajtu byla už na 20 milisekundách. Kdo je tam už dobře, distribuční sítí nic nezíská.

Postup k napodobení

1. Měřit dřív, než se cokoli změní. Mobil a desktop odděleně, hodnoty si zapsat.
2. Najít největší přenášený soubor. Téměř vždy je to JavaScript. Otázkou není, jak ho zmenšit, ale jestli ho potřebujete.
3. Zkontrolovat kompresi. Ne jestli je zapnutá, ale pro které typy souborů.
4. Spočítat blokující požadavky. Každý soubor stylopisu v záhlaví zdržuje první vykreslení.
5. Prověřit posuny rozvržení bez brzdy. Ten jediný test, který nám chyběl.
6. Po každé změně měřit znovu. Jinak na konci nevíte, co zabralo.

Pomoz mi převést zprávu PageSpeed mé stránky do pořadí
podle důležitosti. Buď přísný; nechval nic.

Moje naměřené hodnoty:
- Mobil: [počet bodů], Desktop: [počet bodů]
- LCP, TBT, CLS pro každé zařízení: [hodnoty]
- Největší přenášené soubory s velikostí: [seznam]
- Požadavky blokující vykreslení: [seznam]
- Hlášení ze zprávy: [vložit text]

Ke stránce:
- Jak je postavená: [CMS / statická / stavebnice]
- Je JavaScript potřeba pro viditelný obsah? [ano/ne]
- Jak se doručuje CSS? [externě / předem / částečně předem]

Úkoly:
1. Přiřaď každé hlášení k příčině a řekni, kterou metriku
   ovlivňuje – LCP, TBT nebo CLS.
2. Seřaď opatření podle účinku na jednotku námahy. U každého
   uveď, kolik bodů reálně pohne a proč.
3. Uveď opatření ze zprávy, která u mého typu stavby
   prakticky nic nepřinesou – a zdůvodni to, místo abys je
   prostě vynechal.
4. U každého velkého souboru JavaScriptu se nejdřív zeptej,
   jestli je potřeba, než navrhneš zmenšování.
5. Upozorni, pokud se CSS doručuje předem jen částečně,
   a vysvětli, proč to pro CLS může být horší
   než vůbec.
6. Uveď, co bych měl po každé změně změřit znovu.

Nevymýšlej si naměřené hodnoty.

Závěr

Počet bodů sám o sobě není cílem – je to naměřená hodnota, ne obchodní výsledek. Co se počítá, je zkušenost za tím: stránku, která je čitelná po 1,4 sekundy, si přečte víc lidí než tu, která potřebuje šest sekund. U mobilních návštěvníků přes mobilní síť je ten rozdíl větší než jakákoli optimalizace textu.

Cesta k tomu vedla v našem případě přes jedinou opakující se otázku: potřebujeme to? Pět ze šesti zásahů spočívalo v tom něco odstranit, ne něco přidat.

Časté otázky