Výkon a Core Web Vitals

Web má v Lighthouse 100 ze 100. Audit svítí zeleně, tým slaví. O dva týdny později přijde report ze Search Console a Core Web Vitals jsou červené. INP reálných uživatelů přesahuje 500 ms, stránka pod prstem zamrzá při každém kliknutí, a zelený audit o tom neřekl ani slovo. Nikdo nelhal. Laboratoř a terén prostě měří jiné věci.

To napětí je jádro celé kapitoly. Jednovětou definici metrik má společný slovník: LCP pod 2,5 s, INP pod 200 ms, CLS pod 0,1, vždy na p75 reálných dat. Tady jde o to, proč ta čísla nejdou změřit jedním nástrojem, jak se opravdu vyhodnocují, a co se s nimi dá udělat.

Tři metriky, tři různé příčiny

Core Web Vitals nejsou jedno „skóre rychlosti". Jsou to tři nezávislé osy uživatelského zážitku a každá se rozbíjí i opravuje jinde.

LCP (Largest Contentful Paint) měří načítání. Kdy se vykreslí největší prvek viditelný bez posunu stránky, typicky hero obrázek nebo nadpis. Kategorie Good je do 2,5 s, Poor nad 4 s. Brzdí ho pomalý TTFB, těžké obrázky, pozdě objevený zdroj. Opravuje se na síti a v doručení.

INP (Interaction to Next Paint) měří odezvu. Jak dlouho po kliknutí, tapu nebo stisku klávesy trvá, než prohlížeč vykreslí reakci. Kategorie Good je do 200 ms, 200 až 500 ms je Needs improvement, nad 500 ms Poor. Vinu nese zahlcené hlavní vlákno a příliš mnoho klientského JavaScriptu. Opravuje se v kódu, ne na serveru.

CLS (Cumulative Layout Shift) měří vizuální stabilitu. Jak moc obsah poskakuje, když dotečou obrázky, fonty nebo pozdě vložené reklamy. Kategorie Good je do 0,1, Poor nad 0,25. Je to čistě bezrozměrné číslo, ne čas. Opravuje se rezervací místa předem.

„Zrychlit web" tedy není jeden úkol. Když máš špatné INP, optimalizace obrázků ti nepomůže. Když poskakuje layout, rychlejší server s tím nehne. Diagnóza musí rozlišit, která ze tří os je červená. Jinak opravuješ naslepo.

Laboratoř a terén nejsou dvě verze téhož

Tohle je ten omyl z úvodu, a stojí nejvíc peněz. Laboratorní a terénní měření se nepletou proto, že by jedno bylo přesnější. Pletou se, protože měří fyzicky jiné věci.

Laboratoř (syntetický monitoring). Lighthouse a DevTools spustí stránku v kontrolovaném prostředí. Předdefinované zařízení, simulovaná síť, žádný reálný uživatel. Je to reprodukovatelné a skvělé na ladění, problém izoluješ a hned ověříš opravu. Jenže do té stránky nikdo reálně neklikne. INP v laboratoři neexistuje. Potřebuje reálné interakce, a ty laboratoř nemá. Lighthouse nabídne jen náhražku, Total Blocking Time, což je odhad, ne ta metrika. Zelený laboratorní audit proto o reálném INP nevypovídá nic.

Terén (RUM). Terénní data sbírají skuteční uživatelé na svých zařízeních a sítích. Tohle Google používá pro hodnocení CWV i pro vyhledávání. Žádný laboratorní nástroj terénní data nenahradí, protože nezachytí pomalý telefon na 3G v metru.

CrUX (Chrome UX Report) je terénní zdroj, ale ne plnohodnotný RUM. Jsou to data jen z Chromu. Žádný Safari, Firefox ani Edge. A jsou čistě číselná: řeknou ti, jak rychlý jsi, ne proč. Diagnostiku „co konkrétně stránku brzdí" CrUX nedá. Na to potřebuješ vlastní RUM, který doplní kontext k číslu.

Nástroje pak dávají smysl podle toho, čí data čtou. PageSpeed Insights kombinuje obojí: nahoře terénní data z CrUX, dole laboratorní Lighthouse. Report CWV v Search Console je terénní, jede na CrUX. Lighthouse a DevTools jsou laboratorní. Zelený PSI dole a červené CWV v Search Console si vůbec neodporují. Měří jiné uživatele.

Jak se rozhoduje projde / neprojde

Hodnocení se chová jinak, než většina lidí čeká. Není to průměr a není to spojitá škála.

Pro každou metriku se vezme 75. percentil všech zobrazení stránky za rolovací 28denní okno. Tedy hodnota, kterou má 75 % návštěvníků lepší. Když i ten 75. percentil padne pod práh Good, metrika je Good. Bere se tím v potaz, že tvůj zážitek na rychlém Macu není zážitek mediánového uživatele s laciným Androidem.

A výsledek je nemilosrdný. Stránka projde CWV jen tehdy, když všechny tři metriky splní Good na p75. Jediná metrika v Needs improvement znamená celkový neúspěch. Dvě zelené a jedna oranžová není „skoro", je to neúspěch. Nejsou tu žádné body za snahu, jen tři pevné kategorie Good / Needs improvement / Poor.

To má praktický důsledek. Nemá smysl leštit LCP z 2,5 na 1,8 s, když INP visí na 480 ms. Strop drží nejhorší metrika. Optimalizace začíná tím, že najdeš tu jednu červenou, ne tím, že přidáš na té, co už je zelená.

INP nahradil FID v březnu 2024

Krátká poznámka, protože pojmy přežívají déle než metriky. Do 12. března 2024 byla metrika odezvy First Input Delay (FID). Ta měřila jen zpoždění první interakce, a skoro vždy vyšla dobře, takže nic neodhalila. Od 12. března 2024 ji nahradil INP, který přes Event Timing API měří dobu do dalšího vykreslení po jakékoli interakci za celou návštěvu. Search Console od té doby FID nezobrazuje. Když narazíš na starší článek mluvící o FID, je zastaralý.

Jak metriky zlepšit

Každá osa se opravuje na svém místě. Začni od té, která je na p75 červená.

LCP řešíš v doručení. Hero obrázku nastav preload s fetchpriority="high", klíčovým fontům taky. Doručuj AVIF nebo WebP, zmenši obrázek na reálné zobrazované rozměry, použij srcset. A zrychli TTFB pomocí edge cache. Obrázkovou stranu téhle páky rozebírá do detailu kapitola o médiích a podkladech a stojí za to vědět proč: podle Web Almanacu má medián stránky 1 054 KB obrázků proti 613 KB JavaScriptu na desktopu. Obrázky jsou na většině webů hlavní LCP páka.

INP řešíš na hlavním vlákně. Méně klientského JavaScriptu, rozbití dlouhých tasků (yield, requestIdleCallback), code-splitting, tree-shaking. Každý task nad 50 ms blokuje odezvu. Cíl je hlavní vlákno udržet volné, aby stačilo reagovat do 200 ms.

CLS řešíš rezervací místa. Na obrázky vždy width a height nebo aspect-ratio, ať si prohlížeč nechá prostor předem. Fonty preloaduj a řeš font-display. Animuj přes CSS transform, ne přes vlastnosti měnící layout. contain: layout izoluje posuny do regionu.

Výkon jako rozpočet, ne úklid po incidentu

Optimalizace po faktu má jednu vadu. Regrese protečou. Jeden deploy přidá knihovnu třetí strany, JS bundle naroste o 80 KB, INP se zhorší, a nikdo si toho nevšimne, dokud nepřijde terénní report. Výkonový rozpočet tomu předchází. Je to číselný strop, který se kontroluje automaticky.

Konkrétní čísla, o která se opřít. web.dev radí doručit pod zhruba 170 KB komprimovaných zdrojů na kritické cestě, tedy to, co potřebuje první obrazovka. Optimální rozpočet pro nejhorší scénáře vyšel ve výzkumu na 130 až 170 kB. Typický týmový strop bývá celkový JavaScript do 150 KB minifikovaný a gzipovaný.

Nástroje to umí vynutit. Webpack varuje nad 244 KiB nekomprimovaně. Angular CLI varuje nad 170 KB a build spadne nad 250 KB, když to nastavíš jako blokující pravidlo. Přesně tady se výkon stává součástí CI/CD: Lighthouse CI v pipeline s budget.json a úrovněmi off / warn / error, kde error blokuje merge. Mechaniku kontrolní brány v pipeline rozvádí build a deploy. Bez té zarážky není rozpočet pravidlo, je to přání.

Výkon je tržby, ne estetika auditu

Protiargument zní „rychlost je hezká, ale platí mi za ni někdo?". Platí, a jde to změřit pojmenovanými A/B testy, ne hypotézami.

Rakuten 24 nasadil optimalizaci CWV a v A/B testu naměřil +53,4 % tržby na návštěvníka, +33,1 % konverzní poměr a −35,1 % exit rate. Vodafone v Itálii zlepšil LCP o 31 % a viděl +8 % prodejů, +15 % leadů a +11 % návštěv košíku. Studie Deloitte a Googlu spočítala, že zrychlení o pouhou 0,1 s zvedlo v retailu konverze o 8,4 % a průměrnou hodnotu objednávky o 9,2 %.

To staví hon za jedním Lighthouse skóre na hlavu. Cíl není zelený audit. Cíl je, aby reálný uživatel na svém telefonu dostal obsah rychle, mohl hned kliknout a nic mu pod prstem neposkočilo. Audit je jen náhražka. Terénní data, a za nimi tržby, jsou to skutečné. Proto výkon patří mezi sdílené vyhledávací a konverzní signály, které řeší i SEO.

Co rozhodne dřív, než napíšeš první řádek CSS

Mikrooptimalizace nedoženou špatné architektonické rozhodnutí. Strop výkonu z velké části určí dvě věci, které volíš na začátku.

První je renderování. SSG dodá reálné HTML hned, což je dobré LCP. Méně klientského JS přes islands a partial hydration znamená lepší INP a menší CLS. Čistý CSR naopak posílá velký balík JavaScriptu, který zatíží hlavní vlákno přesně tam, kde se rodí špatné INP.

Druhá je hosting a CDN. Edge cache a komprese zkracují TTFB, a TTFB je první díl LCP. Pozor ale, CDN ve výchozím stavu HTML necachuje (třeba Cloudflare), takže reálné LCP závisí na konfiguraci, ne na tom, že „máme CDN". Konkrétní nastavení cache a komprese u poskytovatele řeší Cloudflare.

A jeden návyk před vším ostatním: nasbírej výchozí stav výkonu, než sáhneš na redesign. Bez čísla „odkud jsme vyšli" nepoznáš, jestli změna pomohla. Tahle disciplína patří do discovery.

Typické záměny

• Zelený Lighthouse = rychlý web. Laboratoř neměří INP (čistě terénní metriku) ani reálné CLS. Search Console i vyhledávání jedou na CrUX. Jeden audit dává falešný klid.
• CrUX = pravda o mých uživatelích. CrUX je jen Chrome, žádný Safari ani Firefox, a je čistě číselný bez diagnostiky. Na rozhodování chce vlastní RUM.
• Výkon = rychlost serveru. TTFB je jen díl LCP. INP rozhoduje hlavní vlákno a klientský JS, ne server.
• Výkonový rozpočet je byrokracie. Bez blokujícího pravidla proteče regrese každým deployem. Rozpočet je levný řádek v budget.json.

Zdroje

• web.dev — Defining the Core Web Vitals metrics thresholds (LCP 2,5 s, INP 200 ms, CLS 0,1; klasifikace na p75).
• corewebvitals.io — pass jen když všechny tři metriky splní good na p75 přes 28denní okno.
• web.dev / Google Search Central — INP nahradil FID 12. 3. 2024, Event Timing API, Search Console už FID nezobrazuje.
• DebugBear — laboratoř vs. RUM, CrUX vs. RUM (jen Chrome, číselný bez diagnostiky).
• web.dev — optimize LCP; dev.to — techniky pro INP a CLS.
• web.dev case studies — Rakuten 24 (+53,4 % revenue/visitor), Vodafone Itálie (LCP −31 %, +8 % prodejů), Deloitte/Google (0,1 s = +8,4 % konverze).
• web.dev — performance budgets (~170 KB critical path, 130–170 kB), Angular CLI (warn 170 KB / error 250 KB), Webpack (244 KiB).
• Web Almanac — medián 1 054 KB obrázků vs. 613 KB JS na desktopu.

Výkon stojí na třech nezávislých osách, které měří slovník. Z velké části ho předurčí volba renderování a hosting s CDN, obrázkovou páku drží média a podklady, výsledek projde/neprojde sdílí terénní data se SEO a hlídá se v CI/CD přes výkonový rozpočet. Výchozí stav se sbírá v discovery. Měřicí skript je sám položka rozpočtu: balík GA4 je o desítky kilobajtů těžší než nástroj bez cookies, který navíc nemusí nahrát blokující banner souhlasu, jak rozvádí analytika.