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 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ě.