1. První vteřiny rozhodují víc, než si většina webů připouští
Uživatel nečeká na „hotový web“. V praxi často hodnotí stránku během prvních 1–3 sekund a už v této fázi rozhoduje, zda zůstane, nebo se vrátí zpět do výsledků vyhledávání. U mobilních zařízení je tolerance ještě nižší, protože lidé často přicházejí z rychlého impulsu, z reklam nebo z AI vyhledávání, kde očekávají okamžitou odpověď.
Data z praxe ukazují, že zpomalení načítání o každou další sekundu může výrazně snížit míru konverze. U e-commerce bývá rozdíl mezi 2 a 5 sekundami načtení často vidět na tržbách, u lead-gen webů zase na počtu odeslaných formulářů. Google navíc dlouhodobě používá signály Core Web Vitals jako součást hodnocení kvality uživatelského zážitku.
Nejde tedy jen o technický detail. Rychlost je obchodní faktor, SEO faktor i UX faktor zároveň. Pokud web „vypadá dobře“, ale načítá se pomalu, ztrácíte lidi ještě předtím, než stihnou přečíst první větu.
2. Kde web nejčastěji ztrácí výkon už na startu
Největší problémy obvykle nevznikají v jednom místě, ale v kombinaci několika slabin. Typicky jde o velké obrázky, zbytečné skripty, špatně optimalizovanou šablonu, pomalý server a příliš mnoho externích služeb. Každá z těchto věcí sama o sobě nemusí web „zabít“, ale dohromady způsobí výrazné zpoždění.
Nejčastější technické příčiny
- Příliš velké obrázky bez moderních formátů typu WebP nebo AVIF.
- Render-blocking CSS a JavaScript, které brání vykreslení první obrazovky.
- Přetížený WordPress s desítkami pluginů, z nichž část běží i tam, kde nemusí.
- Pomalý hosting bez dostatečného CPU, RAM nebo s nízkou kvalitou disků a cache vrstvy.
- Externí skripty pro chaty, heatmapy, tag management, remarketing nebo social embed.
- Absence CDN, zejména u webů s návštěvností z více zemí nebo s větším objemem médií.
Častý problém je také to, že web načítá stejné assets opakovaně na každé stránce, i když jsou potřeba jen na jediné. Například slider knihovna, fonty ve více řezech nebo celý balík ikon, z nichž se používá jen pár symbolů. To jsou zbytečné kilobajty i milisekundy navíc.
Co ukazují metriky Core Web Vitals
Pro rychlou orientaci sledujte hlavně LCP (Largest Contentful Paint), INP (Interaction to Next Paint) a CLS (Cumulative Layout Shift). Problémový web často mívá LCP nad 2,5 sekundy, INP nad 200 ms a viditelné poskakování layoutu při načítání. To už uživatel vnímá jako neprofesionální a nespolehlivé prostředí.
Pokud je největší prvek stránky obrázek hero sekce, video nebo velký blok textu s custom fontem, právě tam bývá úzké hrdlo. Pokud je problém v INP, často za to mohou JavaScriptové interakce, které blokují hlavní vlákno prohlížeče.
3. Jak přesně zjistit, co web brzdí
Bez měření se optimalizuje naslepo. Začněte tím, že si vytvoříte základní performance audit pro homepage, klíčové landing pages a nejdůležitější produktové či kategoriové stránky. Nejde o jednorázový test, ale o opakovatelný proces.
Nástroje, které dávají smysl v praxi
- Google PageSpeed Insights – rychlý přehled Core Web Vitals a konkrétní doporučení.
- Lighthouse v Chrome DevTools – technický rozbor výkonu, přístupnosti a SEO.
- WebPageTest – detailní waterfall, filmstrip a test z různých lokalit a zařízení.
- Chrome DevTools Performance – analýza JavaScriptu, main thread a long tasks.
- Google Search Console – data o stránkách s problémem v Core Web Vitals z reálného provozu.
- GA4 – doplnění o bounce rate, engagement a dopad pomalosti na chování uživatelů.
Užitečný postup je porovnat laboratorní data z PageSpeed Insights s daty z reálných uživatelů v Search Console. Laboratorní test ukáže, co je technicky špatně, ale reálná data vám řeknou, zda se problém děje u skutečných návštěvníků na mobilu, v konkrétní zemi nebo na pomalejších sítích.
Na co se při auditu zaměřit jako první
Nejdřív sledujte TTFB (Time to First Byte), tedy jak rychle server odpoví. Pokud je TTFB vysoké, problém bývá v hostingu, backendu, cache nebo databázi. Pak se dívejte na velikost hlavních assetů, počet requestů a na to, co blokuje vykreslení nad foldem.
Typický scénář: homepage má pěkné skóre v desktopu, ale na mobilu padá kvůli velkému hero obrázku, fontům z externího CDN, třem analytickým skriptům a chat widgetu. Výsledek? Stránka se sice „načte“, ale první použitelný obsah přijde pozdě a uživatel mezitím odchází.
4. Co upravit jako první, aby byl efekt vidět hned
Optimalizace výkonu má nejlepší výsledky tehdy, když postupujete v pořadí dopadu. Není nutné hned přepisovat celý web. Většinou stačí odstranit několik největších brzd a výsledky jsou viditelné během dnů, ne měsíců.
Priorita 1: obrázky a média
Nasazujte moderní formáty WebP nebo AVIF, používejte responsivní velikosti přes srcset a u obsahu pod foldem zapněte lazy loading. U hero obrázku ale lazy loading nepoužívejte, pokud je hlavním LCP prvkem. Ten naopak potřebuje prioritu a ideálně preload.
U jedné produktové kategorie může správná komprese obrázků snížit přenášená data o desítky procent. To je obrovský rozdíl hlavně na mobilu a v lokalitách s horším připojením.
Priorita 2: JavaScript a externí služby
Odstraňte vše, co není pro první obrazovku nutné. Skripty načítejte defer nebo async, odložte chaty, heatmapy a část marketingových nástrojů až po interakci nebo po souhlasu uživatele. Zvažte také audit tag manageru, protože právě tam často tiše přibývají desítky zbytečných tagů.
U moderních webů je dobrý přístup „méně, ale kvalitně“. Jeden dobře nastavený analytický stack je lepší než pět paralelních trackerů, které zpomalují prvotní vykreslení.
Priorita 3: cache, CDN a server
Pokud web běží na WordPressu, bez kvalitní cache vrstvy se výkon zbytečně propadá. Zvažte page cache, object cache a pokud je to možné, i CDN pro statické soubory. U větších webů je vhodné sledovat také databázové dotazy, protože pomalé query umí zničit TTFB i při dobrém frontendu.
U Next.js nebo headless řešení je důležité správně nastavit SSR, SSG nebo ISR podle typu obsahu. Ne každá stránka musí být generována za běhu. Čím více obsahu lze předrenderovat, tím menší zátěž na server a rychlejší odpověď pro uživatele.
5. Rychlost není jen technika, ale i SEO a konverzní problém
Pomalý web neškodí jen uživatelské zkušenosti. Ovlivňuje také crawl budget, indexaci a kvalitu signálů, které posíláte vyhledávačům. Pokud Googlebot opakovaně naráží na pomalé odpovědi serveru nebo nestabilní rendering, může to zpomalit zpracování nového obsahu.
V praxi to znamená, že rychlost je součástí on-page SEO. Stránka, která se načítá pomalu, má často horší engagement, kratší dobu na stránce a vyšší míru okamžitého opuštění. To jsou signály, které se nepřímo propisují i do výkonu ve vyhledávání.
U AI vyhledávání je situace podobná. Systémy typu Google AI Overviews nebo odpovědi v ChatGPT a Perplexity pracují s obsahem, který musí být dobře dostupný, strukturovaný a technicky čistý. Pokud je web pomalý, špatně renderovaný nebo plný zbytečných blokátorů, snižuje to šanci, že bude obsah bez problémů zpracován a citován.
Praktický checklist pro další krok
- Ověřte TTFB na homepage i klíčových landing pages.
- Vyhledejte největší LCP prvek a optimalizujte právě ten.
- Odstraňte nepotřebné pluginy, skripty a widgety.
- Převádějte obrázky do WebP/AVIF a nastavte správné velikosti.
- Projděte tag manager a vypněte duplicity měření.
- Porovnejte laboratorní a reálná data v Search Console a GA4.
Jakmile tyto kroky provedete, obvykle se rychle ukáže, kde web ztrácel lidi nejvíc. A právě v tom je pointa: většina návštěvníků neodchází proto, že by obsah nebyl dobrý. Odchází proto, že se k němu web dostává příliš pomalu.
