Core Web Vitals: jak zlepšit rychlost webu a pozice ve vyhledávání

Optimalizace Core Web Vitals už není technická kuriozita pro vývojáře — je to faktor, který Google přímo zohledňuje při hodnocení kvality stránky a který se promítá do pozic ve vyhledávání i do chování návštěvníků. Pomalý web nebo web, který se během načítání „hýbe“, ztrácí návštěvníky dřív, než si vůbec přečtou obsah. V tomto článku se podíváme na to, co Core Web Vitals přesně měří, proč na nich záleží a jaké konkrétní technické kroky vedou k jejich zlepšení.

Core Web Vitals jsou soubor metrik, kterými Google měří reálnou zkušenost uživatele se stránkou — nejen to, jak rychle se stránka „technicky“ načte, ale jak ji vnímá člověk, který na ni klikl. Jde o tři hlavní metriky:

• LCP (Largest Contentful Paint) — jak rychle se zobrazí největší viditelný prvek stránky (typicky hlavní obrázek nebo nadpis).
• CLS (Cumulative Layout Shift) — zda se prvky na stránce během načítání nehýbou a neposouvají obsah pod kurzorem.
• INP (Interaction to Next Paint) — jak rychle stránka zareaguje na kliknutí, ťuknutí nebo jiný vstup uživatele.

Google tyto metriky používá jako součást hodnocení souboru signálů o kvalitě stránky (page experience). Optimalizace Core Web Vitals tedy není jen o rychlosti pro rychlost samotnou — jde o to, aby se stránka chovala předvídatelně a nefrustrovala návštěvníka.

LCP je metrika, kterou většina webů nejvíc podceňuje, protože její příčiny bývají skryté v detailech implementace.

Nejčastější příčiny pomalého LCP

• Neoptimalizované obrázky ve velkém rozlišení a ve starších formátech (JPEG, PNG místo WebP nebo AVIF).
• Blokující CSS a JavaScript soubory, které musí prohlížeč stáhnout a zpracovat dřív, než vykreslí obsah.
• Pomalá odezva serveru (TTFB), často způsobená nevhodným hostingem nebo chybějícím cachováním.
• Fonty, které se načítají pozdě a způsobují překreslení textu.

Řešení, která fungují

• Komprese a moderní formáty obrázků, ideálně s automatickým výběrem velikosti podle zařízení (responsive images).
• Přednačtení klíčových zdrojů pomocí preload pro hlavní obrázek nebo font.
• Přesun renderování na server (SSR) nebo statické generování stránek tam, kde je to možné — moderní frameworky jako Next.js mají optimalizaci obrázků i fontů zabudovanou přímo v jádře, což jsme podrobněji rozebrali v článku o tom, prečo agentúry čoraz viac uprednostňujú Next.js pre firemné weby.
• Výběr hostingu a CDN, které zkracují vzdálenost mezi serverem a uživatelem.

Layout shift vzniká nejčastěji tehdy, když prohlížeč předem neví, jakou velikost bude mít prvek, který se teprve načítá — obrázek, reklama, embed nebo webfont.

Praktická opatření:

• Vždy definovat width a height (nebo aspect-ratio) pro obrázky a video, aby si prohlížeč vyhradil místo předem.
• Rezervovat prostor pro dynamický obsah — bannery, karusely, vkládané widgety — ještě před jeho načtením.
• Používat font-display: optional nebo swap s pečlivě nastaveným záložním fontem, aby výměna písma neměnila výšku řádků.
• Vyhýbat se vkládání nového obsahu nad existující obsah bez interakce uživatele.

INP nahradilo starší metriku FID a měří zpoždění mezi interakcí uživatele a vizuální odezvou stránky. Vysoké INP je typické pro stránky s těžkým JavaScriptem, který blokuje hlavní vlákno prohlížeče.

Kroky, které INP reálně zlepšují:

• Dělení kódu (code splitting) tak, aby se načítal jen JavaScript potřebný pro danou stránku.
• Odložení zpracování nepodstatných skriptů (analytika, chat widgety, třetí strany) až po vykreslení hlavního obsahu.
• Rozdělení dlouhých úloh v JavaScriptu na menší části, které neblokují vlákno na desítky milisekund najednou.
• Snížení závislosti na těžkých knihovnách tam, kde postačí nativní řešení prohlížeče.

Následující graf ilustruje obecný princip, jak formát a komprese obrázku ovlivňují množství dat, které musí prohlížeč stáhnout před vykreslením hlavního obsahu:

Google publikuje konkrétní prahové hodnoty, podle kterých se metriky vyhodnocují jako dobré, hraniční nebo špatné.

Přesné a aktuální definice najdete v oficiální dokumentaci na web.dev/articles/vitals.

Rychlost webu SEO není jen otázka algoritmu — je to i otázka chování návštěvníka. Pomalá stránka nebo stránka s neočekávanými posuny obsahu zvyšuje míru okamžitého opuštění a snižuje šanci, že návštěvník dokončí akci, kvůli které na stránku přišel — vyplní formulář, prohlédne si reference nebo si stránku uloží a vrátí se k ní později. Zlepšení Core Web Vitals se proto vyplatí posuzovat jako součást celkové technické kvality webu, ne jako izolovaný SEO úkol.

Namísto náhodných zásahů je efektivnější postupovat podle dat:

1. Změřit aktuální stav pomocí nástrojů jako PageSpeed Insights nebo Search Console (report Core Web Vitals).
2. Identifikovat, která metrika a na kterých typech stránek (mobil vs. desktop) je nejhorší.
3. Řešit příčiny podle priority — obvykle obrázky a blokující skripty přinášejí nejviditelnější posun.
4. Opakovaně měřit po každé změně, protože optimalizace se navzájem ovlivňují.

Rozsah práce, který si optimalizace vyžádá, závisí na technologii, na které web běží, na množství třetích stran integrovaných do stránky a na tom, zda je web postavený na moderním frameworku, nebo na starší architektuře, kde je třeba řešit technický dluh. Pokud potřebujete posoudit, kde přesně váš web ztrácí body, je vhodné začít auditem — podívejte se na naše riešenia v oblasti vývoja webových aplikácií nebo si domluvte nezáväznú konzultáciu.

Optimalizace Core Web Vitals spojuje technickou práci na frontendu s reálným dopadem na SEO pozice i na chování návštěvníků. LCP, CLS a INP měří tři odlišné aspekty zkušenosti se stránkou a každý vyžaduje jiný soubor opatření — od optimalizace obrázků přes rezervaci prostoru pro dynamický obsah až po dělení JavaScriptu. Firmy, které chtějí tyto metriky zlepšit systematicky a udržitelně, se čím dál častěji obracejí na moderní technologie a ověřené postupy vývoje — víc o našem přístupu najdete v sekci vývoj na mieru nebo se podívejte na naše referencie.