Co se děje v prvních vteřinách po kliknutí
Když uživatel klikne na výsledek ve vyhledávání nebo reklamu, nezačíná „čekat na web“ jen pasivně. Během prvních 1–3 sekund si podvědomě vytváří dojem, zda stránka funguje, zda je důvěryhodná a jestli má smysl zůstat. Pokud se nic neděje, nebo se stránka zobrazí rozbitě, odchod je často okamžitý. U mobilních uživatelů je tolerance ještě nižší, protože připojení bývá horší a pozornost kratší.
Google i další nástroje dnes hodnotí výkon přes metriky jako LCP (Largest Contentful Paint), INP (Interaction to Next Paint) a CLS (Cumulative Layout Shift). Pro běžný web je dobrý cíl držet LCP do 2,5 s, INP pod 200 ms a CLS pod 0,1. Pokud jsou hodnoty horší, nejde jen o SEO problém — web ztrácí lidi ještě předtím, než vůbec stihnou číst obsah.
Nejčastější důvody, proč stránka „nestihne začít“
V praxi většinou nejde o jedinou chybu, ale o několik drobných problémů, které se sčítají. Typicky vidíme kombinaci těžkých obrázků, zbytečných JavaScriptů, pomalého serveru a špatného pořadí načítání prvků. Na desktopu to může být jen nepříjemné, na mobilu už fatální.
1. Příliš velké a špatně optimalizované obrázky
Obrázky bývají největší část přenesených dat. Pokud má hero banner 2–4 MB, stránka se sice „nějak“ načte, ale LCP se dramaticky zhorší. Běžná praxe je převádět obrázky do formátů WebP nebo AVIF, používat správné rozměry a lazy loading jen tam, kde to dává smysl. Nad foldem by se hlavní vizuál naopak měl načítat prioritně.
2. Zbytečně těžký JavaScript
Mnoho webů načítá desítky skriptů: trackování, chat widgety, A/B testy, cookie lišty, mapy, animace, různé pluginy. Každý z nich zvyšuje čas do interakce a může blokovat vykreslení. Pokud má stránka například 1,5 MB JS bundle a ještě několik externích skriptů, uživatel vidí prázdnější obrazovku déle, než je přijatelné. V Next.js nebo moderním frontendu je klíčové dělit skripty podle potřeby a odkládat vše, co není nutné pro první render.
3. Pomalý server nebo nevhodný hosting
I perfektně optimalizovaný frontend ztrácí výkon, když server odpovídá pomalu. Sledujte TTFB (Time to First Byte) — u kvalitního webu by měl být ideálně pod 200–500 ms. Pokud je TTFB přes 800 ms, problém bývá v hostingu, databázi, cache nebo v příliš složitém backendu. U WordPressu je častý scénář: moc pluginů, žádná objektová cache, pomalý sdílený hosting a nevhodně nastavená databáze.
4. Layout shift a vizuální chaos
Uživatel nemusí odejít jen kvůli pomalému načtení, ale i kvůli tomu, že se stránka při renderování „hýbe“. Typicky se posouvají tlačítka, bannery nebo text, protože se později dočítají fonty, reklamy nebo obrázky bez rezervovaného prostoru. Pokud klikne na tlačítko a ono se o kus posune, vzniká frustrace a ztrácí se důvěra. CLS je v tomto směru velmi praktická metrika, protože přesně ukazuje, kde stránka působí neklidně.
Jak poznat, kde přesně web ztrácí návštěvníky
Bez měření se rychlost řeší naslepo. Základní diagnostika by měla začít v Google Search Console, PageSpeed Insights, Lighthouse a v reálných datech z GA4. Rozdíl mezi laboratorním a reálným měřením je zásadní: Lighthouse ukáže potenciál, ale skutečné chování uživatelů zachytí až CrUX nebo RUM data z nástrojů jako SpeedCurve, New Relic nebo DebugBear.
Praktický postup je jednoduchý:
- 1. Změřte homepage, kategorie a klíčové landing pages. Neoptimalizujte jen hlavní stránku.
- 2. Sledujte TTFB, LCP, INP a CLS zvlášť pro mobil. Mobil bývá slabé místo.
- 3. Porovnejte rychlost s odchodovostí. V GA4 si všímejte bounce rate, engagement rate a času do prvního engagementu.
- 4. Najděte, co blokuje render. Pomůže Chrome DevTools, waterfall v WebPageTest nebo report „Eliminate render-blocking resources“ v Lighthouse.
Jeden e-shop, který jsme auditovali, měl LCP kolem 6,8 s na mobilu. Hlavní problém nebyl samotný server, ale kombinace nekomprimovaných obrázků, dvou chat widgetů, několika marketingových pixelů a hero sekce s videem. Po odložení skriptů, kompresi médií a zavedení CDN klesl LCP na 2,9 s. To se promítlo nejen do SEO, ale i do vyššího počtu přidání do košíku.
Co upravit jako první, aby byl rozdíl vidět rychle
Největší návratnost mívají změny, které zrychlí první render a sníží množství dat v úvodu načítání. Nemá smysl začínat redesignem, pokud web nejdřív neumí rychle zobrazit základní obsah.
Optimalizujte kritickou cestu vykreslení
Kritická cesta znamená vše, co je nutné pro zobrazení nad foldem. Sem patří HTML, hlavní CSS, důležitý font a klíčový obrázek. Zbytek odkládejte. U moderních webů je výhodné používat critical CSS, preconnect na důležité domény a správně nastavené preloady. Pokud je nad foldem jen text a CTA, stránka může být vizuálně použitelná mnohem dřív než plně dojede zbytek skriptů.
Zbavte se nadbytečných pluginů a skriptů
Na WordPressu je to velmi častý problém. Každý plugin má své CSS, JS a někdy i vlastní databázové dotazy. Zkontrolujte, co skutečně používáte. Pluginy pro statistiky, cookie lišty, recenze, popupy a formuláře často dělají více škody než užitku, pokud nejsou dobře nastavené. V praxi je lepší mít jeden kvalitní nástroj než pět různých skriptů, které se navzájem zpomalují.
Cache, CDN a komprese nejsou volitelný bonus
Správně nastavená cache může snížit zátěž serveru a výrazně zrychlit odpověď. U statického obsahu pomůže CDN, která doručuje data z bližší lokace. Komprese Brotli nebo gzip je dnes standard, stejně jako HTTP/2 nebo HTTP/3. Pokud tyto technologie nemáte, web zbytečně přichází o výkon, který je technicky snadno dostupný.
Jak rychlost souvisí se SEO, AI vyhledáváním a konverzemi
Rychlost není jen technický parametr. Pro vyhledávače je součástí kvality stránky a pro uživatele velmi konkrétní signál důvěry. Pokud stránka působí pomalu, zvyšuje se pravděpodobnost návratu do SERPu, což je negativní behaviorální signál. U AI Overviews a dalších AI vyhledávacích rozhraní je navíc stále důležitější, aby byl obsah rychle dostupný, dobře strukturovaný a snadno čitelný pro crawler i model.
U e-commerce je dopad ještě přímější. Zpomalení o jednu sekundu může znamenat nižší konverzní poměr, zejména na mobilu. U lead-gen webů zase pomalý formulář snižuje počet odeslání. Není výjimkou, že po zrychlení webu stoupne engagement rate, prodlouží se doba na stránce a současně klesne okamžitý odchod. To je přesně ten moment, kdy se performance mění z „IT tématu“ na obchodní metriku.
Praktický checklist pro majitele webu i vývojáře
Pokud chcete postupovat systematicky, zaměřte se na tyto kroky:
- Změřte aktuální stav v PageSpeed Insights, Search Console a WebPageTest.
- Identifikujte nejhorší šablony — homepage, produkt, kategorie, článek, landing page.
- Optimalizujte obrázky do WebP/AVIF a nastavte správné rozměry.
- Omezte JavaScript, odložte externí skripty a zrušte nepoužívané pluginy.
- Zrychlete server přes cache, CDN, kvalitnější hosting a úpravy databáze.
- Hlídajte CLS rezervací prostoru pro bannery, fonty a dynamické bloky.
- Testujte na mobilu, ne jen na výkonném desktopu s rychlou sítí.
Nejlepší strategie není „udělat web rychlý jednou“, ale průběžně hlídat, co výkon zhoršuje. Jakmile přidáte nový plugin, marketingový skript nebo vizuální prvek, měl by projít stejným testem jako jakákoli jiná změna. Jen tak se nestane, že web začne ztrácet lidi ještě před načtením, aniž by si toho někdo všiml.
