Technické SEO

Core Web Vitals: kompletní průvodce

Metriky, měření a optimalizace LCP, INP a CLS. Průvodce zahrnuje přechod na INP v březnu 2024.

metriky Page Experience

75 %

návštěv musí splnit práh

2021

CWV jako ranking faktor

28 dní

okno CrUX dat v GSC

Konzultace zdarma SEO služby →

Co jsou Core Web Vitals

Co jsou Core Web Vitals a proč je Google zavedl

Core Web Vitals jsou sada tří metrik měřících uživatelský zážitek z pohledu rychlosti načítání, interaktivity a vizuální stability stránky. Na rozdíl od dřívějších rychlostních měřítek jako PageSpeed skóre nebo Time to Interactive jsou CWV navrženy tak, aby co nejlépe odrážely, jak stránku skutečně vnímá návštěvník.

Google je oznámil v roce 2020 a jako přímý ranking faktor nasadil v květnu 2021. Logika za tím rozhodnutím je přímočará: čím lepší zážitek stránky, tím déle na nich uživatelé zůstávají a tím je pro Google hodnotnější je zobrazovat.

Důležité upřesnění: CWV nejsou jediný ranking faktor. Jsou součástí širšího signálu Page Experience, který zahrnuje také HTTPS, mobilní přívětivost a absenci rušivých překryvných prvků. Samotný obsah, relevance a autorita stránky stále hrají dominantní roli. CWV jsou hygienický faktor: špatné skóre tě poškodí, ale perfektní skóre samo o sobě tě nevyhraje.

Zásadní změna: 12. března 2024

Google nahradil metriku FID (First Input Delay) novou metrikou INP (Interaction to Next Paint). FID měřil jen zpoždění první interakce a navíc jen samotné zpoždění vstupu, nikoliv celkovou dobu odezvy. INP sleduje všechny interakce po celou dobu návštěvy.

Tato změna se zatím neprojevila v naprosté většině českých SEO článků.

Jak číst tento průvodce

Pokud jsi tu poprvé, začni u přehledové tabulky metrik v druhé sekci. Pokud optimalizuješ konkrétní problém, přejdi rovnou na sekci LCP, INP nebo CLS.

Na konci najdeš přehled 10 měřicích nástrojů, FAQ a aktualizovaný slovníček pojmů.

Přehled metrik

Tři metriky Core Web Vitals: aktuální přehled

Každá metrika měří jiný aspekt uživatelského zážitku. Aby Google vyhodnotil URL jako „Good“, musí všechny tři metriky dosahovat prahové hodnoty alespoň u 75 % reálných návštěv.

Metrika	Co měří	Good ✅	Needs Improvement ⚠️	Poor ❌
LCP	Rychlost načtení největšího prvku	do 2,5 s	2,5 s až 4 s	nad 4 s
INP	Odezva na všechny interakce	do 200 ms	200 ms až 500 ms	nad 500 ms
CLS	Vizuální stabilita obsahu	pod 0,1	0,1 až 0,25	nad 0,25

75. percentil, ne průměr: Google hodnotí stránky na základě 75. percentilu CrUX dat. To znamená, že 25 % návštěv může být pomalejších, aniž by to ovlivnilo hodnocení. Pokud má URL status „Poor“ v jediné metrice, celá URL je hodnocena jako „Poor“, i když ostatní metriky jsou výborné.

První metrika

LCP (Largest Contentful Paint): rychlost načtení hlavního obsahu

LCP měří okamžik, kdy se ve viewportu uživatele vykreslí největší viditelný prvek stránky. Jinými slovy: kdy má návštěvník pocit, že stránka je načtená a může začít číst nebo nakupovat.

Nejčastějšími LCP kandináty jsou: hero obrázek nebo fotografie produktu, velký textový blok (H1 nebo úvodní odstavec), video thumbnail nebo pozadí vykreslené přes CSS. Google doporučuje hodnotu LCP do 2,5 sekundy pro alespoň 75 % návštěv.

Čtyři fáze LCP: kde vzniká problém

LCP není jeden okamžik. Skládá se ze čtyř po sobě jdoucích fází. Každá fáze má jiné příčiny a jiné řešení. Nejčastější chyba: tým stráví týdny kompresí obrázků (fáze 3), zatímco skutečný problém je ve fázi 1 nebo 2.

TTFB

Time to First Byte: čas od požadavku po první bajt HTML

Resource Load Delay

Čas mezi TTFB a zahájením stahování LCP zdroje

Resource Load Duration

Samotný čas stahování LCP souboru

Element Render Delay

Čas od stažení po skutečné vykreslení na obrazovce

Fáze 1: TTFB

Čas od požadavku uživatele po přijetí prvního bajtu HTML odpovědi ze serveru. Pokud je TTFB nad 800 ms, je téměř nemožné dosáhnout dobrého LCP. Weby s špatným LCP mají medián TTFB přes 2,27 sekundy, což samo o sobě překračuje celý povolený LCP budget.

Příčiny: pomalý server, absence cache, velká vzdálenost od serveru.

Fáze 2: Resource Load Delay

Čas mezi TTFB a okamžikem, kdy prohlížeč začne stahovat LCP zdroj. Tato fáze se často přehlíží. Pokud je LCP prvek obrázek načítaný přes CSS background-image nebo přes JavaScript, prohlížeč ho nemůže objevit včas a čeká. Zpoždění v této fázi může snadno přidat 500 ms i více.

Fáze 3: Resource Load Duration

Samotný čas stahování LCP souboru. Ovlivňuje ho velikost souboru, kompresní formát a rychlost sítě. Tato fáze je nejčastěji optimalizována, ale data z CrUX ukazují, že ve většině případů není hlavním viníkem.

Fáze 4: Element Render Delay

Čas od dokončení stahování po skutečné vykreslení prvku na obrazovce. Prohlížeč má soubor stažený, ale main thread je zahlcen JS úlohami nebo blokujícím CSS. Obrázek leží v paměti a čeká, až bude prostor ho vykreslit.

Jak optimalizovat LCP: 10 konkrétních kroků

Krok 1

fetchpriority=“high“ na hero obrázek

Řekni prohlížeči explicitně, že tento zdroj má absolutní prioritu. Jde o nejjednodušší a nejefektivnější optimalizaci, kterou lze nasadit okamžitě bez vedlejších efektů.

Krok 2

<link rel=“preload“ as=“image“> v hlavičce

Pro obrázky, které prohlížeč nenajde rychle v HTML (například přes srcset). Předlod stahování dřív, než prohlížeč narazí na img tag.

Krok 3

Nikdy loading=“lazy“ na LCP element

Lazy loading je skvělý nástroj, ale na LCP element je katastrofa. Prohlížeč pak čeká, místo aby stahoval. Tato chyba se podle HTTP Archive Almanac 2025 vyskytuje na 16 % mobilních stránek.

Krok 4

Moderní formáty obrázků

WebP místo JPEG/PNG, AVIF pro ještě lepší kompresi. Zachovej stejnou vizuální kvalitu při výrazně menší velikosti souboru.

Krok 5

Správné width a height atributy

Prohlížeč pak dopředu rezervuje prostor a eliminuje layout shift. Ovlivňuje také CLS příznivě.

Krok 6

Zlepšení TTFB

Správný hosting, serverová cache (full-page cache), CDN pro geograficky vzdálené uživatele. Pokud TTFB přesahuje 800 ms, nic jiného LCP nezachráni.

Krok 7

Odstraň render-blocking CSS a JS

Skripty v <head> bez defer nebo async blokují vykreslování. Přesuň nekritický JS na konec dokumentu nebo použij defer.

Krok 8

Preconnect pro třetí strany

Krok 9

Ověř, zda LCP není za lazy-loaded komponentou

JavaScript frameworky (React, Vue) někdy renderují hero sekci klientsky, takže prohlížeč nevidí LCP prvek v původním HTML. Zkontroluj view-source a zdrojový kód.

Krok 10

Spekulativní předrenderování pro klíčové stránky

Speculation Rules API umožňuje předrenderovat stránky, na které uživatel pravděpodobně přejde. Pro e-shopy: produktové stránky z výpisu kategorií.

Druhá metrika

INP (Interaction to Next Paint): odezva na interakce

INP měří, jak rychle stránka viditelně reaguje na interakci uživatele: kliknutí, klepnutí nebo stisk klávesy, a to po celou dobu jeho návštěvy. Jde o metriku, která od 12. března 2024 nahradila FID.

Proč Google nahradil FID metrikou INP

First Input Delay (FID) měřil pouze zpoždění zpracování první interakce na stránce a navíc jen samotné zpoždění vstupu, nikoliv celkovou dobu odezvy. Výsledkem bylo, že stránka mohla mít výborné FID, ale přesto reagovat pomalu na všechny ostatní kliky během návštěvy.

INP řeší oba problémy najednou. Sleduje všechny interakce po celou dobu návštěvy a jako výsledné skóre reportuje nejhorší reprezentativní interakci. Zobrazuje tak skutečný pocit ze svižnosti celého webu, nejen první dojem.

Tři fáze každé interakce: Input Delay (čas od interakce po spuštění event handleru) + Processing Time (zpracování handleru) + Presentation Delay (čas vykreslení výsledku). Cílem je minimalizovat každou z nich.

Nejčastější příčiny špatného INP

Long Tasks na main thread JS úlohy trvající déle než 50 ms. Zatímco prohlížeč zpracovává dlouhou úlohu, nemůže reagovat na kliknutí.
Těžké page buildery Elementor, Divi nebo komplexní React aplikace mohou generovat úlohy blokující main thread stovky milisekund.
Skripty třetích stran Live chat, analytika, reklamní sítě. Tyto skripty se inicializují ve stejný moment, kdy uživatel poprvé interaguje s webem.
Velký DOM Strom s tisíci elementů zpomaluje každý layout a paint po interakci.
Komplexní event handlery Zpracování formuláře nebo filtrování produktů, které synchronně přepočítává celé UI.

Jak optimalizovat INP: 8 kroků

Identifikuj Long Tasks v Chrome DevTools Performance panel > spusť záznam > interaguj se stránkou > hledej červené bloky nad 50 ms. Toto je tvůj vstupní bod.
Rozděluj dlouhé JS úlohy Použij scheduler.yield() nebo setTimeout s 0 ms prodlevou. Prohlížeč pak dostává prostor reagovat na vstupy mezi úlohami.
Odlož inicializaci třetích stran Live chat a analytiku inicializuj až po první interakci, nikoliv okamžitě při načtení. Uživatel nepostřehne 1 až 2 sekundy zpoždění live chatu, ale okamžitě pocítí pomalou reakci tlačítka.
Web Workers pro náročné operace Výpočty, parsování dat, filtrování. Web Worker běží v separátním vlákně a main thread zůstane volný.
Minimalizuj DOM size Strom s více než 1 400 elementy začíná viditelně zpomalovat layout. Odstraň nepotřebné wrappery a skryté elementy.
Nahraď těžké page buildery Pokud Elementor způsobuje INP přes 500 ms, je čas zvážit lehčí alternativu nebo vlastní šablonu.
Virtualizace pro dlouhé seznamy Výpisy produktů se stovkami karet bez virtualizace způsobují layout thrashing při každém scrollu.
Testuj na reálných zařízeních INP je výrazně horší na mid-range Android zařízeních s 4x CPU throttlingem. Vývojářský MacBook klame.

Třetí metrika

CLS (Cumulative Layout Shift): vizuální stabilita obsahu

CLS měří, jak moc se obsah stránky neočekávaně posouvá během načítání a po něm. Každý neočekávaný posun je frustrující: uživatel čte text, stránka se posune a klikne na špatný odkaz, nebo klikne na tlačítko, které přeskočí dolů.

Jak se CLS skóre počítá

CLS skóre je součet všech neočekávaných layout shiftů během návštěvy. Každý shift se počítá jako: impact fraction (jakou část viewportu prvek posunul) × distance fraction (jak daleko se posunul). Čím větší prvek a čím dále se posune, tím větší příspěvek do CLS skóre.

Pozor: animace a přechody spuštěné interakcí uživatele (klik, scroll) se do CLS nepočítají. Pouze neočekávané posuny bez uživatelské akce.

Nejčastější příčiny vysokého CLS

Obrázky a videa bez definovaných rozměrů Prohlížeč nezná rozměry dopředu, takže vyhradí nulový prostor. Po načtení obrázku ostatní obsah odskočí dolů.
Reklamy a embedy vkládané dynamicky Obsah se načte po zbytku stránky a posune vše pod sebou.
Webfonty způsobující FOUT Systémový font se zobrazí okamžitě, poté ho nahradí webfont s jinými rozměry. Obsah se posune.
Cookie lišty a notifikační bannery Vkládané nad již vykreslený obsah.
Lazy-loaded obrázky bez placeholder Bez rezervovaného prostoru způsobují shift při načtení.

Jak optimalizovat CLS: 7 konkrétních kroků

Vždy definuj width a height atributy Moderní prohlížeče pak počítají aspect ratio dopředu a rezervují správný prostor.
Rezervuj prostor pro reklamy a bannery Pomocí min-height nebo aspect-ratio v CSS. I když je reklama prázdná, prostor zůstane rezervovaný.
Přednačti webfonty a nastav font-display: optional Prohlížeč použije webfont pouze pokud je dostupný do začátku renderingu, jinak zobrazí systémový font bez shiftu.
Vyhni se vkládání obsahu nad vykreslený obsah Cookie bannery a notifikační lišty zobrazuj jako overlay (position: fixed), ne jako součást flow dokumentu.
Animuj pouze transform a opacity Tyto CSS vlastnosti nevyžadují přepočet layoutu. Nikdy neanimuj top, left, width, height, každá změna spustí reflow.
Zkontroluj embedy YouTube iframe, Google Maps, sociální tlačítka. Wrapper s pevným aspect-ratio zabrání shiftu při jejich načtení.
Použij aspect-ratio v CSS Elegantně nahrazuje starou techniku padding-top hack a funguje ve všech moderních prohlížečích.

Měření

Field data vs. lab data: proč PSI ukazuje jiné číslo než Lighthouse

Toto je jeden z nejčastějších zdrojů zmatení: Lighthouse ukazuje skóre 95, ale v PSI sekci „Data pole“ je stránka označena jako „Needs Improvement“. Která hodnota je správná? Pro účely rankingu platí výhradně field data.

Laboratorní data (Lab)

Co jsou lab data

Lab data jsou výsledky simulovaného měření v kontrolovaném prostředí. Lighthouse simuluje pomalé mobilní připojení (typicky 4G Slow emulace) a méně výkonný CPU. Měření je deterministické: spustíš ho znovu a dostaneš podobný výsledek.

Jsou skvělé pro diagnostiku a vývojářské testování, ale neodráží skutečné chování na různých zařízeních a sítích.

Reálná data (Field / CrUX)

Co jsou field data

Field data pochází z reálných návštěv uživatelů v Chrome prohlížeči. Google je sbírá do databáze Chrome User Experience Report (CrUX) jako klouzavé 28denní okno. Zahrnují všechny typy zařízení, sítí i rychlostí připojení, které tvoji uživatelé skutečně používají.

Google tyto data používá pro vyhodnocení CWV rankingového signálu. Pokud tvůj web nemá dostatek návštěv z Chrome, CrUX data nejsou k dispozici.

Proč se liší

Lab data simulují jeden konkrétní scénář. Field data zahrnují skutečnou diverzitu zařízení, sítí a chování uživatelů.
Lighthouse měří „studené“ načtení bez cache. Reálný uživatel může mít část zdrojů v cache.
CrUX data zahrnují i pomalé návštěvy z 2G/3G sítí nebo starých zařízení. Lighthouse tyto scénáře neemuluje přesně.
Pokud web načítá personalizovaný obsah po přihlášení, CrUX data mohou zahrnovat tyto pomalejší varianty.

Jak měřit

Kde a jak Core Web Vitals měřit: přehled 10 nástrojů

Různé nástroje slouží k různým účelům. Základní pravidlo: pro monitoring a SEO rozhodnutí používej nástroje s field daty. Pro diagnostiku problémů a ladění sáhni po laboratorních nástrojích.

Nástroj	Typ dat	Zobrazuje INP	Vhodný pro
PageSpeed Insights	Field + Lab	✅ Ano	Rychlý audit URL
Google Search Console	Field (CrUX)	✅ Ano	Monitoring celého webu
CrUX Dashboard	Field (CrUX)	✅ Ano	Historický přehled
Lighthouse	Lab	⚠️ Částečně	Diagnostika, vývoj
WebPageTest	Lab	✅ Ano	Pokročilá analýza
Chrome DevTools	Lab	✅ Ano	Debugging Long Tasks
Web Vitals Extension	Field (real-time)	✅ Ano	Real-time procházení
DebugBear	Lab + monitoring	✅ Ano	Dlouhodobý monitoring
GTmetrix	Lab	✅ Ano	Waterfall analýza
Screaming Frog	Lab (PSI API)	✅ Ano	Audit celého webu najednou

Jak správně pracovat s klíčovými nástroji

PageSpeed Insights (PSI)

Vždy se dívej do sekce „Data pole“ jako první. Sekce „Laboratorní data“ ti dá tipy, co optimalizovat, ale neříká ti, jak tě Google vidí. Pokud URL nemá dostatek CrUX dat, uvidíš varování. To neznamená, že web je rychlý, ale že Google nemá dostatek dat.

Google Search Console

CWV report sdružuje URL do skupin (podobné typy stránek). Status skupiny je nejhorší metrika skupiny: pokud má jedna URL špatné CLS, celá skupina je označena jako „Poor“. V Google Search Consolenajdi konkrétní problém a prozkoumej, které URL ho reprezentují.

Chrome DevTools: Performance panel

Pro diagnostiku INP: spusť nahrávání v inkognito okně bez extensions, interaguj se stránkou, zastav záznam. Long Tasks jsou zobrazeny jako červené bloky. V záložce „Timings“ vidíš LCP event a jeho fáze.

Lighthouse

Vždy spouštěj v inkognito režimu bez Chrome extensions: každá extension ovlivňuje výsledek. Záložka „Opportunities“ ukazuje, co optimalizovat pro LCP. „Diagnostics“ odhalí problémy s CLS a INP.

Vliv na ranking

Core Web Vitals a SEO: jak velký vliv mají na ranking

Přímý vliv: CWV jsou potvrzený ranking faktor od května 2021. Google opakovaně zdůraznil, že relevantní stránka s horším UX může stále rankovat výše než irelevantní stránka s perfektními metrikami. CWV jsou jen jedním ze stovek signálů.

V praxi to znamená: pokud máš skvělý obsah a špatné CWV, pravděpodobně rankuješ, ale přicházíš o pozice tam, kde je konkurence jinak srovnatelná. Nepřímý vliv je ale podstatný: lepší LCP a INP vedou k nižší míře odchodů, delšímu času strávenému na stránce a vyšší pravděpodobnosti konverze.

Page Experience signál: širší kontext

CWV jsou součástí Page Experience signálu, který zahrnuje:

Core Web Vitals LCP, INP, CLS
HTTPS šifrované připojení
Mobile-friendly stránka se správně zobrazuje na mobilních zařízeních
Absence intrusive interstitials vyskakovací okna přes celou obrazovku zakrývající obsah
Safe browsing absence malwaru a phishingu

Praktický závěr: jestliže splňuješ CWV, ale web nemá HTTPS nebo má agresivní cookie banner přes celý obsah, Page Experience signál může být stále negativní.

Podle platformy

Core Web Vitals podle platformy: praktické rady

Optimalizační možnosti závisí výrazně na tom, na jaké platformě web běží. Níže jsou nejčastější scénáře v českém prostředí.

WordPress

WordPress je nejrozšířenější platforma, ale také nejčastější zdroj problémů s CWV. Hlavní důvod: page buildery.

Elementor, Divi a WPBakery generují nadbytečný JavaScript a CSS, který výrazně zhoršuje INP a LCP.
Doporučené caching pluginy: WP Rocket, LiteSpeed Cache (pokud server podporuje LiteSpeed), W3 Total Cache.
Doporučené pluginy pro optimalizaci obrázků: Smush, ShortPixel, Imagify. Vždy ověř, že plugin neaplikuje lazy loading na hero obrázek.
Plugin Perfmatters nebo Asset CleanUp slouží k odstranění zbytečných CSS a JS skriptů, které WordPress načítá na každé stránce.
Výběr šablony je kritický. Před koupí otestuj demo šablony v PSI. Hodnota LCP nad 3 s v demo prostředí bude na produkčním serveru pravděpodobně horší.

Shoptet

Šablona a serverová infrastruktura jsou řízeny platformou. Majitel webu je nemůže přímo ovlivnit.

Klíčová oblast vlivu majitele: optimalizace obrázků produktů a bannerů. Velké, nekomprimované bannery jsou nejčastější příčina špatného LCP na Shoptetu.
Skripty třetích stran: live chat, Heureka widget, Zboží.cz konverzní pixel. Každý přidaný skript zatěžuje main thread a zhoršuje INP.
Sleduj CWV skóre po každém přidání nové třetí strany nebo aplikace z Shoptet App Store.

Headless a vlastní řešení (Next.js, Nuxt, Astro)

Nejlepší výchozí podmínky: statické HTML, built-in image optimization, code splitting.

Client-side hydration v React/Next.js může způsobit vysoké INP, protože JS framework přebírá správu stránky po načtení.
Astro generuje statický HTML bez JS pro statický obsah. Výborná výchozí pozice pro CWV.
Vždy měř INP po nasazení nové verze. Framework update může výrazně změnit výkon.

SaaS e-commerce platformy (Shopify, Upgates)

U SaaS platforem platí jedno společné pravidlo: serverová infrastruktura, core kód a cache je v rukou platformy.

Tvoje odpovědnost je v oblasti obsahu: obrázky produktů, bannery, skripty třetích stran a konfigurace aplikací.
Každá nová aplikace nebo integrace může výrazně ovlivnit INP. Měř před i po přidání.

Průběžná péče

Jak sledovat Core Web Vitals v čase a reagovat na zhoršení

Jednorázové měření nestačí. CWV se mění s každou aktualizací obsahu, pluginu nebo třetí strany. Níže jsou konkrétní doporučení pro průběžný monitoring.

Upozornění v Google Search Console

Nastav si emailová upozornění: Settings > Email preferences > Core Web Vitals alerts. GSC ti pošle email, pokud počet „Poor“ URL vzroste.

Frekvence auditů

Měsíčně pro aktivní weby s pravidelným vývojem nebo přidáváním obsahu. Čtvrtletně pro statické informační weby. Po redesignu nebo migraci vždy extra měření.

Každý nový plugin nebo script

Změř INP a LCP před a po přidání. Dopad může být okamžitý a překvapivý. CrUX data zaostávají za realitou o 28 dní, takže lab data jsou při ladění přesnější.

Nezapomeň: GSC CWV report zaostává za realitou o 28 dní. Pokud provedeš opravu dnes, plné zlepšení uvidíš v reportu za měsíc. Průběžně měř v PSI a Chrome DevTools.

Potřebuješ pomoci s technickým SEO nebo auditovat celý web? Podívej se na naše SEO služby nebo si rovnou domluvte SEO konzultaci.

Časté dotazy

Nejčastější otázky o Core Web Vitals

CWV jsou potvrzený ranking faktor od května 2021, ale Google opakovaně zdůraznil, že jde o jeden ze stovek signálů. Relevantní obsah s horším skóre může stále rankovat výše než irelevantní stránka s perfektními metrikami. CWV jsou hygienický faktor: špatné skóre tě poškodí, perfektní skóre samo o sobě nevyhraje.

PageSpeed Insights v sekci „Data pole“ zobrazuje CrUX data za posledních 28 dní pro danou URL. Google Search Console agreguje data za URL skupiny (podobné stránky). Pokud stránka nemá dostatek návštěv pro CrUX, PSI zobrazí pouze laboratorní data. GSC vždy bere nejhorší metriku skupiny jako výsledný status.

Ne. Lighthouse je laboratorní nástroj: Google pro ranking používá výhradně field data (CrUX). Skóre 100 v Lighthouse při slabých field datech rankingu nepomůže. Zaměř se na to, aby tvoje field data v PSI a GSC splňovala prahové hodnoty Good.

Web není zahrnut v CrUX databázi, protože nemá dostatečnou návštěvnost z Chrome prohlížeče. Google pak nemůže hodnotit tuto URL pomocí CWV rankingového signálu. Řešení: zvyš návštěvnost a sleduj, kdy se field data začnou zobrazovat.

First Input Delay (FID) byl oficálně nahrazen metrikouINP (Interaction to Next Paint) dne 12. března 2024. FID měřil pouze zpoždění první interakce, INP měří všechny interakce po celou dobu návštěvy. FID byl odstraněn z GSC reportu k datu přechodu.

Nejsnadněji v PageSpeed Insights: sekce „Největší prvek s obsahem“ ti ukáže přesný element. Alternativně v Chrome DevTools: Performance panel > spusť nahrávání > obnov stránku > v záznamu vyhledej LCP event. Web Vitals Chrome Extension zobrazí LCP element přímo při procházení stránky.

Google hodnotí mobil a desktop odděleně. V GSC reportu vidíš dvě separátní skupiny. Protože Google indexuje web primárně přes mobile-first indexing, mobilní CWV mají zpravidla větší vliv na ranking. Mobilní zařízení mají slabší CPU a pomalejší sítě: splnit prahové hodnoty na mobilu je náročnější.

CrUX data jsou klouzavé 28denní okno. Zlepšení provedené dnes se v GSC reportu plně projeví až po 28 dnech, kdy nová data zcela nahradí stará. Data se aktualizují průběžně, ale starší záznamy mají stále váhu.

Ne přímo. CWV jsou ranking faktor organického vyhledávání. Pro Google Ads existuje jiný systém hodnocení: Quality Score a Ad Rank, kde rychlost vstupní stránky hraje roli, ale jiným způsobem než u organiky.

Pokud stránka nemá dostatek dat v CrUX, Google ji nedokáže hodnotit přes CWV signál a přímý rankingový dopad je nulový. Přesto má smysl optimalizovat kvůli UX a pro případ, že návštěvnost v budoucnu poroste.

Pojmový aparát

Slovníček pojmů

Rychlý přehled technických termínů, které se v diskusích o Core Web Vitals opakují.

Pojem	Vysvětlení
AVIF	Moderní obrazový formát s lepší kompresí než WebP nebo JPEG. Ideální pro LCP obrázky.
CLS	Cumulative Layout Shift: metrika vizuální stability. Měří neočekávané posuny obsahu.
CrUX	Chrome User Experience Report: databáze reálných výkonnostních dat od Googlu.
CDN	Content Delivery Network: síť serverů doručující obsah z geograficky nejbližšího místa.
DevTools	Vývojářské nástroje zabudované v prohlížeči Chrome. Klíčový nástroj pro debugging.
fetchpriority	HTML atribut říkající prohlížeči, které zdroje stáhnout prioritně. Pro LCP obrázky: fetchpriority=“high“.
Field data	Data z reálných návštěv uživatelů (CrUX). Google je používá pro ranking.
FID	First Input Delay: zastaralá metrika nahrazená INP v březnu 2024.
FOIT / FOUT	Flash of Invisible/Unstyled Text: problémy při načítání webfontů způsobující CLS.
INP	Interaction to Next Paint: metrika odezvy na interakce. Nahradila FID v březnu 2024.
Lab data	Data z laboratorního prostředí (Lighthouse). Slouží k diagnostice, nikoliv rankingu.
Lazy loading	Technika odkládání načítání obrázků mimo viewport. Nikdy nepoužívat na LCP prvek!
LCP	Largest Contentful Paint: metrika rychlosti načtení největšího viditelného prvku.
Long Task	JS úloha trvající déle než 50 ms na main thread. Hlavní příčina špatného INP.
Main thread	Hlavní vlákno prohlížeče, které zpracovává JS, CSS a vykreslování. Může být zahlceno.
PSI	PageSpeed Insights: nástroj Googlu zobrazující field i lab data pro danou URL.
Preload	Hint prohlížeči, aby začal stahovat zdroj co nejdříve: <link rel=“preload“>.
TTFB	Time to First Byte: čas od požadavku po přijetí prvního bajtu HTML odpovědi ze serveru.
Viewport	Viditelná oblast prohlížeče. CWV metriky se měří v rámci tohoto prostoru.
Web Worker	JavaScript vlákno běžící mimo main thread. Pomáhá zlepšit INP u výpočetně náročných operací.
WebP	Moderní obrazový formát Googlu s lepší kompresí než JPEG při zachování kvality.
75. percentil	Google hodnotí URL podle hodnoty metriky, které dosahuje 75 % reálných návštěv. Ne průměr.

Autor článku

Samuel Krištof

CEO & CMO · PŘESAH.agency

SEO Online marketing Správa PPC Sociální sítě Emailing

Marketingu se věnuji od roku 2017. Začínal jsem ve Fajn skupině, kde jsem budoval komunity na Facebooku a záhy přešel k placeným kampaním. Postupně jsem se dostal k SEO, automatizacím a celkové správě marketingu. Dnes působím jako CEO agentury PŘESAH a zároveň jako externí CMO ve společnosti Bohemian Estates.

Obsah článku je ověřen vůči oficiálním zdrojům Google Search Central a web.dev.

Naposledy aktualizováno: březen 2026 | Obsah vychází z dat Google Search Central, web.dev a Chrome User Experience Report (CrUX).

Máš špatné CWV skóre? Pojďme se na to podívat.

Projdeme field data, identifikujeme největší brzdy a navrhneme postup, který dává smysl pro tvoji platformu.

Nezávazná konzultace →

SEO agentura SEO konzultace SEO Brno SEO Praha

Zdroje

Všechny informace v tomto článku jsou ověřeny z těchto primárních zdrojů:

Google Search Central: Core Web Vitals — přístup březen 2026
web.dev: Introducing INP as a Core Web Vital — přístup březen 2026
web.dev: Optimize Largest Contentful Paint — přístup březen 2026
web.dev: Common misconceptions about LCP subparts — přístup březen 2026
Google Search Central Blog: Introducing INP — přístup březen 2026
Google Search Console Help: Core Web Vitals report — přístup březen 2026
Chrome for Developers: LCP breakdown — přístup březen 2026
HTTP Archive Web Almanac 2025: Performance — přístup březen 2026