Výkon a Core Web Vitals

Web má v Lighthouse 100 ze 100. Audit svítí zeleně, tým si odškrtne výkon. Za dva týdny přijde Search Console a Core Web Vitals jsou červené. Reálným lidem se stránka po kliknutí zasekává, INP leze přes 500 ms, a laboratorní audit o tom neřekl skoro nic.

Nikdo nelhal. Jen se spletly dva světy: laboratoř a terén.

Tři 3 metriky rychlosti

Core Web Vitals nejsou jedno „skóre rychlosti". Řeší tři části uživatelského zážitku.

LCP (Largest Contentful Paint) měří načítání. Ptá se, kdy se vykreslí největší viditelný kus obsahu v prvním viewportu, často hero obrázek, nadpis nebo větší blok textu. Good je do 2,5 s, Poor nad 4 s. Brzdí ho pomalý TTFB, pozdě objevený obrázek, těžký font nebo render-blocking CSS. Opravuje se hlavně v tom, jak rychle server vrací data.

INP (Interaction to Next Paint) měří odezvu. Ptá se, jak dlouho po kliknutí, tapu nebo stisku klávesy trvá, než prohlížeč vykreslí odpověď. Good je do 200 ms, Needs improvement 200 až 500 ms, Poor nad 500 ms. Nejčastěji ho kazí zahlcené hlavní vlákno a moc klientského JavaScriptu. Opravuje se obvykle v kódu na straně klienta.

CLS (Cumulative Layout Shift) měří vizuální stabilitu. Ptá se, jak moc obsah poskakuje, když dotečou obrázky, fonty, embed nebo pozdě vložený banner. Good je do 0,1, Poor nad 0,25. Není to čas, ale bezrozměrné skóre posunů. Opravuje se rezervací místa předem.

„Zrychlit web" tedy není jeden úkol. Když máš špatné INP, optimalizace obrázků sama o sobě nepomůže. Když poskakuje layout, rychlejší server s tím nehne.

Laboratoř a terén nejsou totéž měření

Nejdražší omyl je věřit, že Lighthouse, PageSpeed Insights a Search Console jen různě zobrazují stejnou pravdu. Nezobrazují, měří sice stejné věci, ale vychází z jiných dat.

Laboratoř spustí stránku v řízeném prostředí. Lighthouse a DevTools mají předem dané zařízení, síť a scénář. To je výborné pro ladění: změnu zopakuješ, izoluješ a hned ověříš. Jenže laboratorní běh nemá tvoje reálné publikum, jeho telefony, jeho síť ani jeho chování. Lighthouse bez uživatelské interakce neumí změřit skutečné INP, proto používá Total Blocking Time jako zástupnou laboratorní metriku. TBT se hodí jako stopa, ne jako verdikt.

Terén sbírá zkušenost skutečných lidí. Reálná zařízení, reálné sítě, reálné kliky, reálné čekání. Právě terénní data rozhodují v Search Console i v hodnocení Core Web Vitals. Laboratoř ti ukáže, kde hledat a co spravit, pak je to potřeba v terénu po čase zkontrolovat, že to skutečně pomohlo.

CrUX (Chrome UX Report) je zdroj Googlu o tom, jak se chová web. Bere způsobilé uživatele Chromu na podporovaných platformách; nezahrnuje Safari, Firefox, Edge, Chrome na iOS ani Android WebView. Zároveň vyžaduje dost návštěv a veřejně dostupné URL. CrUX tedy dobře ukáže, jak tě vidí Google, ale neřekne, proč je konkrétní interakce pomalá a jestli problém zažívají i lidé mimo Chrome.

Jak se rozhoduje projde / neprojde

Pro každou metriku se vezme 75. percentil za posledních 28 dní. Tedy hodnota, kterou má 75 % zobrazení stránky lepší nebo stejnou. Tohle pravidlo chrání před klamem rychlého vývojářského stroje: web musí fungovat pro většinu návštěv, nejen pro lidi na dobrém zařízení a rychlé síti.

Když jsou pro stránku nebo skupinu URL dostatečná data, výsledek projde jen tehdy, když jsou všechny tři metriky v Good na 75. percentilu. Jedna oranžová metrika znamená, že celek neprošel. Dvě zelené a jedna oranžová nejsou „skoro hotovo". Jsou to pořád špatná Core Web Vitals.

Z toho plyne jednoduchá priorita: nelešti LCP z 2,4 na 1,8 s, když INP visí na 480 ms. Strop drží nejslabší metrika. Optimalizace začíná tam, kde p75 padá přes práh.

Jak metriky zlepšit

LCP řeš v doručení prvního obsahu. Hero obrázek nesmí být pozdě objevený vedlejší zdroj. Nastav mu správné rozměry, srcset, moderní formát jako AVIF nebo WebP a podle situace i preload nebo fetchpriority="high". Zmenši TTFB přes cache, CDN a méně práce na serveru. Obrázky rozebírá kapitola o médiích a podkladech. Dává to smysl i podle aktuálních dat: Web Almanac 2025 u mediánové desktopové homepage uvádí zhruba 1 058 KB obrázků proti 697 KB JavaScriptu.

INP řeš na hlavním vlákně. Omez klientský JavaScript, rozděl dlouhé úlohy, posuň nedůležitou práci mimo reakci na kliknutí, použij code-splitting a vyhoď nepoužitý kód. Každý long task nad 50 ms bere prohlížeči prostor reagovat. Cíl není jen menší bundle. Cíl je volné hlavní vlákno ve chvíli, kdy člověk něco udělá.

CLS řeš rezervací prostoru. Obrázky a video mají mít width a height nebo aspect-ratio, aby si prohlížeč uměl místo nechat dopředu. Embedy a bannery potřebují stabilní kontejner. Fonty preloaduj jen když to dává smysl a nastav font-display, aby text nezpůsobil překvapivý přeskok. Animuj přes transform, ne přes vlastnosti, které přepočítávají layout.

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

Regrese většinou přijde jako nenápadný deploy: přibude měřicí skript, chat widget, knihovna pro carousel, třetí varianta fontu. JS naroste o desítky kilobajtů, hlavní vlákno ztěžkne, INP se za pár týdnů zhorší. Tým si toho všimne až za dlouho.

Jeden ze způsobů jak to řešit, je stanovit si výkonový rozpočet, tedy číslo, které můžou hlídat testy v CI.

Rozpočet má být konkrétní: maximální velikost JavaScriptu, počet požadavků, velikost obrázků pro první obrazovku, laboratorní metrika jako TBT, případně vlastní p75 z RUM. web.dev pořád uvádí 170 KB komprimovaných zdrojů na kritické cestě jako užitečný startovní bod, ale ne jako univerzální zákon. Skutečný rozpočet si nastav podle typu stránky, publika a výchozího stavu.

Mechanicky to není složité. Lighthouse CI umí hlídat budget.json, bundle nástroje umí zastavit příliš velký JavaScript a pipeline může mít úrovně warn / error.

Zatím to teda nikde nemáme a většinou se to používá na velkých projektech.

Výkon je zásadní pro výkon webu

„Rychlost je hezká, ale zaplatí mi ji někdo?" U obsahového webu se to projeví v dokončeném čtení, návratech a konverzích. U e-commerce přímo v tržbách.

Rakuten 24 nasadil optimalizaci Core Web Vitals a v A/B testu naměřil +53,37 % tržby na návštěvníka, +33,13 % konverzní poměr a −35,12 % exit rate. Vodafone v Itálii si to ověřil A/B testem na landing page: varianta optimalizovaná pro Web Vitals měla o 31 % lepší LCP a přinesla +8 % prodejů, +15 % lead-to-visit rate a +11 % cart-to-visit rate. Studie Deloitte a Googlu spočítala, že zrychlení mobilního webu o pouhých 0,1 s zvýšilo konverze v retailu o 8,4 % a průměrnou hodnotu objednávky o 9,2 %.

Stejný výsledek samozřejmě dostane každý web. Každopádně ukazují, že když reálný uživatel dostane hlavní obsah rychle, může hned kliknout a stránka mu neposkočí pod prstem, odstraňuješ tření z celého funnelu. Proto výkon patří mezi sdílené vyhledávací a konverzní signály, které řeší i SEO.

## Není to zbytečné pro malý web?

Pro malý web stačí jednoduchý režim: před spuštěním změř Lighthouse a PageSpeed Insights, po spuštění sleduj Search Console, drž jeden rozpočet na JS a obrázky, a při každém větším zásahu porovnej p75 před a po. Každopádně rychlost je jedna z klíčových věcí, co klientům slibujeme.

Praktický checklist

• Zjisti, která metrika je v terénu nejhorší: LCP, INP nebo CLS.
• Nezaměňuj Lighthouse skóre za Search Console. Laboratoř ladí, terén rozhoduje.
• U LCP kontroluj TTFB, hlavní obrázek, fonty, preload a prioritu zdrojů.
• U INP hledej dlouhé tasky, moc klientského JS a práci v handleru interakce.
• U CLS rezervuj prostor pro obrázky, video, embedy, bannery a fonty.
• Rozpočet dej do CI jako warn / error, jinak se regrese vrátí.
• Před redesignem ulož výchozí stav a po spuštění sleduj minimálně 28 dní terénních dat.

Typické záměny

• Zelený Lighthouse ≠ rychlý web. Lighthouse je laboratorní ladicí nástroj. Skutečné CWV v Search Console stojí na reálných uživatelích.
• TBT ≠ INP. TBT je užitečná laboratorní stopa, ale není to metrika, která rozhoduje v terénu.
• CrUX ≠ všichni moji uživatelé. CrUX je vzorek způsobilých uživatelů Chromu a neobsahuje diagnostiku. Vlastní RUM dá širší a konkrétnější obraz.
• Výkon ≠ rychlost serveru. TTFB je jen část LCP. INP často zabije klientský JavaScript, i když server odpovídá rychle.
• Výkonový rozpočet je byrokracie. Bez blokujícího pravidla se výkon zhoršuje po malých krocích, které jednotlivě nevypadají nebezpečně.

Zdroje

• web.dev — Web Vitals a Defining the Core Web Vitals metrics thresholds (LCP 2,5 s, INP 200 ms, CLS 0,1; p75 a pravidlo všech tří metrik).
• PageSpeed Insights docs — rozlišení field/lab dat, 28denní CrUX okno, p75 a průchod CWV.
• Search Console Help — Core Web Vitals report, skupiny URL, nejhorší metrika a hodnoty za posledních 28 dní.
• Chrome for Developers — CrUX overview a methodology (způsobilost uživatelů, podporované platformy, limity CrUX).
• web.dev — Interaction to Next Paint is officially a Core Web Vital (INP nahradil FID 12. 3. 2024).
• web.dev — Optimize LCP, Optimize INP, Optimize CLS; Performance budgets 101; Lighthouse CI.
• web.dev case studies — Rakuten 24 (optimalizace CWV: +53,37 % tržby/návštěvník, +33,13 % konverzní poměr, −35,12 % exit rate).
• web.dev case studies — Vodafone Itálie (LCP −31 %, +8 % prodejů, +15 % lead-to-visit rate, +11 % cart-to-visit rate).
• Deloitte / Google „Milliseconds Make Millions" — zrychlení mobilního webu o 0,1 s: +8,4 % konverze v retailu, +9,2 % průměrná hodnota objednávky.
• Web Almanac 2025 — Page Weight (medián desktopové homepage: 1 058 KB obrázků, 697 KB JavaScriptu).