Core Web Vitals a rychlost webu bez Google žargonu

Co jsou Core Web Vitals

Core Web Vitals je sada tří čísel, kterými Google měří, jak rychle a plynule se ti stránka načte. Nejdůležitější z nich se jmenuje LCP, zkratka pro Largest Contentful Paint. Měří jedinou věc, a to za jak dlouho je na stránce vůbec co číst, tedy kdy se objeví největší nadpis, fotka nebo blok textu, který na stránce vidíš. Nemá nic společného s tím, kdy web „začne reagovat" na klik, ani s tím, kdy zmizí načítací kolečko.

To je něco jiného než to, čemu lidé obvykle říkají rychlost webu, tedy jak dlouho trvá, než server vůbec odpoví. Tomu se říká TTFB, Time To First Byte, a měří se úplně jinak. Server může odpovědět bleskově, a stránka se přesto vykresluje dlouhé vteřiny, protože prohlížeč musí ještě stáhnout a zpracovat všechno, co se s tou odpovědí posílá. Přesně tenhle rozdíl jsme změřili na 114 webech malých firem.

Server odpoví do 800 milisekund u 87 ze 114 webů. U 45 z nich, tedy 39 % všech změřených, si čtenář na hlavní obsah přesto počká přes čtyři vteřiny.

Jak jsme měřili

Vzorek je stejný jako u naší dřívější kontroly dostupnosti, 127 webů malých firem a živnostníků ze seznamu firem, které oslovujeme s nabídkou, ne náhodný výběr z rejstříku. Na stav českých webů jako celku z něj usuzovat nejde. Ze 127 webů jsme 114 změřili celé, tedy hlavní obsah stránky se na nich skutečně vykreslil. Zbylých 13 se nepodařilo změřit vůbec. Buď se stránka nenačetla ani do třiceti vteřin, nebo spadl certifikát, nebo prohlížeč dostal jen zavřené spojení.

Měřili jsme 10. září 2026, jedním strojem z jednoho místa, každý web jedním během. Prohlížeč předstíral telefon Pixel 7 na pomalé mobilní síti a se čtyřikrát pomalejším procesorem, stejně, jako měří výchozí mobilní profil nástroje Lighthouse, na kterém stojí i PageSpeed Insights. Bez tohohle zpomalení by čísla vypadala nereálně dobře.

Tohle jsou laboratorní data, ne to, co vidí skuteční návštěvníci na svých telefonech a připojeních. Google k reálným datům používá vlastní systém CrUX, sbírá jím zkušenost opravdových lidí, a ten by pro tyhle weby ukázal jiná čísla.

K PageSpeed Insights API jsme se bez klíče nedostali, denní limit byl vyčerpaný, takže jsme měřili vlastním nástrojem se stejnou metodikou. Jedno měření na web je navíc křehká věc, web mohl mít zrovna horší chvíli. Nejspolehlivější je proto srovnání v rámci jednoho a téhož načtení, tedy jak dlouho trvala odpověď serveru proti tomu, jak dlouho trvalo celé vykreslení.

Kolik webů je podle Googlu pomalých

Medián LCP na 114 změřených webech vyšel na 4 974 milisekund, tedy 4,97 vteřiny. Google považuje za dobrý výsledek cokoliv do 2,5 vteřiny, za špatný cokoliv nad 4 vteřiny. Do dobrého pásma se vešlo 34 webů (30 %), do prostředního 13 webů (11 %) a do špatného 67 webů, tedy 59 % vzorku.

Nejrychlejší web se vykreslil za 252 milisekund, nejpomalejší za 24 488 milisekund, skoro dvacet pět vteřin čekání na to, aby se vůbec objevil hlavní obsah.

Druhá metrika, posun rozvržení stránky neboli CLS, dopadla přesně obráceně. Medián 0,0035 je hluboko pod hranicí 0,1, kterou Google považuje za dobrou, a jen 6 ze 114 webů překročilo špatnou hranici 0,25. Tlačítka a texty na těchhle webech tedy neskáčou pod prsty, jen na ně čtenář dlouho čeká. Google počítá do Core Web Vitals ještě třetí metriku, INP, která měří odezvu na klik nebo dotyk. Tu jsme v tomhle měření nezjišťovali. Zbytek článku se drží LCP, protože na něm tenhle vzorek pokulhává nejvíc.

Server odpoví hned, obsah se přesto nezobrazí

Tohle je hlavní zjištění celého měření. U 87 ze 114 webů přišla odpověď serveru do 800 milisekund. U 45 z nich, tedy 39 % ze všech 114 změřených webů, se hlavní obsah přesto objevil až po víc než čtyřech vteřinách. Server tedy udělal svoji práci rychle. Co se dělo potom, je jiný příběh.

Server odpoví, jakmile pošle první bajt dat. Cesta k viditelnému obsahu ale pokračuje. Prohlížeč musí stáhnout obrázky, písma a skripty, spustit je, spočítat rozvržení stránky a teprve pak něco vykreslit. Když je tenhle balík dat velký nebo blokuje vykreslování, rychlá odpověď serveru na výsledný čas skoro nemá vliv.

Ukazuje to i případ, který se často považuje za hlavního viníka, blokující skripty v hlavičce stránky, tedy skripty, co se musí stáhnout a spustit dřív, než prohlížeč pustí ke slovu zbytek stránky. Ve vzorku je web bez jediného takového skriptu, a přesto se na něm čeká přes dvacet vteřin. A je tam i web s jednadvaceti blokujícími skripty, který se vykreslí za 11,4 vteřiny, tedy skoro dvakrát rychleji. Blokující skripty samy o sobě odpověď nedávají.

Proč záleží na tom, kolik dat web posílá

Přesnější stopa vede k velikosti stránky. Webů, které pošlou do prohlížeče méně než 500 kilobajtů, je ve vzorku 37 a jejich medián LCP je 2 292 milisekund. Webů nad 2 megabajty je 25 a jejich medián je 10 064 milisekund. Rozdíl je 4,4násobný, a platí mezi mediány dvou skupin z téhož vzorku, ne mezi dvěma náhodně vybranými weby.

Objem dat ale není celé vysvětlení. Dva weby ve vzorku přenesou 25, respektive 19 kilobajtů, tedy zlomek toho, co ostatní, a oba mají LCP přes jedenáct vteřin. Něco jiného než velikost přenosu je tam brzdilo. Jedno měření na jeden web tenhle detail neumí rozklíčovat, jen ukazuje, že samotná velikost stránky výsledek nezaručí.

Jak si vlastní web změříš sám

Otevři PageSpeed Insights a vlož adresu svého webu. Nástroj vrátí dvě sady výsledků, pro mobil a pro počítač. Podívej se nejdřív na mobilní verzi, protože z mobilu chodí většina návštěvníků. Nekoukej na velké skóre nahoře, míchá dohromady několik metrik najednou a neřekne ti, kde přesně je problém. Sjeď níž do části „Diagnostikujte problémy s výkonem" a najdi řádek Largest Contentful Paint.

Číslo u LCP porovnej s tím, jak dlouho trvala odpověď serveru. Tu ti PageSpeed Insights ukáže spolehlivě jen v horní části „Objevte, co zažívají skuteční uživatelé" jako Time to First Byte (TTFB), a to pouze u webů, u kterých má Google dost dat od návštěvníků v Chromu. U většiny webů malých firem tam stojí „Žádná data", u našeho vlastního webu taky. Dolní laboratorní část v tom nepomůže. Položka „Latence žádosti o dokument" ukázala u našeho webu odezvu serveru 3 milisekundy a tabulka „Rozdělení LCP" rovnou 0 ms. Nulu žádný server nedá, takže tohle číslo pro srovnání nepoužívej.

Odezvu serveru si změř v kontrole webu, která ji měří přímo.

Když je odezva serveru delší než těch 800 milisekund, které jsme v našem měření brali jako hranici rychlé odpovědi, problém je nejspíš na straně serveru nebo hostingu. Když je odezva serveru rychlá a LCP přesto vysoké, přesně jako u těch 45 webů z našeho vzorku, problém je v tom, co se posílá do prohlížeče, tedy velké obrázky, nenačtená písma a skripty, které blokují vykreslení.

Počítej s tím, že číslo bude horší, než jak web vnímáš sám v kanceláři, na rychlém wifi a novém počítači. PageSpeed Insights měří na zpomalené mobilní síti a s pomalejším procesorem schválně, aby přiblížil, jak web vidí člověk na horší síti nebo starším telefonu. To je reálnější část tvých návštěvníků než ty sám za stolem.

Co ti kontrola webu na Weave Labs neřekne

Na kontrole webu si kdokoli zdarma a bez e-mailu ověří, jestli web vůbec odpovídá, jestli má platný certifikát, jestli je nastavený pro mobily a jestli něco nebrzdí vykreslení hned v hlavičce stránky. To je užitečná a rychlá kontrola základů. Neříká ale, jak dlouho ve skutečnosti trvá, než je na stránce co číst. To je jiné měření, přesně to, o kterém je celý tenhle článek, a kontrola webu ho dnes neumí.

Pro rychlý přehled o vlastním webu tedy použij oboje, kontrolu webu pro základy a odezvu serveru, PageSpeed Insights pro LCP. Kdo chce vědět víc, včetně toho, kolik ho pomalý web může stát na ušlých poptávkách, najde hlubší rozbor v placeném auditu.

Souvisí s tím i to, co jsme psali o webech, které se zákazníkovi vůbec neotevřou. Rychlost a dostupnost jsou dvě různé věci, a firma může mít problém s jednou, s druhou, nebo s oběma najednou. Víc o tom v článku Když ti spadne web, nikdo ti nezavolá.