Core Web Vitals 2026: INP, LCP, CLS a co pro ně udělat tento týden

V březnu 2024 nahradilo INP (Interaction to Next Paint) starou metriku FID a od té doby se Core Web Vitals staly tvrdším testem než dřív. V roce 2026 už neměříme jen rychlost — měříme reálný uživatelský zážitek na milisekundy. Pokud váš web tyhle tři metriky nesplní, ztrácíte pozice v Googlu, citace v ChatGPT i konverze. V tomto návodu vám ukážu, jak je rychle změřit a opravit — bez programátora.

Co se v tomto článku dozvíte

• Jaké jsou aktuální prahy LCP, INP a CLS pro rok 2026
• Jak Core Web Vitals změřit za 3 minuty (4 nástroje)
• Konkrétní postupy, jak je opravit (s reálnými čísly z mého webu)
• Časté chyby, které propadnou v 8 z 10 auditů
• Proč na CWV teď čekají i AI vyhledávače jako ChatGPT a Perplexity

Proč to řešit zrovna teď

Tři důvody, proč jsou Core Web Vitals v 2026 důležitější než kdy předtím:

1. INP nahradil FID v březnu 2024. FID měřil jen první kliknutí. INP měří všechny interakce a bere 98. percentil. Web, který v FID prošel, v INP padá, protože se najednou počítají i pozdní kliky, kdy už váš JavaScript dělá těžké výpočty.
2. AI vyhledávače používají rychlost jako proxy pro kvalitu. ChatGPT Search, Perplexity i Google AI Overviews preferují weby, které stihnou vrátit čistý HTML rychle. Pomalý web znamená méně citací.
3. Google v 2026 zpřísnil prahy pro mobilní index. 75. percentil reálných uživatelů (z CrUX dat) rozhoduje, zda jste „Good", „Needs Improvement" nebo „Poor". Mít zelený Lighthouse v lab prostředí už nestačí.

Aktuální prahy 2026

Aby váš web v Google Search Console měl status „Good URL", musí 75 % reálných návštěv spadat do zelené (Good) zóny u všech tří metrik.

Krok 1: Změřte web za 3 minuty

Existují 4 nástroje, které stojí za to znát. Každý ukazuje něco jiného:

• PageSpeed Insights — pagespeed.web.dev — nejrychlejší rozkoukání, kombinuje lab data (Lighthouse) a reálná data (CrUX).
• Google Search Console → Core Web Vitals — agregovaná data za posledních 28 dní, podle URL skupin. Sem se podívejte, pokud chcete vidět, kde reálně přicházíte o pozice.
• Chrome DevTools → Lighthouse + Performance — pro debugging konkrétní stránky. Zapněte „Mobile" a „Slow 4G" před měřením.
• Web-vitals.js knihovna — pokud chcete posílat metriky do vlastního trackingu (GA4, Plausible). 4 řádky JavaScriptu na webu.

Tip: u nového webu nejdřív běžte do PageSpeed Insights. Až budete vědět, kde to drhne, otevřete DevTools a najděte konkrétního viníka.

Krok 2: Opravte LCP (Largest Contentful Paint)

LCP měří, jak rychle se zobrazí největší prvek nad ohybem — typicky hero obrázek, video poster nebo nadpis. V 80 % případů je problém v jednom z těchto bodů:

Hero obrázek

• Místo PNG nebo JPG použijte WebP nebo AVIF (50–80 % menší soubor při stejné kvalitě).
• Servírujte různé velikosti přes <img srcset="..."> — mobil nepotřebuje 2400 px obrázek.
• Přidejte fetchpriority="high" na hero obrázek a loading="eager" (ne lazy!).
• V hlavičce HTML preload klíčový obrázek: <link rel="preload" as="image" href="..." fetchpriority="high">.

Reálné čísla z webpj.cz: Hero obrázek na úvodní stránce měl 1,2 MB JPG. Po konverzi na AVIF a přidání srcset jsme šli z LCP 3,1 s na 1,4 s (mobilní 4G).

Server response time

Pokud váš TTFB (Time to First Byte) přesahuje 600 ms, máte problém na serveru — pomalá databáze, neoptimalizované PHP, nebo špatný hosting. Změřte to: v DevTools → Network → kliknete na první request → Timing → Waiting for server response.

• Zapněte HTTP cache v .htaccess nebo nginx (1 hodina pro HTML, 1 rok pro static).
• Použijte page cache (Redis, file cache) pro stránky, které se nemění.
• Zvažte CDN (Cloudflare zdarma, Bunny.net za pár dolarů).

Render-blocking CSS a JS

Velký style.css v hlavičce blokuje LCP. Řešení: critical CSS inline (jen těch 5–10 kB CSS, které potřebuje first paint) a zbytek <link rel="preload" as="style" onload="this.rel='stylesheet'">.

Krok 3: Opravte INP (Interaction to Next Paint)

INP je nová bestie. Měří, jak dlouho trvá od kliknutí (kbd-press, tap) k vykreslení další odpovědi. Pokud máte heavy JS, který blokuje main thread, INP propadne i na webu, který vypadá rychle.

Hlavní viníci

• Tagové manažery (GTM, Klaviyo, Hotjar, Intercom). Každý z nich přidává 50–200 ms na main thread po každé interakci.
• Third-party scripty (Facebook Pixel, Google Ads, chat widgety). Same problém.
• Nezvládnutý React/Vue rerender na velkých listech — když se filtruje 500 položek, INP letí ke 800 ms.
• Synchronní onClick handlery, které dělají těžké výpočty místo async/postpone.

Co s tím

• Defer všechen non-critical JS: <script src="..." defer> — neblokuje parsing.
• Použijte requestIdleCallback nebo setTimeout(fn, 0) pro výpočty, které nemusí proběhnout okamžitě.
• Virtualizujte dlouhé seznamy (knihovny: react-window, vue-virtual-scroller).
• Auditujte 3rd party v PageSpeed Insights → záložka „Third party usage". Často zjistíte, že jeden Hotjar pixel kazí celý web.

Reálný příklad z RealFree.cz: Klik na filtr „Praha + 5 km" trval 600 ms (INP Poor). Příčina — synchronní filtr přes 1200 nemovitostí. Po virtualizaci listu a přesunu filtru na server jsme šli na 120 ms (Good).

Krok 4: Opravte CLS (Cumulative Layout Shift)

CLS měří, kolik se vám během načítání „pohnula" stránka. Reklamní bannery, late-loading fonty a obrázky bez rozměrů jsou hlavní viníci.

Recept na nulový CLS

• Vždycky nastavte width a height u <img> a <video>. Browser pak zarezervuje místo dopředu.
• Reklamní sloty dejte do kontejneru s pevnou výškou (min-height: 250px).
• Fonty načítejte přes font-display: optional nebo swap a preload kritického fontu.
• Žádné dynamicky vkládané banner nad ohybem (cookie banner OK, ale přes overlay, ne push down).

Krok 5: Sledujte to v reálném provozu

Lighthouse v DevTools je lab data — měření v ideálních podmínkách na vašem počítači. Co rozhoduje, jsou field data — reálné hodnoty od skutečných uživatelů.

Dvě cesty:

1. Google Search Console → Page Experience → Core Web Vitals. Zdarma, agregované za 28 dní, podle URL groups. Doporučuji kontrolovat 1× týdně.
2. Vlastní RUM (Real User Monitoring). Stáhnete web-vitals.js (3 kB), pošlete hodnoty do GA4 nebo do vlastního endpointu. Vidíte přesně, které stránky a které segmenty (mobile/desktop) padají.

Časté chyby

• Optimalizujete jen úvodní stránku. Google indexuje všechno. Pokud máte 10 000 produktových stránek, optimalizujte šablony.
• Důvěřujete Lighthouse skóre 100/100. Lab data ≠ reálná data. Vždy zkontrolujte CrUX v PageSpeed Insights.
• Zapomenete na font swap. Custom font bez font-display může způsobit FOIT (Flash of Invisible Text) a CLS shift.
• Necháte cookie banner skákat. Banner, který se objeví po 500 ms a posune obsah, dá CLS 0,3.
• Nahrnete tagy přes GTM. 1 GTM container s 20 tagy = INP 400 ms. Lepší: server-side GTM nebo Plausible.

Nástroje, které doporučuju

• PageSpeed Insights — start auditu
• web.dev/measure — alternativa s detailem
• web-vitals.js — RUM v 3 kB
• Request Metrics — placený RUM, kvalitní vizualizace (od $30/mes)
• DebugBear — synthetic monitoring + CrUX history
• Cloudflare — zdarma CDN, automatický minify, Brotli

Případová studie: webpj.cz

Když jsem v lednu 2026 spouštěl tento web, dělal jsem v PageSpeed Insights tyto výsledky (mobilní):

• LCP: 3,4 s (Needs Improvement) — viník: nepřipravený hero obrázek
• INP: 380 ms (Needs Improvement) — viník: GTM s 8 tagy
• CLS: 0,18 (Needs Improvement) — viník: cookie banner skákal

Po optimalizacích podle bodů výše:

• LCP: 1,4 s (Good) — AVIF hero, srcset, preload
• INP: 140 ms (Good) — server-side GTM, lazy 3rd party
• CLS: 0,02 (Good) — cookie banner přes overlay, fixed height bannery

Výsledek: za 6 týdnů od optimalizace stoupla průměrná pozice v Search Console z 18,4 na 11,7 a počet klikátů +47 %.

Často kladené otázky

Co se stane, když nesplním Core Web Vitals?

Google vás nepenalizuje přímo, ale ztrácíte pozice v rankingu — Page Experience je jeden z hodnocených faktorů. V konkurenčních nikách dělá rozdíl mezi pozicí 5 a pozicí 12.

Stačí mít zelené skóre v Lighthouse?

Ne. Lighthouse je lab měření v ideálních podmínkách. Google rozhoduje podle field dat (CrUX) — reálných hodnot z prohlížečů Chrome uživatelů. Vždy ověřujte oboje.

Jak často mám Core Web Vitals měřit?

Search Console kontrolujte 1× týdně. Při velkém release (nový template, nový tag manager) zkontrolujte do 48 h, abyste zachytili regresi.

Pomáhá pomalý hosting?

Ano, dramaticky. Levné sdílené hosty mají TTFB často 800–1500 ms, což zabíjí LCP ještě před tím, než si váš kód něco řekne. Doporučuju Forpsi VPS, Hetzner Cloud nebo Cloudflare Workers pro statické weby.

Jaký je rozdíl mezi FID a INP?

FID měřil jen první interakci po načtení stránky. INP měří všechny interakce a vrací 98. percentil. INP odhalí problémy, které FID maskoval — pomalé filtry, lazy renderované komponenty, těžké onClick handlery.

Související články

• Jak zrychlit web: Průvodce Core Web Vitals (přehled)
• Jak připravit web pro vyhledávače od začátku
• Co je responzivní design a proč ho potřebujete