Google v roce 2021 zavedl Core Web Vitals jako přímý rankingový faktor. Weby, které tyto metriky plní, mají měřitelnou výhodu ve vyhledávání oproti webům, které je neplní. A přesto zůstává pro naprostou většinu českých firemních webů Core Web Vitals nevyřešená oblast — podle dat Googlu splňuje "dobré" hodnoty ve všech třech metrikách méně než polovina webů na internetu.
Proč to zákazníky firem zajímá: Core Web Vitals nejsou jen SEO záležitost. Přímo korelují s konverzemi. Google zaznamenal, že weby s dobrými Core Web Vitals mají o 24 % nižší opuštění stránky a výrazně vyšší konverzní poměr. Pomalý web, který se "skáče" při načítání, zákazníky doslova odrazuje od kontaktu.
Tři metriky Core Web Vitals
LCP: Largest Contentful Paint
LCP měří, jak rychle se načte největší viditelný prvek na stránce. Nejčastěji je to hero obrázek nebo velký nadpis v horní části stránky. Čím dříve zákazník vidí hlavní obsah, tím lépe.
Hodnotící škála:
- Dobrá: LCP ≤ 2,5 sekundy
- Potřebuje zlepšení: 2,5–4,0 sekund
- Špatná: LCP > 4,0 sekund
Prakticky: zákazník klikne na váš odkaz ve výsledcích Googlu. Za 2,5 sekundy by měl vidět hlavní obrázek nebo nadpis vaší homepage. Pokud to trvá 5 sekund, polovina zákazníků stránku opustí ještě před tím, než ji vidí.
INP: Interaction to Next Paint
INP (Interaction to Next Paint) nahradil v březnu 2024 původní metriku FID (First Input Delay). Měří, jak rychle web reaguje na uživatelskou interakci — kliknutí, tapnutí, stisk klávesy. Konkrétně: jak dlouho trvá, než se stránka vizuálně "odezví" na akci zákazníka.
Hodnotící škála:
- Dobrá: INP ≤ 200 ms
- Potřebuje zlepšení: 200–500 ms
- Špatná: INP > 500 ms
Prakticky: zákazník klikne na tlačítko "Zobrazit více" nebo vyplní pole formuláře. Pokud stránka nereaguje vizuálně do 200 ms, zákazník neví, zda kliknutí fungovalo, a klikne znovu (nebo odejde). INP je nejnovější z Core Web Vitals a zároveň ten, se kterým má nejméně webů dobré výsledky.
CLS: Cumulative Layout Shift
CLS měří, jak moc se stránka "skáče" a přeskakuje během načítání. Klasický scénář: čtete text, načte se obrázek, celý obsah se posune o 200 px dolů a kliknete na nesprávné tlačítko. Nebo reklamní banner se načte a stlačí celý obsah. CLS měří kumulativní součet těchto posunutí.
Hodnotící škála:
- Dobrá: CLS ≤ 0,1
- Potřebuje zlepšení: 0,1–0,25
- Špatná: CLS > 0,25
CLS je jediná metrika bez časové dimenze — měří vizuální stabilitu, ne rychlost.
Jak zjistit hodnoty Core Web Vitals pro váš web
Google PageSpeed Insights
Přejděte na pagespeed.web.dev, zadejte URL a klikněte Analyze. Zobrazí dvě sady dat:
Field data (reálná data) — data nasbíraná ze skutečných návštěv vašeho webu za posledních 28 dní, z Chrome User Experience Report (CrUX). Toto jsou data, která Google používá pro rankingový faktor. Zobrazují se jen pro weby s dostatečným provozem.
Lab data (laboratorní data) — simulace načítání v kontrolovaném prostředí (Lighthouse). Rychlejší k získání, ale méně přesná — nezohledňuje reálné podmínky sítě a zařízení.
Pro rankingové účely záleží na field data. Lab data jsou užitečná pro diagnostiku a měření dopadu oprav.
Google Search Console: Core Web Vitals report
V GSC přejděte na Základní metriky webu (Core Web Vitals). Report ukáže:
- Celkový stav webu (kolik URL je "Dobrých," "Potřebuje zlepšení," "Špatných")
- Rozdělení na desktop vs. mobil — mobilní hodnoty jsou typicky horší
- Konkrétní URL s problémy a typ problému (špatné LCP, špatné INP atd.)
GSC report pracuje s field daty — reálnými měřeními od skutečných uživatelů. Je to nejspolehlivější zdroj pro pochopení skutečného stavu.
Lighthouse v Chrome DevTools
Pro vývojáře a rychlé testování: otevřete Chrome DevTools (F12), záložka Lighthouse, spusťte audit. Výsledkem je detailní report s hodnotami a doporučeními.
Výhoda: funguje na libovolném URL, nevyžaduje dostatečný provoz pro CrUX data, ukáže konkrétní příčiny problémů.
Nevýhoda: laboratorní podmínky — výsledky se liší od reálných field dat, závisí na výkonu počítače, na kterém běží.
WebPageTest
Detailnější analýza na webpagetest.org — vodopádový diagram načítání, filmstrip (screenshoty v čase jak se stránka načítá), testování z různých lokací a na různých typech sítí. Pro hlubší debugging specifických problémů.
Nejčastější příčiny špatného LCP
Neoptimalizované obrázky
Příčina číslo jedna špatného LCP napříč weby. Hero obrázek jako PNG o velikosti 2–5 MB místo WebP pod 200 kB zvýší LCP o 2–4 sekundy.
Moderní formáty:
- WebP — 25–35 % menší než JPEG při stejné vizuální kvalitě. Podporují ho všechny moderní prohlížeče.
- AVIF — 50 % menší než JPEG, ale pomalejší enkódování a starší prohlížeče ho nepodporují. Použijte s fallback na WebP.
Jak opravit: v Next.js jsou optimalizované obrázky zabudované (komponenta Image automaticky servíruje WebP). Ve WordPressu použijte plugin jako Smush nebo ShortPixel. Pro manuální konverzi: Squoosh.app (zdarma, online nástroj).
Chybějící preload pro hero obrázek
Prohlížeč zpracovává HTML, pak CSS, a teprve pak nalezne hero obrázek v CSS jako background-image — a začne ho stahovat. Toto zpoždění může přidat 0,5–1,5 sekundy k LCP.
Oprava: přidejte <link rel="preload"> do <head> pro hero obrázek, nebo použijte HTML <img> s atributem fetchpriority="high" místo CSS background. Next.js komponenta Image s priority={true} toto řeší automaticky.
Pomalý hosting a TTFB
TTFB (Time to First Byte) je čas, za který server odpoví na první request. Levný sdílený hosting v ČR má TTFB typicky 600–1200 ms. Vercel nebo Cloudflare Pages mají TTFB 50–200 ms.
Vysoké TTFB se projeví přímo v LCP — server, který reaguje za 800 ms, nemůže mít LCP pod 2,5 sekundy.
Pro WordPress: serverové caching (WP Rocket, LiteSpeed Cache), CDN (Cloudflare je zdarma pro základní použití). Pro Next.js: deployment na Vercel nebo AWS.
Blokující JavaScript a CSS
Skripty načítané bez atributu async nebo defer blokují vykreslení stránky — prohlížeč čeká, až se skript stáhne a spustí, než pokračuje v renderování HTML.
Analytika, třetí stránkové skripty, live chat widgety — tyto skripty by měly být načítány async nebo odloženy na moment po načtení hlavního obsahu. Google Tag Manager umožňuje zpoždění tagů pomocí "Trigger > Delay" nebo custom HTML.
Nejčastější příčiny špatného INP
INP problémy jsou způsobeny výpočetně náročným JavaScriptem, který blokuje hlavní vlákno (main thread). Když zákazník klikne na tlačítko, prohlížeč musí dokončit aktuálně probíhající JavaScript kód, než zpracuje interakci.
Těžké JavaScript frameworky s příliš velkými bundly
React, Vue, Angular — každý přidává JavaScript, který se musí spustit při načtení. Velké JS bundly znamenají delší dobu inicializace a horší INP.
Oprava: code splitting (rozdělení JS do menších chunks, které se načtou jen když jsou potřeba), tree shaking (odstranění nepoužívaného kódu), lazy loading komponent. Next.js a Vite toto řeší automaticky při správné konfiguraci.
Analytické a marketingové skripty
Meta Pixel, Google Tag Manager se spoustou tagů, Hotjar, live chat — každý přidává JavaScript, který běží na hlavním vlákně. Kumulativní efekt může výrazně prodloužit INP.
Auditujte, které skripty skutečně potřebujete. Každý nepotřebný skript odstraňte. Používejte Google Tag Manager s pravidlem "Načíst po interakci uživatele" pro méně kritické skripty.
Zbytečné rerenderování v Reactu
React komponenty, které se rerenderují při každé malé změně stavu, mohou způsobovat INP problémy na komplexnějších stránkách. Řešení: React.memo, useMemo, useCallback pro optimalizaci rerenderování.
Nejčastější příčiny špatného CLS
Obrázky bez definovaných rozměrů
Nejčastější příčina CLS. Pokud <img> nemá atributy width a height, prohlížeč neví, kolik místa vyhradit pro obrázek, než se stáhne. Když se obrázek načte, posune celý obsah pod sebou.
Oprava: vždy definujte width a height na obrázku (nebo použijte CSS aspect-ratio). Next.js komponenta Image toto řeší automaticky. Ve WordPressu: moderní verze automaticky přidávají rozměry, starší verze nebo pluginy je mohou vynechat.
Webfonty s viditelným "flash"
Webfonty se stahují asynchronně. Dokud se font nestáhne, prohlížeč zobrazí text systémovým fontem (nebo ho skryje). Když font přijde, text "přeskočí" — změní se font, změní se layout.
Oprava: font-display: swap v CSS (nebo font-display: optional pokud je layout kritický). Google Fonts automaticky přidávají font-display=swap při správném načítání. Preload klíčových fontů: <link rel="preload" as="font">.
Reklamy a embeds bez rezervovaného prostoru
Reklamní bannery, embed YouTube videa, Twitter widgety — pokud se načtou po hlavním obsahu a nemají rezervované místo v layoutu, způsobí CLS.
Oprava: vždy rezervujte prostor pro asynchronně načítané prvky pomocí CSS min-height nebo aspect-ratio. Pro reklamní sloty: pevné rozměry banneru, i když je slot prázdný.
Dynamicky vkládaný obsah
JavaScript, který přidává obsah nad existující prvky (notifikace, bannery, cookie lišty) po načtení stránky, způsobuje CLS.
Oprava: bannery a notifikace rezervujte v layoutu ještě před načtením stránky, nebo je umísťujte tak, aby neposouvaly existující obsah (fixní pozice).
Realistická očekávání a prioritizace
Pro moderní weby na Next.js a Vercel jsou dobré Core Web Vitals přirozeným výsledkem správné implementace. Problémy jsou spíš výjimkou.
Pro WordPress weby je cesta delší. Výchozí instalace WordPressu s populárními page buildery (Elementor, Divi) a množstvím pluginů má typicky špatné hodnoty bez aktivní optimalizace. S kombinací cachingového pluginu (WP Rocket), CDN (Cloudflare), optimalizace obrázků a auditu JavaScriptu se dá dostat na dobré hodnoty — ale vyžaduje to průběžné úsilí.
Pro starší PHP weby na sdíleném hostingu: základní optimalizace přinesou zlepšení, ale dosáhnout "dobrých" hodnot ve všech třech metrikách může vyžadovat migraci na modernější infrastrukturu.
Prioritizace oprav: zlepšení LCP přináší největší dopad na konverze (zákazník vidí obsah dřív), zlepšení CLS zlepšuje vnímání kvality (žádné přeskakování), zlepšení INP zlepšuje interaktivitu (formuláře, klikání).
V Appitect stavíme weby na Next.js s Core Web Vitals jako standardem. Každý projekt měříme před a po launchi. Pokud váš web má špatné skóre a nevíte, kde začít, ozvěte se — audit Core Web Vitals je součástí naší úvodní konzultace.
