Průvodce
Jak zrychlit web a zlepšit Core Web Vitals
Rychlost webu přímo ovlivňuje SEO, konverze i důvěru návštěvníků.
Níže najdete jednoduchý postup, jak zrychlit načítání a zlepšit Core Web Vitals bez zbytečných zásahů do designu.
Proč je rychlost webu tak důležitá
Rychlost webu není jen technický detail. Podle studií Googlu každá sekunda zpoždění načítání stránky snižuje konverze až o 7 %. Pokud váš web vydělává 100 000 Kč měsíčně a načítá se o dvě sekundy déle, než by mohl, přicházíte potenciálně o 14 000 Kč každý měsíc. A to nezahrnuje ztrátu návštěvníků, kteří stránku opustí ještě před jejím zobrazením.
Číst dále
Google od roku 2021 používá Core Web Vitals jako přímý rankingový signál. To znamená, že pomalý web nejen ztrácí zákazníky, ale také se hůře umisťuje ve vyhledávání. Zrychlení webu je proto jednou z nejefektivnějších investic, kterou můžete udělat.
Core Web Vitals: co měří a jaké jsou cílové hodnoty
Core Web Vitals jsou tři klíčové metriky, které Google používá k hodnocení uživatelského zážitku na webu. Pojďme si každou rozebrat do detailu.
Číst dále
LCP (Largest Contentful Paint)
LCP měří, jak rychle se zobrazí největší viditelný prvek na stránce. Obvykle jde o hlavní obrázek, video náhled nebo velký blok textu. Cílová hodnota je pod 2,5 sekundy. Hodnoty mezi 2,5 a 4 sekundami Google považuje za „potřeba zlepšení” a nad 4 sekundy za „špatné”.
Nejčastější příčiny špatného LCP jsou velké nekomprimované obrázky, pomalá odpověď serveru (TTFB), blokující CSS a JavaScript, a pomalé načítání webových fontů. Každou z těchto příčin lze vyřešit konkrétními kroky, které popisujeme níže.
CLS (Cumulative Layout Shift)
CLS měří vizuální stabilitu stránky. Sleduje, kolik se obsah na stránce posouvá během načítání. Cílová hodnota je pod 0,1. Typickým problémem jsou obrázky bez definovaných rozměrů, dynamicky načítané reklamy, fonty, které mění velikost textu po načtení, nebo elementy vkládané do stránky nad již viditelným obsahem.
CLS je zákeřná metrika, protože ji jako vývojář často nevidíte. Máte rychlé připojení a obsah se načte okamžitě. Vaši zákazníci na mobilních datech ale vidí, jak jim obsah „skáče” pod prsty. Vždy testujte s throttlingem sítě v DevTools.
INP (Interaction to Next Paint)
INP nahradil v roce 2024 metriku FID a měří odezvu stránky na interakce uživatele. Sleduje dobu od kliknutí, tapnutí nebo stisknutí klávesy do vizuální změny na stránce. Cílová hodnota je pod 200 ms. INP je výrazně přísnější než FID, protože měří všechny interakce během celé návštěvy, nejen tu první.
Špatný INP obvykle způsobuje těžký JavaScript, který blokuje hlavní vlákno prohlížeče. Dlouhé úlohy (long tasks) nad 50 ms brání prohlížeči reagovat na vstupy uživatele. Řešením je rozdělit velké skripty na menší části, používat requestIdleCallback a minimalizovat práci v hlavním vlákně.
Postup krok za krokem
1. Změřte výkon a určete priority
Použijte PageSpeed Insights pro laboratorní i terénní data. Laboratorní data ukazují simulovaný výkon, terénní data (CrUX) odrážejí reálné zkušenosti návštěvníků za posledních 28 dní. Zaměřte se na nejpomalejší šablony a stránky, ne jen na homepage. Často jsou problémové stránky produktů, kategorie s mnoha obrázky nebo stránky s embedovaným videem.
Číst dále
Doplňte měření o data z Google Analytics 4, kde v reportu Technologie najdete reálné časy načítání podle zařízení a typu připojení. Chrome DevTools nabízejí panel Performance pro detailní analýzu waterfallu a identifikaci úzkých míst.
2. Optimalizujte obrázky
Obrázky tvoří v průměru 50–60 % datového objemu stránky. Jejich optimalizace má proto největší dopad na rychlost. Používejte moderní formáty WebP a AVIF, které nabízejí o 25–50 % lepší kompresi než JPEG při stejné vizuální kvalitě. Pro maximální kompatibilitu využijte element picture s fallbackem na JPEG.
Vždy definujte atributy width a height, aby prohlížeč mohl vyhradit místo ještě před stažením obrázku. Tím eliminujete layout shift. Pro responzivní obrázky použijte atribut srcset s různými velikostmi a atribut sizes, který prohlížeči řekne, kolik místa obrázek zabere v daném viewportu.
Lazy-loading nastavte pomocí atributu loading=”lazy” na všech obrázcích, které nejsou viditelné při prvním zobrazení stránky. Hlavní obrázek (hero image) naopak označte loading=”eager” a přidejte mu link rel=”preload” v hlavičce, aby se stáhl co nejdříve a zlepšil LCP.
3. Optimalizujte skripty
JavaScript je nejčastějším viníkem špatného INP a pomalého načítání. Každý kilobajt JavaScriptu musí prohlížeč stáhnout, rozparsovat, zkompilovat a spustit. Na mobilních zařízeních je to 2–5x pomalejší než na desktopu.
Používejte atribut defer pro skripty, které nejsou kritické pro první zobrazení. Atribut async je vhodný pro nezávislé skripty jako analytiku nebo chatboty. Oba atributy zabrání blokování parsování HTML. Sloučte menší soubory do bundlů a používejte tree-shaking pro odstranění nepoužívaného kódu.
Pravidelně auditujte nainstalované skripty třetích stran. Každý chat widget, analytický nástroj, remarketingový pixel a sociální plugin přidává desítky až stovky kilobajtů JavaScriptu. Ptejte se, zda každý z nich skutečně přináší hodnotu odpovídající jeho nákladům na výkon.
4. Optimalizujte CSS
CSS je render-blokující zdroj. Prohlížeč nezobrazí stránku, dokud nestáhne a nezpracuje všechny CSS soubory. Kritický CSS (styly potřebné pro obsah nad ohybem) vložte přímo do HTML v elementu style. Zbytek načtěte asynchronně pomocí link rel=”preload” s onload přepnutím na stylesheet.
Odstraňte nepoužívané CSS. Typický WordPress web načítá 200–500 KB CSS, z čehož se na dané stránce využije jen 10–20 %. Nástroje jako PurgeCSS nebo Coverage tab v Chrome DevTools vám ukáží, které styly jsou zbytečné. Minifikujte výsledné soubory nástrojem jako cssnano.
5. Optimalizujte fonty
Webové fonty mohou způsobit jak pomalé LCP (pokud prohlížeč čeká na stažení fontu před zobrazením textu), tak CLS (pokud se font po načtení liší velikostí od fallbacku). Nastavte font-display: swap, aby prohlížeč okamžitě zobrazil text systémovým fontem a po stažení ho nahradil webovým fontem.
Přidejte link rel=”preload” pro nejdůležitější fontové soubory (typicky Regular a Bold). Omezte počet řezů na nezbytné minimum. Pokud web používá jen latinku, využijte subsetting a odstraňte znaky, které nepotřebujete. Formát WOFF2 nabízí nejlepší kompresi a je podporován všemi moderními prohlížeči.
6. Serverová optimalizace
I perfektně optimalizovaný frontend nepomůže, pokud server odpovídá pomalu. Cílový TTFB (Time to First Byte) je pod 200 ms. Nastavte správné caching hlavičky: statické soubory (obrázky, fonty, CSS, JS) by měly mít Cache-Control s max-age alespoň 1 rok a versionování v URL. HTML stránky nastavte na kratší cache nebo revalidaci.
Zapněte komprimaci pomocí Brotli (preferovaně) nebo gzip. Brotli nabízí o 15–20 % lepší kompresi než gzip. Na většině moderních serverů stačí přidat pár řádků do konfigurace. Zvažte použití CDN pro doručování statických souborů z geograficky blízkých serverů.
Hosting pro český trh
Pro české weby je klíčové, aby server byl co nejblíže cílové skupině. Ideální jsou datacentra v Praze nebo Frankfurtu. Mezi kvalitní české hostingy patří Wedos, Forpsi nebo Stable.cz pro sdílený hosting. Pro náročnější projekty zvažte VPS u Hetzner Cloud (Frankfurt) nebo Contabo. Pro statické weby je skvělou volbou Cloudflare Pages nebo Vercel s edge deploymentem v Evropě.
Kontrolní seznam
- LCP pod 2,5 s na mobilu i desktopu
- CLS pod 0,1 a stabilní layout bez posunů
- INP pod 200 ms na všech stránkách
- Obrázky ve formátu WebP/AVIF se srcset a definovanými rozměry
- Lazy-loading pro obsah pod prvním zobrazením
- Hero obrázek s preloadem a loading=”eager”
- Minifikovaný CSS/JS a odložené skripty (defer/async)
- Kritický CSS inline, zbytek asynchronně
- Fonty s display: swap, preload a WOFF2 formátem
- Brotli/gzip komprese na serveru
- Cache-Control hlavičky pro statické soubory
- TTFB pod 200 ms
Časté chyby
- Nahrávání velkých fotek bez komprese (5 MB JPEG místo 150 KB WebP)
- Obrázky bez definovaných rozměrů width/height (způsobuje CLS)
- Příliš mnoho externích widgetů a trackerů (chat, remarketing, sociální pluginy)
- Animace a parallax bez ohledu na výkon na mobilu
- Blokující skripty v <head> bez defer/async
- Načítání celého CSS frameworku kvůli pár třídám
- Příliš mnoho fontových řezů (5+ variant jednoho fontu)
- Chybějící komprese na serveru
FAQ
Jak často mám rychlost kontrolovat?
Ideálně po každé větší úpravě webu a alespoň jednou za čtvrtletí. Doporučujeme nastavit si automatický monitoring pomocí nástroje jako PageSpeed Insights API, web.dev/measure nebo SpeedCurve. Sledujte zejména terénní data v Google Search Console, která ukazují reálný výkon pro vaše návštěvníky. Po nasazení nového pluginu, změně šablony nebo přidání třetí strany vždy proveďte okamžitý test.
Stačí PageSpeed, nebo potřebuji jiné nástroje?
PageSpeed Insights je skvělý start, ale pro kompletní obraz doplňte měření reálnými daty z GA4 (report Technologie), Chrome UX Report (CrUX) a WebPageTest pro detailní analýzu waterfallu. Chrome DevTools nabízejí panel Lighthouse pro lokální testy a panel Performance pro identifikaci long tasks a problémů s INP. Pro průběžný monitoring zvažte nástroje jako SpeedCurve nebo Calibre.
Co s videem na homepage?
Video na homepage může výrazně zpomalit načítání, protože soubory jsou velké a prohlížeč je začne stahovat okamžitě. Řešením je zobrazit statický náhled (poster image) a načíst video až po interakci uživatele (kliknutí na tlačítko přehrání). Pokud video běží jako pozadí, zvažte krátkou optimalizovanou smyčku ve formátu WebM s nízkou kvalitou a rozlišením. Autoplay videa na mobilu navíc často nefungují kvůli omezením prohlížečů.
Pomůže rychlejší hosting?
Hosting ovlivňuje TTFB (Time to First Byte), což je čas od požadavku po první byte odpovědi. Pokud je váš TTFB nad 600 ms, lepší hosting může výrazně pomoct. Ale pokud je TTFB v pořádku a problém je v obrovských obrázcích nebo blokujícím JavaScriptu, hosting nic nevyřeší. Největší zisky bývají v optimalizaci médií a skriptů. Hosting řešte, až když máte frontend vyladěný.
Jak velký je rozdíl mezi WebP a JPEG?
WebP nabízí o 25–35 % lepší kompresi než JPEG při srovnatelné vizuální kvalitě. AVIF je ještě lepší s úsporou 30–50 %, ale jeho kódování je pomalejší, takže je vhodnější pro předgenerované obrázky. Praktický příklad: fotka produktu, která má jako JPEG 400 KB, bude jako WebP kolem 280 KB a jako AVIF kolem 220 KB. Při desítkách obrázků na stránce se úspora rychle sčítá.
Má smysl používat CDN pro malý český web?
Pokud cílíte pouze na české návštěvníky a máte hosting v Praze nebo Frankfurtu, CDN přinese minimální zrychlení pro statické HTML. Ale i pro malý web má CDN další výhody: automatickou kompresi, edge caching statických souborů, ochranu před DDoS a HTTP/3 podporu. Cloudflare nabízí bezplatný plán, který je pro většinu českých webů více než dostačující. Nasazení trvá asi 15 minut a stojí za to.