Existuje specifický druh úzkosti, který se dostaví ve chvíli, kdy se zakladatel poprvé podívá na skóre svého webu v PageSpeed Insights. To číslo bývá někde v sedmdesátce. Stránka je plná červených a oranžových varování. A přirozená reakce je předpokládat, že je web nějak zásadně rozbitý a potřebuje okamžitou opravu.
Většinou není. A honit se za tím skóre je jeden z nejspolehlivějších způsobů, jak promarnit celý vývojářský sprint na věcech, které vašemu byznysu smysluplně nepomůžou.
Tady je upřímný výklad toho, co Core Web Vitals v roce 2026 vlastně jsou, které části Google při hodnocení webu skutečně používá a které můžete s klidem ignorovat, zatímco se soustředíte na ty, na kterých záleží.
Co ty metriky vlastně měří
Core Web Vitals jsou pokus Googlu změřit, jak váš web prožívá skutečný návštěvník. Ne jak čistý je kód, ne kolik dotazů stránka pošle, ale jak se reálně načítá a jak se s ní pracuje.
Tři, které mají váhu, jsou LCP, CLS a INP.
LCP, tedy Largest Contentful Paint, měří, jak dlouho trvá, než se objeví hlavní obsah stránky. Pokud někdo přijde na web a déle než dvě a půl vteřiny zírá na prázdnou nebo z poloviny načtenou obrazovku, máte špatné LCP. Google ho používá jako přímý faktor hodnocení.
CLS, Cumulative Layout Shift, měří, jestli stránka při načítání poskakuje. Ten otravný zážitek, kdy chcete kliknout na tlačítko a ono vám uskočí, protože se dodatečně načetl obrázek, je špatné CLS. Je to také faktor hodnocení a stojí za to o něj dbát už z prostšího důvodu: kvůli němu působí web rozbitě.
INP, Interaction to Next Paint, v roce 2024 nahradilo FID a měří, jak rychle stránka reaguje na akci uživatele. Když na něco kliknete a chvíli se nic neděje, je to špatné INP. Pro hodnocení váží méně než LCP a CLS, ale hodně rozhoduje o tom, jestli vašemu produktu člověk uvěří natolik, aby u něj zůstal.
Čemu Google dává skutečnou váhu
Ty tři nejsou rovnocenné a pochopení toho rozdílu vás ušetří špatných kompromisů.
LCP je to, co řešit jako první, a zároveň to, na čem startupové weby nejčastěji padají. Příčina bývá skoro vždy jedna ze dvou: obrázek, který je příliš velký a není pořádně optimalizovaný, nebo skripty blokující vykreslení, které se načítají dřív než hlavní obsah. Obojí se dá spravit bez přestavby webu. Ani jedna oprava nevyžaduje génia, obě ale vyžadují někoho, kdo skutečně ví, co dělá, ne někoho, kdo jen spustí report z Lighthouse a doufá, že se jeho návrhy promítnou do reálného zlepšení.
Problémy s CLS bývají strukturální. Písma bez explicitně nastavených rozměrů, obrázky bez atributů width a height, vložené prvky třetích stran, které se načítají asynchronně bez rezervovaného místa. To jsou rozhodnutí, která se udělají nebo neudělají ve chvíli, kdy se web staví. Proto je stavíme správně od začátku, místo abychom je dodatečně záplatovali.
Problémy s INP se obvykle objevují na webech přesycených JavaScriptem, kde se hodně děje v hlavním vlákně. Pokud je váš web hlavně marketingová prezentace a ne webová aplikace, tenhle limit překročíte málokdy. Pokud zvládá víc, zaslouží si pozornost.
Co můžete přestat řešit
Skóre v PageSpeed. Ne proto, že by na rychlosti nezáleželo, záleží, a zásadně, ale protože to skóre je směs mnoha věcí a optimalizovat na to číslo není totéž jako optimalizovat na signály, které Google opravdu používá. Web může mít skóre 72 a přesto skvělé reálné Core Web Vitals. Web může mít skóre 98 a přesto se na běžném mobilu v běžné síti načítat pomalu.
Počet HTTP požadavků. To bylo důležité v roce 2015 a od chvíle, kdy se standardem stalo HTTP/2, už to klíčové úzké hrdlo není.
Vyhazování každého skriptu třetí strany. Ano, externí skripty přidávají váhu. Ale strhat z webu každý analytický a chatovací nástroj kvůli dokonalému skóre vás obvykle stojí víc na datech a konverzní schopnosti, než kolik ušetříte na hodnocení.
Varování o zdrojích blokujících vykreslení, které ve skutečnosti nejsou na kritické cestě. Lighthouse značkuje agresivně. Ne každé varování je reálný problém.
Co většině týmů uniká
Core Web Vitals se měří z dat skutečných uživatelů, ne jen z laboratorních testů. Google při hodnocení bere v potaz vaše terénní data, tedy reálnou zkušenost skutečných návštěvníků na skutečných zařízeních, ne jen to, co hlásí Lighthouse v řízeném testu. Tyto dvě věci se mohou výrazně rozcházet a rozhodují právě ta terénní data.
Znamená to, že nejlepší optimalizace jsou ty, které zlepšují reálný výkon, ne ten simulovaný. Rychlejší server, správné formáty obrázků a líné načítání, žádné skripty blokující vykreslení na kritické cestě, build, který kvůli vykreslení jednoho odstavce textu neposílá tři sta kilobajtů JavaScriptu. To jsou základy a ty se v čase sčítají.
Stavíme rovnou na terénní data, ne na laboratorní skóre. Weby, které stavíme, se trefují do dobrých hodnot u všech tří metrik proto, že rozhodnutí, která k těmto výsledkům vedou, padnou v architektuře a v kódu, ne se na ně lepí jako záplaty po spuštění.
Pokud váš web na Core Web Vitals padá a chcete upřímně vědět proč a co by oprava reálně stála, přesně to pokrývá naše revize webu. Řekneme vám, které problémy jsou strukturální a které jen šum.