Proč rychlost webu rozhoduje o SEO dřív, než si toho všimne návštěvník
Google už dávno nehodnotí web jen podle obsahu a odkazů. Technická kvalita, a hlavně rychlost, je součástí toho, jak snadno dokáže vyhledávač stránku procházet, renderovat a pochopit. Když je web pomalý, Googlebot spotřebuje na jednu návštěvu víc zdrojů, prochází méně URL a u velkých webů to může znamenat i pomalejší indexaci nového obsahu.
Na uživatelské úrovni je situace ještě tvrdší. Studie napříč e-commerce i mediálními weby dlouhodobě ukazují, že každá další sekunda načítání snižuje pravděpodobnost dokončení akce. Google proto sleduje metriky Core Web Vitals a používá je jako signál kvality stránky. Nejde o to, že by pomalý web automaticky spadl z první pozice, ale v konkurenčním prostředí rozhoduje i rozdíl mezi stránkou, která je „dost dobrá“, a stránkou, která je technicky bezchybná.
Co Google skutečně měří: LCP, INP a CLS v praxi
Core Web Vitals jsou dnes základní rámec pro hodnocení uživatelské zkušenosti. Nejvíc se řeší tři metriky:
- LCP (Largest Contentful Paint) – jak rychle se zobrazí hlavní obsah stránky. Ideální hodnota je do 2,5 s.
- INP (Interaction to Next Paint) – jak rychle stránka reaguje na interakci. Dobrá hodnota je do 200 ms.
- CLS (Cumulative Layout Shift) – stabilita layoutu při načítání. Cíl je pod 0,1.
V praxi to znamená, že nestačí jen „mít rychlý server“. Pokud se uživateli zobrazí hero obrázek až po 4 sekundách, nebo se mu při načítání rozjíždí tlačítka kvůli pozdně načtenému fontu, Google to vidí jako horší zkušenost. A protože Core Web Vitals vycházejí z reálných dat uživatelů, je důležité sledovat nejen laboratorní testy, ale i field data.
Pro měření používejte kombinaci nástrojů: Google Search Console pro přehled CWV v reálném provozu, PageSpeed Insights pro doporučení a Lighthouse skóre, Chrome DevTools pro detailní diagnostiku a WebPageTest pro hlubší analýzu waterfallu, TTFB a renderu. Pokud máte větší web, vyplatí se sledovat i data z GA4 nebo RUM řešení, například SpeedCurve či New Relic Browser.
Nejčastější brzdy: obrázky, skripty, server a špatný frontend
Většina pomalých webů netrpí jedním velkým problémem, ale souhrou několika menších. Typicky jde o neoptimalizované obrázky, přetížené JavaScriptové balíky, pomalý hosting a zbytečně těžkou šablonu nebo pluginy.
1. Obrázky, které zabíjejí LCP
Na obsahových i e-commerce webech bývá největší problém hlavní obrázek. Pokud posíláte do prohlížeče 2MB JPEG bez správných rozměrů, zbytečně prodlužujete LCP. Praktický standard je používat WebP nebo AVIF, generovat více velikostí přes srcset a nastavit správný width a height. U hero sekce navíc pomáhá preload hlavního obrazového assetu.
U produktových webů často vidím, že stejný obrázek se načítá v desktopové i mobilní velikosti bez adaptivního servírování. To je zbytečná zátěž. Na mobilu běžně stačí obrázek o šířce 800–1200 px, ne 2400 px.
2. JavaScript a render-blocking zdroje
Moderní weby často trpí „JS přebytkem“. Každý slider, chat widget, heatmapa a marketingový skript přidává další kilobajty i blokování hlavního threadu. V Lighthouse sledujte hlavně Time to Interactive, dlouhé tasky a počet requestů. Problém je často v tom, že stránka sice technicky načte HTML rychle, ale obsah se vykreslí až po doběhnutí skriptů.
Řešení bývá jednoduché: odložit nepotřebné skripty pomocí defer nebo async, načítat třetí strany až po souhlasu nebo po interakci, a pravidelně auditovat, co skutečně přináší byznysový efekt. Na WordPressu to znamená často omezit počet pluginů, neinstalovat duplicitní nástroje a hlídat, co přidává každá šablona.
3. Server, TTFB a cache
Pokud má stránka vysoký TTFB, problém není v designu, ale v backendu. U WordPressu bývá viník pomalá databáze, chybějící cache, nekvalitní hosting nebo příliš složité dotazy od pluginů. U headless řešení zase může být problém v pomalém API nebo špatně nastaveném CDN.
Reálně by se TTFB měl u běžných webů pohybovat ideálně pod 800 ms, u dobře optimalizovaných projektů i výrazně níž. Pomáhá server-side caching, object cache, CDN jako Cloudflare nebo Fastly, správné HTTP cache hlavičky a komprese Brotli nebo gzip. Pokud hosting nedokáže držet stabilní výkon v špičce, žádná frontendová optimalizace to plně nezachrání.
Jak rychlost ovlivňuje crawl budget a indexaci
U menších webů si Google většinou poradí i s horší technikou. U větších webů, e-shopů a obsahových portálů už ale rychlost přímo ovlivňuje, kolik URL Googlebot zvládne projít za jednotku času. Když server odpovídá pomalu, bot snižuje frekvenci návštěv, a to může zpomalit indexaci nových produktů, článků i změn na stránkách.
To je důležité hlavně pro weby s častými aktualizacemi. Pokud publikujete desítky nových URL denně, ale server je přetížený a render trvá dlouho, Google nemusí změny zachytit tak rychle, jak by měl. V Search Console je pak vidět vyšší doba procházení, nižší efektivita crawlingu a někdy i kolísání v index coverage.
Prakticky doporučuji sledovat v logách:
- četnost návštěv Googlebotem podle sekcí webu,
- průměrný čas odpovědi serveru,
- stránky s opakovaným crawlitem bez změn,
- URL, které se indexují pomalu nebo vůbec.
Na větších webech se vyplatí log analysis nástroje jako Screaming Frog Log File Analyser, Elastic Stack nebo Splunk. Díky nim poznáte, jestli Google tráví čas na důležitých stránkách, nebo se zbytečně zasekává na parametrech, filtrování a nekvalitních URL.
Co udělat jako první: rychlý audit a prioritizace zásahů
Největší chyba je začít „optimalizovat všechno“. Správný postup je nejdřív zjistit, co má na webu největší dopad na uživatele i vyhledávač. U každého projektu si proto rozdělte problémy na tři vrstvy: měření, technický zásah a obchodní dopad.
Začněte tímto pořadím:
- Změřte baseline v PageSpeed Insights, Search Console a WebPageTest.
- Identifikujte LCP prvek a zjistěte, proč se načítá pozdě.
- Omezte třetí strany – chaty, pixely, tagy, embedované widgety.
- Optimalizujte obrázky a nastavte lazy loading jen tam, kde dává smysl.
- Zrychlete server přes cache, CDN a lepší hosting.
- Otestujte změny na reálných datech, ne jen v lab reportu.
Pokud spravujete WordPress, často přinese největší efekt kombinace: kvalitní hosting, cache plugin typu WP Rocket nebo LiteSpeed Cache, obrazová optimalizace přes ShortPixel nebo Imagify a redukce pluginů. U Next.js nebo jiných moderních frontendů zase dává smysl hlídat bundling, code splitting, server rendering a správné lazy loading strategie.
Rychlost není jen SEO signál, ale přímý byznysový faktor
Pomalý web neškodí jen pozicím. Zhoršuje i konverzní poměr, zvyšuje bounce rate a oslabuje důvěru. U e-shopu může být rozdíl mezi 2,2 a 4,5 sekundami rozhodující pro to, jestli uživatel přidá produkt do košíku, nebo odejde ke konkurenci. U leadových webů zase zpomalení formuláře nebo sekce s kontaktem snižuje počet odeslaných poptávek.
Proto se vyplatí rychlost sledovat jako součást pravidelného technického SEO auditu. Ne jednou za rok, ale průběžně. Každá nová integrace, šablona, plugin nebo marketingový skript může web zpomalit víc, než čekáte. A Google na to reaguje dřív, než to většina lidí stihne pojmenovat jako problém.
