Core Web Vitals v roce 2026: aktuální metriky
Aktuální Core Web Vitals jsou LCP, INP a CLS. LCP měří výkon načítání, INP odezvu interakcí a CLS vizuální stabilitu. Google je popisuje jako základní uživatelsky orientované aspekty reálné zkušenosti. [1][3]
FID už do sady nepatří. INP nahradilo FID v březnu 2024 a FID bylo později odstraněno z CrUX. [7][14]
Prahové hodnoty a 75. percentil
| Metrika | Dobré | Potřebuje zlepšení | Špatné | Co měří |
|---|---|---|---|---|
| LCP | ≤ 2.5 s | 2.5 s - 4.0 s | > 4.0 s | Načtení hlavního obsahu |
| INP | ≤ 200 ms | 200 ms - 500 ms | > 500 ms | Odezvu interakcí |
| CLS | ≤ 0.1 | 0.1 - 0.25 | > 0.25 | Vizuální stabilitu |
Dobré jsou LCP ≤ 2,5 s, INP ≤ 200 ms a CLS ≤ 0,1. Zlepšení vyžadují 2,5 až 4,0 s, 200 až 500 ms a 0,1 až 0,25. Vyšší hodnoty jsou špatné. [3][4]
Google používá 75. percentil, ne průměr. Alespoň 75% zkušeností musí splnit práh nebo být lepší. Mobil a desktop se hodnotí odděleně. [3][4]
Celkové hodnocení projde jen při dobrém výsledku všech tří metrik. [3]
Core Web Vitals a SEO
Google potvrzuje, že Core Web Vitals používá v systémech hodnocení jako součást hodnocení zkušenosti se stránkou. Dobré hodnoty ale nezaručují vysokou pozici, protože rozhodují i relevance a kvalita obsahu. [1][2]
Optimalizace tedy zlepšuje skutečný UX a odstraňuje technickou slabinu, ale nenahrazuje dobrý obsah.
LCP: co přesně měří
Largest Contentful Paint měří čas od začátku navigace do vykreslení největšího vhodného obsahového prvku ve viewportu. Terénní LCP může zahrnovat redirecty, vytvoření spojení a TTFB. [5]
LCP proto není jen čas stahování největšího obrázku. Zpoždění může vzniknout mnohem dříve. [5][6]
LCP v praxi: čtyři části
web.dev rozděluje LCP na TTFB, zpoždění načtení zdroje, dobu načtení zdroje a zpoždění vykreslení prvku. [6]
Když je LCP zdroj objeven pozdě, samotná komprese nemusí pomoci. Zdroj by měl být pokud možno objevitelný v počátečním HTML a LCP obrázek se nemá lazy loadovat. Pomoci může priorita nebo preload. [6]
Diagnostikujte v pořadí: TTFB, discovery zdroje, transfer, render delay. [6]
- Snižte TTFB pomocí cache, CDN, menšího počtu redirectů a rychlejšího backendu.
- Zpřístupněte LCP zdroj v počátečním HTML.
- Nepoužívejte `loading="lazy"` pro LCP obrázek.
- Při pozdním discovery použijte vhodnou prioritu nebo preload.
- Optimalizujte velikost a formát jen pokud je transfer skutečný problém.
- Omezte JavaScript nebo CSS blokující finální vykreslení.
INP: odezva během celé návštěvy
Interaction to Next Paint sleduje kliknutí, tapy a klávesnici během celé návštěvy. Pro většinu stránek se reportuje nejpomalejší interakce. U velmi interaktivních stránek se jedna nejhorší interakce na každých 50 ignoruje kvůli omezení outlierů. [7]
INP se liší od FID, protože zahrnuje input delay, processing a dobu do dalšího paint. [7][8]
Bez kliknutí, tapu nebo klávesnice nemusí mít návštěva INP. Scroll a hover se nepočítají. [7]
INP v praxi: tři zdroje latence
Celková latence se skládá z input delay, processing duration a presentation delay. Špatné INP může způsobit vytížený main thread, pomalé handlery nebo drahý layout a rendering. [8]
Pomáhají kratší úlohy, dělení práce, méně těžkého JavaScriptu, jednodušší layout, vhodné Web Workers a rychlá vizuální odezva. [8]
Začněte RUM daty, která identifikují pomalou interakci, a pak ji reprodukujte v DevTools. Lighthouse sám nereprezentuje plné reálné INP. [8][11][12]
CLS: stabilita během celé životnosti stránky
Cumulative Layout Shift měří neočekávaný pohyb viditelných prvků. Používá největší okno relace, kde po sobě jdoucí posuny dělí méně než jedna sekunda a celé okno trvá maximálně pět sekund. [9]
CLS je bezrozměrné a kombinuje dopad a vzdálenost posunu. Některé změny přímo související s akcí uživatele mohou být vyloučeny. [9]
Problémy často vznikají až po loadu kvůli reklamám, bannerům, widgetům nebo fontům. Jediný laboratorní load je nemusí zachytit. [10][11]
CLS v praxi: časté příčiny
web.dev uvádí obrázky bez rozměrů, reklamy, embedy a iframy bez rezervovaného místa, dynamický obsah a webfonty. [10]
Rezervujte prostor předem. Použijte `width` a `height` nebo stabilní `aspect-ratio`, dejte reklamám a embedům předvídatelné rozměry a nevkládejte obsah nad text, který už uživatel čte. [10]
U fontů omezte rozdíly metrik mezi fallbackem a finálním fontem a měřte reálný dopad. `font-display` sám neřeší každý problém. [10]
Terénní a laboratorní data
Core Web Vitals jsou primárně terénní metriky. CrUX a vlastní RUM ukazují reálné uživatele, Lighthouse pomáhá řízeně reprodukovat a diagnostikovat. [11][12]
Lighthouse neměří plné přirozené INP a používá mimo jiné TBT jako laboratorní proxy. Laboratorní CLS může být nižší, pokud posuny nastávají až po interakci. [11][12]
Terénní data rozhodují, zda problém skutečně existuje, laboratoř pomáhá najít příčinu.
Který nástroj použít
| Nástroj | Typ dat | Nejlepší použití |
|---|---|---|
| PageSpeed Insights | CrUX + Lighthouse | Rychlá kontrola URL a originu |
| Search Console | CrUX, skupiny URL | Hledání skupin stránek s SEO problémy |
| Chrome DevTools | Laboratoř + CrUX kontext | Detailní diagnostika LCP, INP a CLS |
| Lighthouse | Laboratoř | Automatické audity a CI regrese |
| RUM / web-vitals | Vlastní uživatelská data | Nejpřesnější monitoring po vydání |
PageSpeed Insights kombinuje CrUX a Lighthouse. Search Console seskupuje podobné URL. DevTools nabízí živé metriky a detailní trace. [12][13]
CrUX API a PageSpeed Insights používají zhruba 28denní klouzavé okno. Nová oprava proto veřejný p75 nezmění hned. Vlastní RUM reaguje rychleji. [12][13]
Dobrý proces používá RUM pro monitoring, Search Console pro SEO skupiny, PSI pro rychlé kontroly a DevTools pro diagnózu.
CrUX v roce 2026: aktuální stav webu
| Metrika | Originy s dobrým výsledkem, červenec 2026 |
|---|---|
| LCP | 68,3% |
| INP | 85,7% |
| CLS | 81,6% |
| Všechny Core Web Vitals | 55,7% |
Poslední měsíční dataset vydaný před 4. zářím 2026 pokrývá červenec 2026 a vyšel 11. srpna. Obsahuje 18 059 068 originů. 68,3% mělo dobré LCP, 81,6% dobré CLS, 85,7% dobré INP a 55,7% splnilo všechny Core Web Vitals. [14]
Jde o agregovaná data webu v CrUX, ne cíle pro jeden web. CrUX zahrnuje pouze způsobilé veřejně zjistitelné a dostatečně populární stránky a originy. [13][14]
Chybějící data CrUX neznamenají rychlost ani pomalost, jen nedostatek způsobilých dat.
SPA a soft navigations: důležitá změna v roce 2026
Historicky byly Core Web Vitals orientované na plné navigace dokumentu. Chrome 151 v roce 2026 zavedl nové API pro měření soft navigations a dokumentace byla aktualizována 2. září 2026. [15]
Chrome DevTools 152 z 25. srpna 2026 zobrazuje Core Web Vitals pro soft navigations v Live Metrics ve výchozím stavu pomocí `web-vitals` 6.0.0. [16]
Je to důležité pro React, Angular, Vue a další SPA. Nelze však automaticky předpokládat, že všechny veřejné CrUX reporty soft navigations už vyhodnocují stejně.
Produkční monitoring s kontextem
Veřejný p75 často ukáže problém bez přesné příčiny. Vlastní RUM může přidat LCP element a části, INP interakci, route, zařízení a verzi aplikace. web.dev doporučuje RUM jako doplněk CrUX. [3][8][12]
Označujte deploymenty verzí a porovnávejte distribuce před a po. Průměr může skrýt regresi na pomalejších zařízeních.
CI chrání před zjevnými laboratorními regresy, ale nenahrazuje produkční monitoring. [11][12]
Praktický plán zlepšení
Nejprve zjistěte, která metrika selhává na p75 a na jakých typech stránek. Zúžte problém pomocí RUM nebo CrUX, reprodukujte ho v DevTools, opravte konkrétní příčinu a sledujte po deployi. [12]
Pro LCP najděte dominantní část, pro INP skutečně pomalou interakci a pro CLS konkrétní posuny.
Potom ověřte laboratoř i terén. Veřejné CrUX reaguje se zpožděním, proto je RUM důležitý pro rychlou validaci.
- Nejprve identifikujte problém v terénních datech.
- Oddělte mobile a desktop.
- U LCP sledujte TTFB, discovery, transfer a render delay.
- U INP analyzujte interakci a její tři části.
- U CLS zaznamenejte posuny během celé relace.
- Nasaďte jednu měřitelnou opravu a porovnejte před a po.
- Udržujte RUM a alerty regresí.
