Rychlý web bez honby za stovkou v PageSpeed

Rychlý web se pozná podle používání, ne podle zeleného kolečka

PageSpeed Insights dokáže během několika minut upozornit na velký obrázek, dlouhou práci JavaScriptu nebo obsah, který se při načítání posouvá. To je užitečné. Potíž nastává ve chvíli, kdy se skóre začne brát jako obchodní cíl samo o sobě. Laboratorní skóre jednoho běhu ovlivní testovací zařízení, síť, stav serveru i obsah, který se zrovna načetl. O pár bodů jiné číslo proto ještě neznamená, že se web pro návštěvníka citelně změnil.

Core Web Vitals se soustředí na tři části zkušenosti: jak rychle se objeví hlavní obsah, jak pohotově stránka reaguje a zda se její rozložení neočekávaně nehýbe. Ani tyto metriky nepopisují všechno. Neřeknou, zda člověk rozumí nabídce, najde kontakt nebo bez potíží dokončí objednávku. Jsou ale dobrým společným jazykem pro konkrétní technické potíže, které lidé opravdu vnímají.

Terénní a laboratorní data odpovídají na jiné otázky

V PageSpeed Insights se můžete potkat se dvěma sadami údajů. Terénní data pocházejí z Chrome User Experience Reportu, zkráceně CrUX. Skládají zkušenosti skutečných uživatelů Chromu, kteří splňují podmínky pro zařazení do tohoto datasetu, a pracují s klouzavým obdobím posledních 28 dní. Zahrnují různá zařízení, sítě, lokality i způsoby používání. U menšího webu nebo málo navštěvované konkrétní URL ale nemusí být dost dat. Někdy je k dispozici jen souhrn za celý web.

Laboratorní část spustí Lighthouse v řízených podmínkách. Je opakovatelnější, nabídne detailní diagnostiku a vývojář ji může použít ještě před nasazením změny. Nevidí však týdny skutečného provozu ani běžné interakce návštěvníků. Lighthouse proto neumí přímo změřit INP: bez člověka, který na stránce skutečně kliká a píše, nemá z čeho celkovou odezvu návštěvy spočítat. Jako laboratorní vodítko používá Total Blocking Time, ale ten není náhradou za terénní INP.

Core Web Vitals hodnotí 75. percentil načtení stránek zvlášť pro mobilní a desktopová zařízení. Lidsky řečeno: web splní doporučenou hranici tehdy, když jí dosáhnou alespoň tři čtvrtiny naměřených načtení, ne jen rychlý notebook v kanceláři. Zároveň několik ojedinělých extrémů nerozhodne o celém hodnocení.

Tři metriky přeložené do běžných situací

LCP

Largest Contentful Paint sleduje, kdy se ve viditelné části stránky vykreslí největší obrázek, textový blok nebo video. Dobrá hodnota je nejvýše 2,5 sekundy. Nad 4 sekundy je výsledek špatný. Návštěvník vnímá hlavně to, zda stránka konečně ukázala svůj hlavní obsah.

INP

Interaction to Next Paint sleduje odezvu během celé návštěvy a zaměřuje se na jednu z nejpomalejších interakcí. U stránek s mnoha kliknutími přitom omezuje vliv ojedinělého extrému. Dobrá hodnota je nejvýše 200 ms, špatná nad 500 ms. Pro člověka je to rozdíl mezi tlačítkem, které odpoví hned, a rozhraním, u něhož si není jistý, zda kliknutí vůbec zaregistrovalo.

CLS

Cumulative Layout Shift vyjadřuje nejhorší sérii neočekávaných posunů během návštěvy. Zohledňuje velikost zasažené plochy i vzdálenost, o kterou se obsah pohnul. Dobrá hodnota je nejvýše 0,1, špatná nad 0,25. Typickým projevem je odkaz, který člověku uskočí právě ve chvíli, kdy na něj chce klepnout.

Hranice vždy čtěte v souvislosti se 75. percentilem a oddělením mobilu od desktopu. Hodnota LCP 2,4 sekundy z jednoho laboratorního testu není totéž jako dobré LCP pro 75 % skutečných mobilních návštěv. Stejně tak červené číslo není diagnóza. Metrika ukáže druh potíže. Konkrétní příčinu musíte najít na dané stránce.

Nejdřív najděte problém, který má dopad a dá se ověřit

Neexistuje univerzální pořadí, ve kterém má každý web optimalizovat obrázky, skripty a fonty. Začněte skutečným provozem: rozdělte stránky do smysluplných skupin, například homepage, články, produkty a košík. Jedna šablona může být rychlá, zatímco jiná má problém dlouhodobě. Souhrnná hodnota za celý web někdy průměruje situace, které spolu technicky téměř nesouvisejí. U neveřejné klientské části se budete muset opřít o vlastní měření a laboratorní testy, protože veřejný dataset pro ni obvykle nebude k dispozici.

1. 01

   Vyberte důležitý uživatelský scénář

   Nezačínejte automaticky úvodní stránkou. Otestujte cestu, kterou lidé opravdu používají: otevření detailu, filtrování nabídky, přidání do košíku nebo odeslání formuláře.

2. 02

   Podívejte se na skutečná data

   Porovnejte mobil a desktop, konkrétní URL a celý web. Zjistěte, která metrika selhává a zda jde o rozšířený problém, nebo o úzkou skupinu stránek.

3. 03

   Zopakujte potíž v laboratoři

   Použijte Lighthouse a panel Performance v Chrome DevTools. U INP projděte stejné interakce ručně, ideálně i při načítání a na slabším zařízení.

4. 04

   Opravte jednu srozumitelnou příčinu

   Upřednostněte změnu s jasnou vazbou na problém. Po úpravě musí být možné říct, co se zrychlilo a proč.

5. 05

   Hlídejte vedlejší dopady

   Optimalizace nesmí rozbít čitelnost, přístupnost, analytiku, objednávku ani vzhled. Rychlejší nefunkční formulář je pořád nefunkční formulář.

Pomalé LCP nemusí způsobovat jen velký obrázek

Velká fotografie v úvodu je častým LCP prvkem, ale výsledný čas nevzniká jen jejím stahováním. web.dev rozděluje LCP na dobu do první odpovědi serveru, prodlevu před zahájením načítání zdroje, samotné stahování a prodlevu před vykreslením. Obrázek může být rozumně malý, a přesto se k němu prohlížeč dostane pozdě, protože jej objeví až v JavaScriptu nebo čeká na blokující styly.

• Nechte prohlížeč důležitý zdroj objevit brzy. LCP obrázek patří ideálně přímo do HTML. Nenačítejte jej líně pomocí loading="lazy". U opravdu prioritního obrázku může pomoci fetchpriority="high".
• Posílejte přiměřenou velikost. Telefon nemá stahovat stejný několikamegabajtový obrázek jako velký monitor. Připravte více velikostí a zkontrolujte, kterou z nich prohlížeč skutečně načítá.
• Zkraťte čekání na server. Prověřte cache, přesměrování, práci backendu a vzdálenost k uživateli. LCP v terénu zahrnuje také síťové a serverové prodlevy před samotným vykreslením.
• Nenechte hlavní obsah čekat na zbytečnosti. Styly a skripty, které první obrazovka nepotřebuje, nemají blokovat její vykreslení.

Když web reaguje pomalu, sledujte celý okamžik od kliknutí po nový obraz

INP není jen rychlost jednoho event handleru. Doba interakce zahrnuje čekání na hlavní vlákno, zpracování obsluhy události a čas, který prohlížeč potřebuje k vykreslení dalšího snímku. Tlačítko tak může mít jednoduchý kód, ale pořád reagovat pozdě, protože před ním běží dlouhý úkol analytiky, vykreslování komponent nebo zpracování velkého seznamu.

Nejprve určete konkrétní pomalou interakci a prvek. Samotná souhrnná hodnota INP vývojáři neřekne, zda návštěvníky brzdí mobilní menu, filtr produktů nebo validace formuláře. Pokud máte vlastní měření v terénu, ukládejte spolu s hodnotou typ stránky, verzi webu a technické označení prvku — nikoliv obsah formuláře nebo text napsaný uživatelem.

• Rozdělte dlouhé úlohy tak, aby prohlížeč dostal prostor obsloužit vstup a vykreslit další snímek.
• Omezte JavaScript, který se stahuje, parsuje a spouští bez bezprostředního užitku. Zkontrolujte i skripty třetích stran.
• Po kliknutí ukažte rychlou a pravdivou zpětnou vazbu. Náročnou práci proveďte následně nebo ji rozdělte, pokud to architektura dovolí.
• U velkých změn DOM zmenšete rozsah práce a vyhněte se zbytečnému přepočítávání stylů a rozložení.
• Testujte i během načítání stránky, kdy bývá hlavní vlákno nejvytíženější, a projděte víc než první kliknutí.

Laboratorní TBT může upozornit na dlouhou blokaci hlavního vlákna a zlepšení TBT často pomůže i odezvě. Není však zárukou dobrého INP. Skutečný návštěvník může použít funkci, kterou laboratorní scénář vůbec neotevřel, nebo kliknout právě ve chvíli, kdy se na pozadí rozběhne další práce.

Když stránka poskakuje, rezervujte prostor dřív, než dorazí obsah

CLS nepenalizuje každý pohyb. Běžnou reakci na kliknutí posuzuje jinak než obsah, který bez varování uskočí během čtení. Špatná zkušenost vzniká hlavně tehdy, když se změní poloha něčeho, co člověk právě čte nebo chce ovládat. Častým viníkem jsou obrázky bez rozměrů, reklamní a vložené prvky bez rezervovaného místa, dodatečně vložené bannery a změna fontu.

• U obrázků a videí uvádějte width a height nebo stabilní poměr stran. Prohlížeč pak zná potřebný prostor ještě před stažením souboru.
• Pro reklamy, mapy, iframe a personalizované bloky připravte předem rozumný prostor. Po načtení je nevkládejte nad rozečtený obsah bez zásahu uživatele.
• Načítání webfontu nastavte tak, aby náhradní a výsledné písmo měly co nejpodobnější rozměry. Ověřte delší nadpisy i české znaky.
• Pro vizuální pohyb preferujte transformace, které nepřepočítávají rozložení okolních prvků, pokud se hodí k zamýšlenému efektu.

CLS bývá typickým místem, kde se laboratoř a terén rozcházejí. Laboratorní test sleduje krátké, předem dané načtení. Návštěvník ale může stránku nechat otevřenou, scrollovat níž a potkat pozdě načtený obsah, cookie lištu nebo komponentu po interakci. Při diagnostice proto sledujte layout shifts v panelu Performance a zároveň vyhodnocujte skutečné návštěvy.

Změnu ověřte ve třech časech: před nasazením, po něm a v provozu

Před úpravou si uložte výchozí měření a popište scénář tak, aby jej dokázal zopakovat i někdo jiný. Po implementaci použijte stejné zařízení, stránku a postup. Automatické testy v CI mohou hlídat výraznou regresi, ale nastavte rozumné rozpočty a počítejte s přirozeným kolísáním. Jediná absolutní hranice často vede k náhodným pádům nebo k optimalizaci testu místo produktu.

Po nasazení zkontrolujte chyby a základní funkčnost okamžitě. Terénní Core Web Vitals ale nevyhodnocujte po jednom dni: CrUX pracuje s posledními 28 dny, takže staré a nové návštěvy se určitou dobu mísí. Vlastní RUM může ukázat trend dříve a podrobněji, pokud má web dost provozu a měření je navržené s ohledem na soukromí.

1. 01

   Před změnou

   Zapište URL, zařízení, kroky, problematický prvek a výchozí hodnoty. Uložte profil z DevTools, ne jen snímek barevného skóre.

2. 02

   Před vydáním

   Porovnejte několik laboratorních běhů a projděte skutečný scénář. Ověřte vzhled, klávesnici, formuláře i chování při pomalejší síti.

3. 03

   Po vydání

   Sledujte technické chyby, vlastní terénní data a později CrUX. Mobil a desktop vyhodnocujte odděleně.

4. 04

   Při dalším vývoji

   Nastavte limity například pro velikost obrázků, JavaScriptu a dobu blokování. Při dalších úpravách hlídejte nové skripty a pravidelně testujte nejdůležitější šablony.