Proč je sekunda navíc dnes problém
Rychlost webu se dávno nehodnotí jen podle pocitu. Google sleduje reálné signály uživatelské zkušenosti a mezi nejdůležitější patří Core Web Vitals. Pokud se stránka načítá pomalu, uživatel často ani nečeká na kompletní zobrazení obsahu. Z pohledu SEO je důležité, že pomalý web bývá hůře crawlovaný, hůře indexovaný a v konkurenčních výsledcích ztrácí náskok.
Prakticky platí jednoduché pravidlo: čím těžší stránka, tím větší riziko propadu. U e-shopu s fotografiemi, filtry, skripty a trackingem bývá rozdíl mezi 1,5 s a 2,5 s na mobilu znatelný nejen v datech, ale i v tržbách. U obsahového webu se zase pomalé načítání podepisuje na vyšší míře odchodů a nižším počtu zobrazených stránek na návštěvu.
Co Google sleduje: LCP, INP a CLS bez marketingových zkratek
V praxi je potřeba rozumět třem metrikám, které tvoří jádro Core Web Vitals:
- LCP (Largest Contentful Paint) – kdy se zobrazí největší viditelný prvek stránky, typicky hero obrázek nebo hlavní nadpisový blok.
- INP (Interaction to Next Paint) – jak rychle web reaguje na interakci, například kliknutí na menu nebo filtr.
- CLS (Cumulative Layout Shift) – jak moc se obsah „posouvá“ při načítání, tedy zda stránka neskáče pod kurzorem.
Google dlouhodobě doporučuje držet LCP pod 2,5 s, INP pod 200 ms a CLS pod 0,1. Nejde ale jen o splnění limitu. Důležitější je, co metriky znamenají pro uživatele. Pokud se hlavní obsah objeví až po 4 sekundách, návštěvník má pocit, že web nereaguje. Pokud se po kliknutí na tlačítko nic nestane, vnímá to jako chybu, i když technicky stránka „běží“.
Kde se výkon webu nejčastěji ztrácí
Ve většině auditů se opakují stejné problémy. Prvním viníkem bývají příliš velké obrázky. Na mobilu se stále setkávám s bannery v originální velikosti 3000 px, i když reálně stačí 1200 px a moderní formát AVIF nebo WebP. Druhým problémem jsou neoptimalizované skripty třetích stran – chaty, heatmapy, remarketing, consent management, AB testy nebo víc měřicích kódů najednou.
Další častý zdroj zpomalení je render-blocking CSS a JavaScript. Pokud prohlížeč musí nejdřív stáhnout a zpracovat velký JS balík, stránka se sice technicky načítá, ale uživatel ještě nic nevidí. To je typické u těžkých šablon ve WordPressu, u špatně nastaveného builderu nebo u aplikací bez rozumného splitování kódu.
U e-shopů bývá problém i v produktových filtrech a neefektivních dotazech do databáze. U redakčních webů zase často zpomaluje reklama, embedovaný obsah a fonty. A u moderních webů postavených v Next.js nebo jiném frameworku se někdy podcení serverový rendering, cache a velikost JS bundle.
Jak rychlost změřit správně, ne jen „od oka“
Největší chyba je hodnotit výkon pouze podle pocitu nebo jednoho testu v Chrome. Rychlost se musí měřit ve dvou rovinách: laboratorní data a reálná data uživatelů.
Pro rychlou diagnostiku doporučuji tento postup:
- PageSpeed Insights – ukáže Core Web Vitals, laboratorní i field data z CrUX, pokud jsou k dispozici.
- Google Search Console – sekce „Core Web Vitals“ odhalí URL skupiny, které mají problém na mobilu i desktopu.
- Lighthouse v Chrome DevTools – vhodné pro technický rozbor konkrétní stránky.
- WebPageTest – ideální pro detailní waterfall, test z různých lokalit a zařízení.
- GA4 – sledujte dopad na engagement, konverze a bounce podobné metriky v kontextu rychlosti.
Užitečný je i pohled přes Server-Timing, TTFB a INP. Pokud má web vysoké TTFB, problém bývá na serveru, v cache, v databázi nebo v backendové logice. Pokud je TTFB dobré, ale LCP špatné, je problém spíš v frontendu, obrázcích nebo kritickém CSS. Tímto způsobem se vyhnete slepému „optimizování všeho“.
Co má největší dopad: 10 praktických zásahů
Nejúčinnější úpravy jsou obvykle ty, které zmenší objem dat a zrychlí render. V praxi se osvědčuje následující pořadí:
- Optimalizujte obrázky – používejte AVIF/WebP, správné rozměry, lazy loading pod foldem a kompresi bez viditelné ztráty kvality.
- Odložte nekritické skripty – atributy defer a async, případně načítání až po interakci.
- Zaveďte cache na více úrovních – browser cache, server cache, object cache, CDN.
- Snižte počet fontů a variant – ideálně 1–2 řezy, self-hosting, preload jen pro skutečně kritické soubory.
- Minimalizujte CSS – kritické CSS inline, zbytek načíst později.
- Omezte třetí strany – každý script navíc je riziko pro LCP i INP.
- Odstraňte nepoužívaný JavaScript – často tvoří desítky procent bundle bez reálné hodnoty.
- Optimalizujte backend – databázové dotazy, transients, object cache, serverové limity.
- Používejte CDN – zejména pro globální návštěvnost a statické soubory.
- Testujte na mobilním zařízení – pomalý Android na 4G odhalí problémy, které na výkonném notebooku nevidíte.
Typický příklad z praxe: po zmenšení hero obrázku z 1,8 MB na 220 kB, odložení dvou marketingových skriptů a zavedení cache se LCP zlepšilo z 4,1 s na 2,3 s. U stejného webu klesla i míra odchodu z landing page o 17 % a vzrostl počet odeslaných formulářů. To je přesně ten typ změny, který má smysl i pro SEO i pro byznys.
Jak rychlost zapadá do technického SEO a indexace
Rychlost webu není izolovaný problém. Z pohledu technického SEO ovlivňuje, jak efektivně Googlebot prochází web, jak rychle zpracuje nové URL a jak často se vrací na důležité stránky. Na pomalém webu může být crawl budget využíván méně efektivně, zejména u rozsáhlých webů s parametry, faceted navigací a tisíci produktových URL.
U JavaScriptových webů je důležité také to, zda je obsah dostupný bez dlouhého čekání na klientský render. Pokud je hlavní obsah generovaný až po načtení těžkého JS, Google sice často stránku zvládne, ale proces je pomalejší a méně spolehlivý. To platí zejména u nových webů, které spoléhají na moderní frameworky bez správně nastaveného server-side renderingu nebo prerenderingu.
SEO tým by měl proto rychlost řešit spolu s vývojáři a UX, ne jako samostatnou disciplínu. Praktický workflow může vypadat takto: nejdřív identifikovat skupiny URL s nejhoršími CWV v Search Console, pak v PageSpeed Insights a WebPageTest najít hlavní bottleneck, následně upravit šablonu, assety nebo backend a nakonec změny ověřit na reálných datech v GA4 a Search Console. Jen tak poznáte, jestli se optimalizace skutečně promítla do lepší viditelnosti, engagementu a konverzí.
Jak udržet výkon dlouhodobě pod kontrolou
Jednorázová optimalizace nestačí. Web se postupně zpomaluje tím, jak přibývají pluginy, tracking kódy, nové šablony, obsahové bloky a marketingové nástroje. Proto má smysl nastavit pravidelný proces kontroly výkonu, ideálně jednou měsíčně nebo po každé větší úpravě webu.
V praxi doporučuji hlídat tyto body:
- automatické testy výkonu v CI/CD nebo alespoň po nasazení nové verze,
- alerty v Search Console při zhoršení Core Web Vitals,
- monitoring TTFB a chybovosti serveru,
- kontrolu nových skriptů třetích stran před nasazením,
- pravidelné čištění pluginů a nevyužitého kódu,
- měření na mobilu, ne jen na desktopu.
Pokud chcete rychlost využít jako konkurenční výhodu, berte ji jako součást SEO strategie i produktového řízení webu. Google si zpomalení všimne dřív než lidé, protože ho měří v signálech, ne v dojmu. A právě proto je výkon jedním z mála technických faktorů, který dokáže současně zlepšit viditelnost, použitelnost i obchodní výsledky.
