Proč je jedna sekunda často rozdíl mezi návštěvou a odchodem
Rychlost webu už dávno není jen komfortní parametr. Google ji používá jako signál kvality stránky a uživatel ji vnímá jako součást důvěryhodnosti značky. Studie Google dlouhodobě ukazují, že s prodlužující se dobou načítání roste pravděpodobnost odchodu; například při nárůstu z 1 na 3 sekundy může bounce rate výrazně stoupat. V e-commerce je to ještě citlivější, protože zpomalení o desetiny sekundy ovlivňuje počet přidání do košíku i dokončených objednávek.
V praxi neřešíte jen „rychlý web“, ale celý řetězec: server, síť, renderování, JavaScript, obrázky, fonty a třetí strany. Google navíc nehodnotí rychlost abstraktně, ale skrze metriky jako LCP, INP a CLS. Pokud vám web působí rychle, ale hlavní obsah se zobrazí pozdě nebo stránka při načítání skáče, pro vyhledávač je to stále problém.
Jak Google rychlost měří a co z toho opravdu plyne
Nejdůležitější je přestat sledovat jen průměrnou dobu načtení. Ta často nic neříká o tom, kdy uživatel skutečně vidí hlavní obsah nebo kdy může kliknout na tlačítko. Pro SEO i UX jsou klíčové tři metriky:
- LCP (Largest Contentful Paint) – kdy se zobrazí největší viditelný prvek stránky, ideálně do 2,5 s.
- INP (Interaction to Next Paint) – jak rychle stránka reaguje na interakci, ideálně pod 200 ms.
- CLS (Cumulative Layout Shift) – jak moc se stránka při načítání „rozjíždí“, ideálně pod 0,1.
Pro měření používejte kombinaci nástrojů Google PageSpeed Insights, Lighthouse, Search Console a Chrome DevTools. PageSpeed Insights vám ukáže jak laboratorní, tak reálná data z terénu. Search Console pak v reportu Core Web Vitals odhalí, které URL mají problém v reálném provozu, ne jen v testu na simulovaném zařízení.
Velmi důležité je sledovat data po šablonách, ne jen po jednotlivých URL. Homepage, produktová karta, kategorie a blogový článek mají často úplně jiné bottlenecky. Jinak řečeno: na blogu vás může brzdit font a reklamy, na e-shopu zase produktová galerie, filtr nebo recenze z externí služby.
Kde se výkon nejčastěji ztrácí: nejdražší chyby v praxi
Největší problém bývá, že web není pomalý „celý“, ale několik konkrétních komponent ho táhne dolů. V auditů se opakují hlavně tyto chyby:
- Příliš velké obrázky – často 2–5 MB na stránku, bez WebP/AVIF a bez správného resize.
- Přetížený JavaScript – zbytečné knihovny, slider, chat widgety, heatmapy a tracking skripty.
- Blocking resources – CSS a JS, které blokují vykreslení nad přehybem.
- Pomalý hosting nebo server – vysoký TTFB, špatná cache, slabý backend.
- Fonty a externí služby – Google Fonts, mapy, videa, recenze, consent management platformy.
Typický příklad: web má moderní design, ale hero obrázek na homepage má 3,8 MB, k tomu běží tři marketingové pixely, chatbot, cookie lišta a několik reklamních skriptů. Výsledek? LCP přes 4 sekundy, INP nad 300 ms a uživatel má pocit, že stránka „zamrzá“. Google to vyhodnotí jako slabou uživatelskou zkušenost a na konkurenčním klíčovém slově vás může snadno předběhnout rychlejší stránka s lepším technickým základem.
Pro audit je užitečné spustit WebPageTest nebo Lighthouse s filmstripem. Dívejte se na to, kdy se objeví první smysluplný obsah, ne kdy „dojede“ loader. Loader totiž často zakrývá problém místo toho, aby ho řešil.
Co má největší dopad na SEO i konverze: prioritní zásahy
Ne každý technický zásah má stejnou návratnost. Pokud chcete rychlý efekt, začněte tam, kde se výkon ztrácí nejvíc a kde je dopad na UX největší.
1. Optimalizace obrázků
Nasazujte AVIF nebo WebP, používejte responsivní varianty přes srcset a sizes a nastavte lazy loading pouze pro obsah pod přehybem. U hero obrázku naopak lazy loading často škodí, protože zpomaluje LCP. Pokud je hlavní vizuál součástí konverzní stránky, měl by být prioritně načtený, ideálně přes preloading.
2. Redukce JavaScriptu
Každý script se musí obhájit. Zkontrolujte, zda opravdu potřebujete všechny pluginy, A/B testovací nástroje, heatmapy a chaty. U WordPressu bývá problém v tom, že se přidává funkce po funkci a web pak načítá desítky souborů kvůli jedné malé úpravě. V moderních projektech pomáhá code splitting, lazy loading komponent a odkládání neklíčového JS.
3. Server, cache a TTFB
Pokud je Time to First Byte vysoké, problém není v designu, ale v backendu nebo hostingu. Pomáhá server-side cache, CDN, optimalizace databáze, HTTP/2 nebo HTTP/3 a správné nastavení komprese Brotli/Gzip. U WordPressu má velký dopad kvalitní cache vrstva a odlehčení těžkých dotazů do databáze.
4. Fonty a layout shift
Vlastní fonty mohou způsobit zpoždění i poskakování obsahu. Používejte jen potřebné řezy, nastavte font-display: swap a ideálně self-hosting. Pro CLS je důležité předem rezervovat rozměry obrázků, bannerů i embedů, aby se stránka během načítání nepřepočítávala.
Jak zrychlit web bez slepého honění skóre v PageSpeed
Skóre v PageSpeed Insights je užitečné, ale samo o sobě nic neprodává. Cílem není „100 bodů“, ale rychlejší vnímaná odezva a lepší obchodní výkon. Proto je potřeba pracovat prioritně podle dopadu:
- Nejprve opravte LCP na hlavních vstupních stránkách – homepage, kategorie, produkt, landing page.
- Poté snižte INP – hlavně na stránkách s formuláři, filtrováním a interakcí.
- Udržte nízký CLS – především u reklam, cookie lišt, bannerů a dynamických bloků.
V praxi se vyplatí vytvořit si seznam „kritických šablon“ a měřit je průběžně. Pro e-shop to bývá homepage, kategorie, detail produktu a košík. Pro obsahový web zase homepage, článek a interní vyhledávání. Jakmile máte baseline, můžete testovat dopad jednotlivých změn: komprese obrázků, odstranění pluginu, změna hostingu, přesun skriptů do footeru nebo zavedení edge cache.
U větších webů dává smysl i RUM monitoring přes nástroje jako SpeedCurve, New Relic, Datadog nebo vlastní sběr přes web-vitals. Díky tomu vidíte reálné chování uživatelů na různých zařízeních, v různých zemích a s různou kvalitou připojení. To je zásadní, protože laboratoř vám neukáže, jak se web chová na starším Androidu na mobilní síti.
Rychlost jako součást SEO strategie, ne jen technický úkol
Výkonnost webu má přímý dopad na crawl budget, indexaci i kvalitu signálů od uživatelů. Pomalé stránky Google prochází méně efektivně, uživatelé na nich méně interagují a častěji se vrací zpět do výsledků vyhledávání. To je přesně ten moment, kdy vás konkurence předběhne nejen lepší nabídkou, ale i lepším technickým zážitkem.
Pokud chcete postupovat systematicky, nastavte si měsíční proces: technický audit, kontrola Core Web Vitals v Search Console, test hlavních šablon v Lighthouse a vyhodnocení dopadu na konverze v GA4. Sledujte nejen rychlost, ale i míru opuštění, scroll depth, CTR z organiku a dokončené cíle. Teprve kombinace těchto dat vám ukáže, jestli rychlost skutečně pomáhá byznysu.
Největší chyba je čekat, až se výkon „nějak“ zlepší s novým designem. Rychlost je dnes konkurenční výhoda, kterou uživatel pozná během prvních vteřin a Google ji dokáže vyhodnotit ještě dřív, než si přečte váš nadpis. Pokud web reaguje okamžitě, máte vyšší šanci získat klik, důvěru i konverzi. Pokud ne, je dost možné, že zákazník odejde dřív, než se stránka vůbec stihne ukázat.
