Core Web Vitals: Průvodce rychlostí webu pro lepší pozice v Googlu
Web se načítá pomalu. Obrázky naskakují se zpožděním, text poskakuje jak se načítají fonty, a když kliknete na tlačítko „Přidat do košíku", několik vteřin se nic neděje. Uživatelé odcházejí — a Google to vidí. Core Web Vitals jsou tři metriky, kterými Google měří uživatelskou zkušenost na vašem webu. A od roku 2021 jsou součástí rankingového algoritmu. Pomalý web = horší pozice.
Google metriky průběžně zpřísňuje. V březnu 2024 nahradil metriku FID (First Input Delay) přísnější metrikou INP (Interaction to Next Paint), která měří odezvu webu během celé návštěvy, ne jen u první interakce. Podle HTTP Archive je medián LCP (hlavní metrika rychlosti načítání) na mobilech stále přes 3,5 sekundy — to je hluboko v červené zóně. Většina českých webů Core Web Vitals neprochází. A většina majitelů webů o tom neví.
V tomhle článku vám vysvětlíme všechny tři metriky srozumitelně — co přesně měří LCP, INP a CLS, jaké jsou limity pro dobré a špatné hodnoty, a hlavně jak je konkrétně zlepšit. Nebudeme teoretizovat — dostanete ukázky kódu, reálná čísla a příklady z českých webů. Po přečtení budete vědět, kde váš web ztrácí a co s tím dělat.
Článek je určený majitelům firem, marketérům a IT vedoucím, kteří chtějí pochopit, proč je jejich web pomalý a co s tím udělat — aniž by museli rozumět kódu. Technické detaily vysvětlíme srozumitelně a tam, kde je potřeba zásah vývojáře, řekneme to na rovinu. Pokud hledáte komplexní pohled na technický stav webu, podívejte se na náš článek o technickém SEO auditu.
Obsah
Co jsou Core Web Vitals a proč je Google zavedl
Google chce, aby web byl rychlý a příjemný pro uživatele. Ne proto, že by byl altruistický — ale protože spokojení uživatelé více používají Google. A weby s dobrou uživatelskou zkušeností si zaslouží lepší pozice. Core Web Vitals jsou tři metriky, které měří reálnou zkušenost skutečných návštěvníků vašeho webu.
Představte si to jako hodnocení restaurace. LCP (Largest Contentful Paint) je jak rychle vám přinesou hlavní chod — čekáte na jídlo minutu, nebo dvacet? INP (Interaction to Next Paint) je jak rychle číšník reaguje, když na něj mávnete — přijde hned, nebo vás ignoruje? CLS (Cumulative Layout Shift) je jestli vám přestaví stůl zatímco jíte — položíte vidličku a ona je najednou jinde.
Krátká historie Core Web Vitals
2020: Google představil Core Web Vitals jako soubor metrik
2021: Součástí rankingového algoritmu (Page Experience update)
2024: FID nahrazen za INP — přísnější metrika interaktivity
Tady je přehled všech tří metrik s hraničními hodnotami:
Metrika | Co měří | Dobrá hodnota | Potřeba zlepšit | Špatná hodnota |
|---|---|---|---|---|
LCP | Rychlost načtení hlavního obsahu | ≤ 2,5 s | 2,5–4,0 s | > 4,0 s |
INP | Rychlost reakce na interakci | ≤ 200 ms | 200–500 ms | > 500 ms |
CLS | Vizuální stabilita (posun prvků) | ≤ 0,1 | 0,1–0,25 | > 0,25 |
Hodnoty jsou definovány na 75. percentilu — to znamená, že 75 % návštěvníků musí mít danou hodnotu nebo lepší, aby web prošel.
📌 Důležité: Core Web Vitals měří reálné uživatele, ne laboratorní testy. Data pocházejí z Chrome UX Report (CrUX) — skutečné návštěvy z prohlížeče Chrome za posledních 28 dní. Proto se laboratorní výsledky (Lighthouse) mohou lišit od field dat (to, co vidí Google).
Podle studie Googlu mají weby s dobrými Core Web Vitals o 24 % nižší bounce rate. Uživatelé zůstávají déle, prohlížejí více stránek a častěji konvertují. Core Web Vitals nejsou jen o SEO — jsou o byznysu.
Pojďme si každou metriku rozebrat detailně — co přesně měří, proč typicky selhává a jak ji opravit.
LCP — Largest Contentful Paint
LCP měří čas, za který se zobrazí největší viditelný prvek na stránce v rámci viewportu (viditelné oblasti obrazovky). Typicky je to hero obrázek, hlavní nadpis H1, nebo video. LCP měří první dojem — jak rychle uživatel vidí „hlavní obsah" stránky.
Cíl: ≤ 2,5 sekundy
Co se počítá jako LCP element:
Obrázky (
<img>,<image>v SVG,background-image)Video (poster image)
Blokové elementy s textem (nadpisy, odstavce)
Co LCP typicky zpomaluje
1. Neoptimalizované obrázky
Největší zabiják rychlosti. Hero banner v PNG formátu o 3 MB se na mobilním připojení načítá sekundy. A přitom stejný obrázek ve WebP formátu může mít 400 KB při stejné vizuální kvalitě.
<!-- Špatně: jeden velký obrázek pro všechny -->
<img src="hero-banner.png" alt="Banner" />
<!-- Správně: optimalizovaný s responsive variantami -->
<img src="hero-banner.webp"
srcset="hero-banner-400.webp 400w,
hero-banner-800.webp 800w,
hero-banner-1200.webp 1200w"
sizes="(max-width: 600px) 400px,
(max-width: 1024px) 800px,
1200px"
width="1200"
height="600"
loading="eager"
fetchpriority="high"
alt="Popis hero banneru" />
Klíčové atributy:
srcsetasizes— prohlížeč stáhne správnou velikost pro dané zařízenífetchpriority="high"— prohlížeč prioritizuje stažení tohoto obrázkuloading="eager"— načíst ihned (ne lazy load pro above-the-fold obsah)widthaheight— zamezí CLS (layout shift)
2. Pomalý server (TTFB)
TTFB (Time to First Byte) je čas, za který server odpoví na požadavek. Pokud TTFB trvá 2 sekundy, LCP nemůže být lepší než 2 sekundy + čas na stažení a vykreslení obsahu.
# Změření TTFB
curl -o /dev/null -w "TTFB: %{time_starttransfer}s\n" https://vasadomena.cz
Dobrá hodnota TTFB: pod 600 ms. Pokud máte víc, řešení:
CDN (Cloudflare je zdarma) — obsah servírovaný z edge serverů blíž k uživateli
Server-side caching — WordPress: WP Super Cache, WP Rocket; Next.js: ISR
Upgrade hostingu — sdílený hosting za 50 Kč/měsíc prostě nebude rychlý
Příklad z praxe: E-shop na sdíleném hostingu měl TTFB 1,8 sekundy. Po migraci na VPS s Cloudflare CDN klesl TTFB na 180 ms. LCP se zlepšil z 5,2 s na 1,9 s — bez jakékoli změny kódu nebo obrázků.
3. Render-blocking JavaScript a CSS
Prohlížeč nemůže zobrazit obsah, dokud nestáhne a nezpracuje všechny CSS a synchronní JavaScript soubory v <head>.
Řešení:
asyncnebodeferpro skripty, které nejsou kritické pro první vykresleníCritical CSS — inline styly potřebné pro above-the-fold obsah přímo do HTML
Code splitting — načítat pouze JS potřebný pro aktuální stránku
4. Webfonty
Vlastní fonty se stahují ze serveru — mezitím může být text neviditelný (FOIT — Flash of Invisible Text) nebo zobrazený fallback fontem (FOUT — Flash of Unstyled Text).
@font-face {
font-family: 'MujFont';
src: url('/fonts/mujfont.woff2') format('woff2');
font-display: swap; /* Zobrazí fallback font, pak swap na vlastní */
}
<!-- Preload klíčového fontu -->
<link rel="preload" href="/fonts/mujfont.woff2" as="font" type="font/woff2" crossorigin>
💡 Tip: Začněte obrázky — v 70 % případů je LCP problém v neoptimalizovaných obrázcích. Přechod na WebP formát a správné
srcsetčasto stačí ke zlepšení o 1-2 sekundy.
LCP měří načtení hlavního obsahu. Ale co když se stránka načte rychle, ale po kliknutí na tlačítko zamrzne?
INP — Interaction to Next Paint
INP (Interaction to Next Paint) měří odezvu webu na interakci uživatele — kliknutí, tap na mobilu, stisk klávesy. Konkrétně měří čas od interakce do okamžiku, kdy prohlížeč vykreslí vizuální odpověď (next paint).
Cíl: ≤ 200 milisekund
INP nahradil metriku FID (First Input Delay) v březnu 2024. Klíčový rozdíl: FID měřil pouze první interakci návštěvníka. INP měří všechny interakce během celé návštěvy. Prohlížeč zaznamenává 98. percentil (P98), ale pro hodnocení kvality webu Google používá 75. percentil (P75) z Chrome UX Report. Je to výrazně přísnější metrika.
Proč to Google udělal? Protože web může mít skvělou první interakci (zatímco se ještě nenačetly všechny skripty), ale pak zamrzne při každém dalším kliknutí. INP tohle odhalí.
Co INP zhoršuje
1. Těžký JavaScript na main threadu
JavaScript v prohlížeči běží na jednom vlákně (main thread). Když prohlížeč zpracovává těžký JS kód, nemůže současně reagovat na interakce uživatele. Uživatel klikne na „Přidat do košíku" — a 500 ms se nic neděje, protože prohlížeč je zaneprázdněný.
Řešení:
Code splitting — načítat JS pouze pro aktuální stránku, ne celou aplikaci
Lazy loading komponent — načíst modály, karusely a další komponenty až když jsou potřeba
Web Workers — přesunout těžké výpočty mimo main thread
2. Third-party skripty
Google Analytics, Facebook Pixel, chat widgety, remarketing tagy, A/B testing nástroje — každý přidává JavaScript. Mít 10 third-party skriptů znamená významné zpomalení.
<!-- Špatně: všechno synchronně v head -->
<script src="https://analytics.example.com/script.js"></script>
<script src="https://chat.example.com/widget.js"></script>
<script src="https://ads.example.com/pixel.js"></script>
<!-- Lépe: defer a lazy loading -->
<script src="https://analytics.example.com/script.js" defer></script>
Ještě lepší: Google Tag Manager s custom triggery — načíst analytiku až po interakci nebo po X sekundách.
3. Velké DOM stromy
Stránka s 5 000+ DOM elementy (HTML tagy) — prohlížeč musí přepočítat layout a styles po každé změně. Komplexní e-shop s mega menu, filtry a tisíci produkty může mít obrovský DOM.
Řešení:
Virtualizace seznamů — místo 2 000 produktů v DOM renderovat jen 20 viditelných (knihovny jako react-window)
Lazy rendering — načítat obsah až při scrollu
Zjednodušení HTML — méně wrapperů, jednodušší struktura
Příklad z praxe: SaaS dashboard měl INP 680 ms. Příčina: 3 analytické skripty načítané synchronně + live chat widget + React komponenta re-renderující tabulku s 2 000 řádky při každé změně filtru. Po optimalizaci (code splitting, virtualizace tabulky, deferred analytics): INP klesl na 120 ms.
Stránka se načte rychle a reaguje svižně. Ale pak vám ujede layout pod rukama...
CLS — Cumulative Layout Shift
CLS (Cumulative Layout Shift) měří vizuální stabilitu stránky — jak moc se prvky posouvají po načtení. Znáte to: chcete kliknout na odkaz, ale v tu chvíli se načte reklama nad ním a posune celou stránku. Kliknete na reklamu místo odkazu. Frustrující.
Cíl: ≤ 0,1
CLS se počítá jako součet všech neočekávaných posunů layoutu během celé životnosti stránky. Každý posun má skóre = impact fraction × distance fraction. Čím větší prvek se posune a čím dál, tím horší skóre.
Co způsobuje CLS
1. Obrázky a videa bez rozměrů
Prohlížeč nezná velikost obrázku, dokud se nenačte. Rezervuje pro něj 0 pixelů. Když se obrázek načte, přidělí mu skutečnou velikost — a celá stránka pod ním se posune dolů.
<!-- Špatně: prohlížeč neví, kolik místa rezervovat -->
<img src="foto.jpg" alt="Fotografie" />
<!-- Správně: explicitní rozměry -->
<img src="foto.jpg" width="800" height="600" alt="Fotografie" />
<!-- Nebo přes CSS aspect-ratio (moderní přístup) -->
<img src="foto.jpg" style="aspect-ratio: 4/3; width: 100%;" alt="Fotografie" />
2. Dynamicky vkládaný obsah
Cookie lišty, newsletter popup, reklamy, notifikační bannery — cokoliv, co se vloží do stránky po načtení a posune existující obsah.
Řešení:
Rezervujte prostor předem —
min-heightpro kontejnery reklamVkládejte pod fold — content pod viditelnou oblast neovlivní CLS
Overlay místo push — cookie lišta jako overlay nepřesouvá obsah
/* Rezervace prostoru pro reklamu */
.ad-container {
min-height: 250px; /* Standardní velikost reklamy */
}
3. Webfonty (FOIT/FOUT)
Fallback font (Arial) má jiné rozměry než váš custom font. Text se zobrazí ve fallback fontu, pak se „překreslí" custom fontem — a protože má jiné rozměry, text „skočí".
@font-face {
font-family: 'MujFont';
src: url('/fonts/mujfont.woff2') format('woff2');
font-display: swap;
/* size-adjust přizpůsobí fallback font podobným rozměrům */
size-adjust: 105%;
}
4. Animace měnící layout
Animace, které mění width, height, top, left nebo margin způsobují layout shift. Animace přes transform a opacity ne.
/* Špatně: animace mění layout */
.element {
transition: margin-left 0.3s;
}
.element:hover {
margin-left: 20px;
}
/* Správně: transform nepůsobí layout shift */
.element {
transition: transform 0.3s;
}
.element:hover {
transform: translateX(20px);
}
💡 Tip: CLS je nejjednodušší metrika na opravu. V 80 % případů stačí přidat
widthaheightke všem<img>tagům a rezervovat prostor pro dynamický obsah (reklamy, cookie lišty). Často je to práce na hodinu.
Teď rozumíte všem třem metrikám. Jak je změřit?
Jak měřit Core Web Vitals — nástroje
Existují dva typy dat pro Core Web Vitals:
Field data (reální uživatelé) — data z Chrome UX Report, sbíraná od skutečných návštěvníků používajících Chrome. Tohle Google používá pro ranking. Nevýhoda: potřebujete dostatečný traffic, data jsou agregovaná za 28 dní.
Lab data (simulace) — data z nástrojů jako Lighthouse, simulující načítání na definovaném zařízení. Pro diagnostiku a ladění. Nevýhoda: nemusí odpovídat reálné zkušenosti uživatelů.
Nástroje pro měření
PageSpeed Insights (pagespeed.web.dev) — nejdůležitější nástroj. Zadejte URL a dostanete:
Field data z CrUX (pokud má web dostatečný traffic)
Lab data z Lighthouse
Konkrétní doporučení co zlepšit
Začněte vždy tady.
Google Search Console — sekce „Core Web Vitals" v levém menu. Přehled všech URL na webu rozdělených do kategorií Good / Needs improvement / Poor. Sledujte trendy v čase. Upozorní vás na problémy dřív, než ovlivní pozice.
Lighthouse — v Chrome DevTools (F12 → záložka Lighthouse). Spustí lab test s detailním rozpadem metrik. Ideální pro diagnostiku konkrétních problémů. Můžete testovat i lokální/staging verzi webu.
Chrome DevTools Performance panel — pro vývojáře. Záložka Performance → Record. Filmstrip view ukazuje co se děje milisekundu po milisekundě. Flame chart identifikuje konkrétní blokující kód.
web.dev/measure — online verze Lighthouse testu. Jednodušší rozhraní než PageSpeed Insights, dobré pro rychlý test.
⚠️ Pozor: Lab data a field data se často výrazně liší. Lighthouse vám ukáže LCP 1,5 s na vašem rychlém MacBooku — ale reální uživatelé na mobilech s průměrným 4G připojením mají 4,2 s. Vždy prioritizujte field data z CrUX. Lab data používejte pro diagnostiku, ne pro hodnocení úspěchu.
Nástroje znáte. Pojďme dát dohromady akční plán.
Akční plán — jak zlepšit Core Web Vitals krok za krokem
Tohle je praktická sekce — konkrétní kroky, které můžete začít implementovat hned. Seřazeno podle typického dopadu (největší quick wins první).
Krok 1: Diagnostika (den 1)
Než něco opravíte, potřebujete vědět, kde je problém.
Otevřete PageSpeed Insights
Otestujte 5 klíčových stránek: homepage, produktová stránka (nebo stránka služby), blog post, kontakt, kategorie/výpis
Zapište si aktuální hodnoty LCP, INP, CLS pro každou stránku
Identifikujte nejhorší stránku — s ní začněte
Pozor: testujte mobilní verzi, ne desktop. Google primárně měří mobilní výkon.
Krok 2: Obrázky (den 1-3)
Obvykle největší quick win s nejmenším úsilím.
Checklist pro obrázky:
Převeďte na WebP formát (úspora 25-35 % oproti JPEG)
Implementujte responsive images (
srcsetasizes)loading="lazy"pro obrázky pod foldem (ne pro hero obrázek!)fetchpriority="high"pro hero obrázekPřidejte
widthaheightke všem<img>tagům (CLS fix)Zvažte moderní formáty (AVIF pro ještě lepší kompresi)
Nástroje pro konverzi: Squoosh (online), ShortPixel (WordPress plugin), Sharp (Node.js).
Krok 3: JavaScript audit (den 3-5)
V Lighthouse reportu najděte sekci „Opportunities":
Reduce unused JavaScript — kolik KB JS se načítá, ale nepoužívá na dané stránce?
Reduce JavaScript execution time — které skripty blokují main thread?
Co udělat:
Third-party skripty — potřebujete všechny? Může být některý
defernebo lazy loaded?Code splitting — načítejte JS jen pro aktuální stránku (Next.js, Webpack)
Odstraňte nepoužívané pluginy (WordPress: deaktivujte a smažte)
Google Tag Manager místo přímého vkládání skriptů (lepší kontrola)
Krok 4: Server a hosting (den 5-7)
Změřte TTFB:
curl -o /dev/null -w "TTFB: %{time_starttransfer}s\n" https://vasadomena.cz
Pokud TTFB > 600 ms:
Cloudflare CDN (zdarma) — často sníží TTFB o 50-70 %
Server-side caching — WordPress: WP Rocket nebo WP Super Cache
Upgrade hostingu — z sdíleného na VPS nebo managed hosting
Gzip/Brotli komprese — zkontrolujte v DevTools Network tab (sloupec Size vs. Transferred)
Krok 5: Fonty (den 7)
@font-face {
font-family: 'VasFont';
src: url('/fonts/vasfont.woff2') format('woff2');
font-display: swap; /* Kritické! */
}
<!-- Preload klíčového fontu -->
<link rel="preload" href="/fonts/vasfont.woff2" as="font" type="font/woff2" crossorigin>
font-display: swapu všech @font-facePreload pouze 1-2 nejdůležitější fonty
Zvažte system fonts pro body text (rychlejší, žádné stahování)
Krok 6: Měření a iterace (průběžně)
Po každé změně: znovu PageSpeed Insights — zlepšilo se to?
Týdně: kontrola GSC Core Web Vitals reportu
Cíl: všechny klíčové stránky v „Good" zóně (zelená)
Kompletní checklist:
✅ Obrázky ve WebP s explicitními width/height ✅ Hero obrázek s fetchpriority="high" ✅ JavaScript defer/async kde možné ✅ Audit a redukce third-party skriptů ✅ CDN aktivní (Cloudflare) ✅ Gzip/Brotli komprese ✅ font-display: swap pro webfonty ✅ TTFB pod 600 ms ✅ Rezervovaný prostor pro dynamický obsah (reklamy, cookie lišty)
Příklad z praxe: WordPress web (firemní prezentace, 30 stránek) měl PageSpeed skóre 38/100 na mobilu. Příčina: 8 pluginů generujících JS/CSS, nekomprimované obrázky v PNG, žádná cache, pomalý sdílený hosting. Po optimalizaci (WP Rocket cache, ShortPixel pro obrázky, deaktivace 3 zbytečných pluginů, Cloudflare CDN): skóre 89/100. Organic traffic vzrostl o 22 % za 2 měsíce. Celková investice: 8 hodin práce + WP Rocket licence (cca 1 500 Kč/rok).
Pokud potřebujete pomoc s optimalizací, podívejte se na naše služby technického SEO nebo webového vývoje — Core Web Vitals řešíme na denní bázi.
Core Web Vitals jsou základ technického SEO. Ale v roce 2026 na ně navazují další trendy.
Core Web Vitals a budoucnost — co čekat
Google metriky průběžně vyvíjí — FID nahradil INP, další změny přijdou. Tady jsou trendy, které sledujeme.
Soft navigation API
Google testuje měření Core Web Vitals pro single-page aplikace (React, Next.js, Vue). Klasické CWV měří jen první načtení stránky. Ale SPA aplikace mají „měkké" přechody mezi stránkami (JavaScript routing bez full page reload). Soft navigation API umožní měřit tyto přechody jako samostatné „navigace" s vlastním LCP, INP, CLS.
Co to znamená: SPA weby budou brzy měřeny přísněji. Pokud máte React/Vue aplikaci, kde je první načtení rychlé, ale přechody mezi stránkami pomalé — připravte se.
Větší důraz na mobilní výkon
Mobilní traffic tvoří přes 60 % návštěv celosvětově (v některých segmentech přes 80 %). Google již nyní primárně měří mobilní verzi webu. Očekávejte ještě přísnější požadavky na mobilní rychlost.
Souvislost s AI readiness
Rychlý web není důležitý jen pro uživatele a Google. AI crawlery (GPTBot, ClaudeBot) mají také omezený čas na crawling. Pomalý web s TTFB 3 sekundy je méně atraktivní i pro AI boty. Optimalizace rychlosti pomáhá i vaší viditelnosti v AI vyhledávačích — více o tom v našem článku o AI readiness.
Doporučení do budoucna
Nezaměřujte se jen na čísla — snažte se o reálně rychlý web pro reálné uživatele. Čísla jsou jen proxy metrika.
Nastavte pravidelný monitoring — měsíční kontrola GSC Core Web Vitals reportu
Při každém redesignu nebo nasazení nové funkce měřte dopad na CWV
Investujte do infrastruktury — dobrý hosting a CDN se vyplatí
⚠️ Pozor: Core Web Vitals nejsou jediný ranking faktor. Web s perfektním PageSpeed skóre 100/100 a slabým obsahem bude stále prohrávat s pomalejším webem, který má lepší, relevantnější obsah. CWV je nutná podmínka pro dobré pozice, ne dostatečná. Je to základ, na kterém stavíte — ale samotný základ dům nedělá.
Nejčastější otázky o Core Web Vitals
Co jsou Core Web Vitals jednoduchým jazykem?
Core Web Vitals jsou tři metriky od Googlu, které měří, jak rychlý a příjemný je váš web pro návštěvníky. LCP měří, jak rychle se zobrazí hlavní obsah stránky (ideálně do 2,5 sekundy). INP měří, jak rychle web reaguje na kliknutí nebo tap (ideálně do 200 milisekund). CLS měří, jestli se prvky na stránce nepohybují během načítání (ideálně skóre pod 0,1). Google tyto metriky sbírá od reálných uživatelů a používá je jako jeden z faktorů pro určení pozic ve vyhledávání.
Jsou Core Web Vitals ranking faktor?
Ano, Core Web Vitals jsou součástí rankingového algoritmu Googlu od června 2021 v rámci „Page Experience" update. Ale je to jeden z mnoha faktorů — a ne ten nejdůležitější. Relevance a kvalita obsahu mají stále větší váhu. Pokud máte dva weby s podobným obsahem a odkazy, rychlejší vyhraje. Ale pomalý web s vynikajícím obsahem může stále překonat rychlý web s průměrným obsahem. Berte CWV jako nutnou podmínku, ne jako záruku úspěchu.
Jak rychle se projeví zlepšení CWV na pozicích?
Google aktualizuje CWV data z CrUX (Chrome UX Report) za období 28 dní. Po implementaci oprav tedy trvá minimálně měsíc, než se změny projeví v datech, která Google vidí. Samotný dopad na pozice pak závisí na dalších faktorech — konkurenci, crawl frekvenci, váze CWV ve vašem segmentu. Realisticky očekávejte viditelné změny v pozicích za 2-3 měsíce po optimalizaci. Některé weby zaznamenají rychlejší zlepšení, jiné pomalejší.
Jaké Core Web Vitals skóre je dobré?
Google definuje tři zóny: Good (dobrá), Needs Improvement (potřebuje zlepšení) a Poor (špatná). Pro Good hodnocení potřebujete: LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1. Tyto hodnoty musí splnit 75 % vašich návštěvníků (75. percentil). V PageSpeed Insights se „Good" zobrazuje zeleně, „Needs Improvement" oranžově a „Poor" červeně. Cílem je mít všechny tři metriky v zelené zóně.
Můžu Core Web Vitals zlepšit bez vývojáře?
Částečně ano. Některé optimalizace zvládnete sami: komprese obrázků (online nástroje jako Squoosh), instalace cache pluginu (WordPress), aktivace Cloudflare CDN. Ale komplexnější problémy — code splitting JavaScriptu, optimalizace render-blocking resources, úpravy custom kódu — vyžadují vývojáře. Doporučujeme začít s tím, co zvládnete sami (obrázky, cache, CDN), změřit dopad, a pokud to nestačí, přizvat odborníka na technické SEO.
Shrnutí
Core Web Vitals jsou tři metriky od Googlu měřící rychlost a uživatelskou zkušenost: LCP (rychlost načtení hlavního obsahu), INP (odezva na interakce) a CLS (vizuální stabilita). Od roku 2021 jsou součástí rankingového algoritmu — pomalý web má horší pozice. Nejčastější problémy na českých webech jsou neoptimalizované obrázky, příliš mnoho JavaScriptu a pomalý hosting. Začněte diagnostikou v PageSpeed Insights, pak optimalizujte obrázky (největší quick win), zrychlete server (CDN, cache) a redukujte JavaScript. Cíl: všechny metriky v zelené zóně. Pravidelně monitorujte v Google Search Console.
Chcete zjistit, jak je na tom váš web?
V rámci naší služby technického SEO prověříme Core Web Vitals a navrhneme konkrétní kroky ke zlepšení. Nabízíme bezplatnou 15minutovou konzultaci, kde probereme aktuální stav.
Napište na [email protected] nebo využijte kontaktní formulář.