Core Web Vitals 2026: jak optimalizovat LCP, INP a CLS ve WordPressu

Core Web Vitals jsou tři čísla, podle kterých Google měří, jak dobře váš web slouží reálným uživatelům. V éře, kdy 53 % mobilních návštěvníků opouští web, který se nenačte do 3 sekund, a kdy AI nástroje preferují technicky bezchybné zdroje, se z Core Web Vitals stal jeden z nejdůležitějších technických signálů. V roce 2026 navíc pouze 47 % webů splňuje všechny tři metriky – to znamená obrovskou konkurenční příležitost pro ty, kdo se na ně zaměří. V tomto článku si vysvětlíme, co LCP, INP a CLS znamenají, jaké jsou prahové hodnoty a jak je optimalizovat ve WordPressu.

Co jsou Core Web Vitals

Core Web Vitals jsou tři metriky vyvinuté Googlem, které měří reálnou uživatelskou zkušenost na webu. Místo abstraktních „skóre rychlosti“ sledují tři konkrétní věci, které lidé na webu skutečně vnímají:

LCP (Largest Contentful Paint) – jak rychle se zobrazí hlavní obsah
INP (Interaction to Next Paint) – jak rychle web reaguje na klikání a interakce
CLS (Cumulative Layout Shift) – jak moc obsah „skáče“ během načítání

Google data o těchto metrikách sbírá od reálných uživatelů přes Chrome (tzv. CrUX dataset – Chrome User Experience Report). Nesleduje, jak rychle web funguje v laboratoři na rychlém serveru, ale jak ho zažívá průměrný uživatel na běžném mobilu na 4G. To je zásadní rozdíl.

Důležitá změna: INP nahradil FID v březnu 2024

Pokud čtete starší články o Core Web Vitals, narazíte na metriku FID (First Input Delay). Ta v roce 2024 zanikla – Google ji 12. března 2024 nahradil novější metrikou INP (Interaction to Next Paint).

Proč: FID měřil pouze dobu před tím, než server začal reagovat na první interakci uživatele. Stránka mohla projít FID skvěle, ale být přitom celkově pomalá a sekající. INP měří kompletní dobu od kliknutí do vizuální odpovědi – a to nejen u prvního, ale u všech kliknutí na stránce. Je to mnohem poctivější měřítko reálné použitelnosti.

Důsledek: 43 % webů v roce 2026 nesplňuje INP threshold 200 ms, což z něj dělá nejčastěji propadanou Core Web Vital metriku. Mnoho webů, které dříve „prošly“, dnes propadají.

LCP – jak rychle se zobrazí hlavní obsah

Co měří

Largest Contentful Paint měří, za jak dlouho se v okně prohlížeče objeví největší viditelný element – obvykle hero obrázek, hlavní nadpis nebo video preview. Je to v podstatě „kdy uživatel uvidí to hlavní“.

Prahové hodnoty

Dobré: méně než 2,5 sekundy ✅
Vyžaduje zlepšení: 2,5 až 4,0 sekundy ⚠️
Špatné: více než 4,0 sekundy ❌

Časté příčiny špatného LCP

Pomalý server (TTFB nad 600 ms)
Velké, nezoptimalizované obrázky
Render-blocking JavaScript a CSS
Pomalé fonty (web fonts načítané z externích zdrojů)
Chybějící CDN (uživatelé z Asie čekají, než se data dostanou ze serveru v Praze)

Jak LCP zlepšit

Optimalizujte obrázky. Použijte moderní formáty (WebP, AVIF), správnou velikost, kompresi. Plugin ShortPixel, Imagify nebo EWWW Image Optimizer.
Preload hero obrázku. <link rel="preload" as="image" href="hero.webp"> v hlavičce dokumentu
Použijte CDN. Cloudflare, BunnyCDN nebo cdn77 pro doručení obsahu z lokace blízko uživateli.
Cachujte stránky. WP Rocket, LiteSpeed Cache, W3 Total Cache
Lazy loading jen pod foldem. Hero obrázek NIKDY nelazy-loadovat, jinak Google penalizuje LCP.
Upgrade hostingu. Pokud je TTFB nad 600 ms, žádná optimalizace na frontendu to nezachrání. Sdílený hosting často nedokáže Core Web Vitals splnit.

INP – jak rychle web reaguje

Co měří

Interaction to Next Paint měří dobu od kliknutí (nebo zadání z klávesnice) do okamžiku, kdy prohlížeč zobrazí vizuální odpověď. Pokud kliknete na tlačítko a nic se nestane další sekundu, váš web má INP problém.

INP měří všechny interakce během návštěvy a bere 95. percentil – tedy nejhorší z nejhorších. Pokud máte 100 kliknutí, počítá se 95. nejpomalejší. To znamená: pokud je vaše stránka 99× rychlá a jedno kliknutí trvá 800 ms, INP vám ukáže právě tu jedničku.

Prahové hodnoty

Dobré: méně než 200 milisekund ✅
Vyžaduje zlepšení: 201 až 500 ms ⚠️
Špatné: více než 500 ms ❌

Časté příčiny špatného INP

Heavy JavaScript – velké JS soubory, které blokují hlavní vlákno prohlížeče
Third-party skripty – Google Analytics, Facebook Pixel, chat widgety, reklamní systémy
Page buildery – některé generují obrovské množství JavaScriptu (problém u Elementoru, Divi)
Komplexní formuláře s mnoha validacemi v reálném čase
Filter-heavy stránky v e-shopech (mnoho filtrů s reaktivním přepočítáváním)

Jak INP zlepšit

Auditujte plugin overhead. Plugin Query Monitor ukáže, které pluginy plýtvají časem. Méně pluginů = lepší INP.
Defer / async u JavaScriptu. Skripty, které nejsou kritické pro první vykreslení, načítejte asynchronně.
Omezte third-party skripty. Každý analytický nástroj, chat widget a tracking pixel zatěžuje INP. Auditujte, co reálně potřebujete.
Lighter page builder. Pokud máte starý Elementor s desítkami widgetů, zvažte přechod na Gutenberg nebo Bricks Builder, které generují čistší kód.
Preload kritických resources.
Code splitting. U custom React/Vue aplikací rozdělte JavaScript na menší chunks, které se načítají dle potřeby.

Realistická poznámka: INP se z Core Web Vitals nejhůře řeší. Není to o jednom nastavení – je to o architektuře JavaScriptu vašeho webu. Pokud máte komplexní stránku s mnoha pluginy a komerčním builderem, oprava INP může vyžadovat vážnou refaktorizaci.

CLS – stabilita layoutu

Co měří

Cumulative Layout Shift měří, jak moc obsah na stránce „skáče“ během načítání. Klasická situace: chcete kliknout na tlačítko, ale v ten moment se nad ním objeví reklama nebo banner – tlačítko se posune dolů a vy omylem kliknete na něco úplně jiného. CLS přesně tohle čísluje.

Prahové hodnoty

Dobré: méně než 0,1 ✅
Vyžaduje zlepšení: 0,1 až 0,25 ⚠️
Špatné: více než 0,25 ❌

Časté příčiny špatného CLS

Obrázky bez specifikovaných rozměrů. Když HTML neví, jak velký obrázek bude, nemůže pro něj rezervovat místo. Když se obrázek načte, layout se posune.
Dynamicky vkládané reklamy a iframe. Reklama se objeví v prostředku článku a posune obsah pod sebou.
Web fonts. Text se nejprve zobrazí v fallback fontu, pak se přepne do custom fontu jiné velikosti – layout se posune.
Cookie lišty a notifikace. Pokud se objeví v horní části stránky a posunou veškerý obsah dolů.
Lazy-loaded sekce, které mění výšku po načtení obsahu.

Jak CLS zlepšit

Vždy specifikujte width a height u obrázků. WordPress to dělá automaticky pro obrázky vložené přes media library, ale custom HTML musí mít explicitně:

<img src="hero.jpg" width="800" height="450" alt="...">

Rezervujte prostor pro reklamy a embed. Vždy mějte CSS s pevně danou výškou kontejneru, kam se reklama načítá.
font-display: swap a preload kritických fontů. Web font se načítá současně s textem, ne až po něm.
Cookie lišty fixujte přes overlay, ne posouváním obsahu.
Sticky headery by měly být sticky od začátku, ne se objevit po scrollu.

Proč na tom v éře AI tolik záleží

Core Web Vitals jsou potvrzeným ranking faktorem od června 2021. V březnu 2026 Google jejich váhu v algoritmu posílil dalším core update. Ale přínos jde dál:

1. AI nástroje preferují technicky čisté zdroje

Pomalý web s špatnými Core Web Vitals má vyšší míru opouštění (bounce rate). Uživatelé se na něm chovají jinak než na rychlém. AI nástroje tato chování (přes Chrome data, Bing data) sledují a deprioritizují weby se špatnou user experience.

2. Pomalé weby vypadnou z AI Overviews

Pro zařazení do Google AI Overviews je technicky bezchybná stránka prerekvizita. Když Googlebot crawluje pomalý web, nemůže ho efektivně zpracovat – a tím pádem ho ani efektivně neukáže AI vrstvě.

3. Konkrétní byznys data

Stránky pod 2 sekundy mají bounce rate 9 %, stránky nad 5 sekund 38 %
Každá sekunda navíc nad 2,5s LCP zvyšuje bounce rate o 32 %
1 sekunda zpoždění snižuje konverze o 7 %
E-shopy splňující všechny tři Core Web Vitals vidí zlepšení konverzí o 15–30 %
Weby s passing CWV mají v průměru o 24 % nižší bounce rate

Jak Core Web Vitals měřit

Field data vs. lab data

Důležitý rozdíl, který hodně lidí plete:

Field data – data z reálných uživatelů přes Chrome (CrUX dataset). Toto Google používá pro ranking.
Lab data – simulované měření v testovací prostředí (Lighthouse, PageSpeed). Užitečné pro debugování, ale není to, co Google hodnotí.

Můžete mít v Lighthouse 100/100 a v reálu propadat – pokud má vaše cílová skupina pomalé telefony nebo špatné připojení.

Nástroje pro měření

Google Search Console → Core Web Vitals report – nejdůležitější. Ukazuje field data agregovaná napříč celým webem, rozdělené na mobile a desktop.
PageSpeed Insights (pagespeed.web.dev) – kombinuje field data (z CrUX) a lab data (z Lighthouse) pro konkrétní URL.
Chrome DevTools → Lighthouse panel – lab měření přímo v prohlížeči, dobré pro debugging.
Web Vitals Chrome rozšíření – ukazuje aktuální Core Web Vitals při procházení webu
WebPageTest (webpagetest.org) – pokročilé testování s detailními waterfall grafy
Cloudflare Web Analytics – kontinuální monitoring (zdarma)

Co je 75. percentil

Aby váš web prošel Core Web Vitals, musí mít 75 % uživatelů „dobrou“ zkušenost. Není to průměr – je to threshold, který musí 75 % vašich návštěvníků překonat. Pokud 25 % vašich uživatelů má pomalý mobil a špatné připojení, ostatní 75 % musí mít skvělou zkušenost, abyste prošli.

WordPress optimalizace v praxi

Caching

WP Rocket – komerční, nejjednodušší a nejkomplexnější
LiteSpeed Cache – zdarma, vyžaduje LiteSpeed nebo OpenLiteSpeed server
W3 Total Cache – zdarma, technicky náročnější konfigurace
WP Super Cache – zdarma, jednodušší alternativa od Automattic

Optimalizace obrázků

ShortPixel – komerční, vysoká kvalita komprese, podpora WebP/AVIF
Imagify – od tvůrců WP Rocket
Smush – populární free verze, omezení v bezplatné variantě
EWWW Image Optimizer – free, lokální komprese

CDN

Cloudflare – nejpopulárnější, free tier postačí pro většinu webů
BunnyCDN – levné, výborný výkon v Evropě
cdn77 – česká firma s globální sítí
KeyCDN – jednoduché, předvídatelné ceny

Hosting

Pro Core Web Vitals zásadní. Sdílený hosting je obvykle pomalý, často nedokáže LCP pod 2,5 sekundy:

Managed WordPress hosting (WPEngine, Kinsta, Cloudways)
Český managed: WEDOS, Stable.cz, Forpsi (vyšší tarify)
VPS: DigitalOcean, Linode, Vultr

Téma a page builder

Lightweight témata: GeneratePress, Astra, Kadence, Blocksy
Page buildery, které fungují dobře: Bricks, Breakdance, native Gutenberg
Page buildery s problematickým overheadem: Divi, starší Elementor, WPBakery (Visual Composer)

Strategie optimalizace: priority pořadí

Nejčastější chyba je skok na metriku, která vypadá nejhůř. Lepší přístup je systematický:

TTFB (Time to First Byte) – jak rychle server začne odpovídat. Optimalizujte hosting a caching jako první.
LCP – obrázky, fonty, render-blocking resources
INP – nejtěžší, často vyžaduje strukturální změny
CLS – obvykle nejjednodušší: rozměry obrázků, font-display swap, rezervovaný prostor

Druhá zásada: pracujte na úrovni šablony, ne jednotlivých URL. Pokud má váš blog 200 článků a všechny mají stejný layout, jedna oprava šablony opraví všechny stránky najednou.

Časté chyby

Spoléhání jen na Lighthouse skóre. 100/100 v laboratoři neznamená, že web prochází Core Web Vitals u reálných uživatelů. Sledujte field data v Search Console.
Optimalizace jednotlivých URL místo šablon. Plýtvání času.
Lazy loading hero obrázku. Hero (LCP element) NIKDY nelazyloadovat. Některé pluginy to dělají automaticky – vypněte to.
Příliš mnoho cachovacích pluginů najednou. Konflikty, nepředvídatelné chování. Jeden plugin pro caching, jeden pro obrázky.
Ignorování mobile výsledků. Google používá mobile data primárně. I když máte desktop perfektní, mobile rozhoduje.
Snaha o dokonalá skóre za každou cenu. Cíl je „dobré“ (zelená), ne „perfektní“. 90 vs. 100 v Lighthouse často není rozdíl, který stojí za týdny práce.
Měření jednou a hotovo. Core Web Vitals se mění s každým novým pluginem, novou verzí WordPressu, novým obsahem. Monitoring musí být kontinuální.
Příliš mnoho third-party skriptů. Každý analytický pixel a marketingový tag zatěžuje INP. Auditujte čtvrtletně, co reálně potřebujete.

Realistická očekávání

Optimalizace Core Web Vitals není o tom, aby váš web byl nejrychlejší na světě. Je o tom, aby splňoval „dobré“ prahové hodnoty pro 75 % vašich uživatelů. To je dosažitelný cíl pro většinu webů.

Realistické časové horizonty:

Týdny: Quick wins (caching, optimalizace obrázků, CDN, dimenze obrázků)
Měsíce: Strukturální zlepšení (lighter theme, méně pluginů, refactor JS)
28 dní: Po každé změně Google čeká 28denní okno CrUX dat, než aktualizuje hodnocení. Buďte trpěliví.

Závěr

Core Web Vitals jsou jednou z mála SEO disciplín, kde se zájmy všech sčítají. Rychlejší web = spokojenější uživatelé = lepší Google ranking = více AI citací = více konverzí. Investice do výkonu se vrací na všech frontách.

V roce 2026, kdy 53 % webů propadá v Core Web Vitals a 43 % konkrétně v INP, máte konkurenční výhodu už jen tím, že to děláte správně. Nepotřebujete vyhrát soutěž v rychlosti – stačí, abyste byli mezi 47 % webů, které prochází.

Akční plán:

Zkontrolujte Search Console → Core Web Vitals report (mobile primárně)
Identifikujte šablonu nebo typ stránky s největším problémem
Začněte hostingem a cachingem (TTFB pod 600 ms)
Optimalizujte obrázky (WebP/AVIF, správné rozměry, lazy loading mimo hero)
Specifikujte width/height u všech obrázků pro CLS
Auditujte third-party skripty pro INP – odstraňte zbytečné
Nasaďte CDN pro globální dostupnost
Po 28 dnech sledujte aktualizaci dat v Search Console

Pravidlo na závěr: Core Web Vitals jsou technická hygiena, kterou si dnes nemůžete dovolit zanedbat. Není to fancy SEO trik – je to základní podmínka, aby vaš web vůbec dostal šanci být objeven, doporučen a ohodnocen jako kvalitní zdroj. V éře AI vyhledávání platí: pomalý web je neviditelný web.