Proč web zpomaluje víc, než si většina lidí myslí
Když majitel webu vidí pomalé načítání, často obviní hosting, šablonu nebo „příliš mnoho pluginů“. Tyto faktory mohou hrát roli, ale v praxi se velmi často opakuje jeden vzorec: stránku brzdí jediný velký prvek nad foldem, typicky obrázek, video background nebo slider. A právě ten rozhoduje o tom, kdy uživatel uvidí hlavní obsah a kdy Google vyhodnotí stránku jako dostatečně rychlou.
U Core Web Vitals je nejcitlivější metrika LCP (Largest Contentful Paint). Ta měří, kdy se zobrazí největší viditelný prvek v úvodní části stránky. Pokud je tímto prvkem hero obrázek o velikosti 1,8 MB, může být problém i na jinak dobře optimalizovaném webu. Pro představu: na pomalejším mobilním připojení se takový soubor může načítat několik sekund, zatímco dobře optimalizovaný obrázek WebP nebo AVIF často spadne na 80–200 kB.
To je důvod, proč se výkon webu nedá posuzovat jen podle „rychlosti serveru“. Rozhoduje i to, co se musí stáhnout jako první, jak je obsah poskládaný a zda prohlížeč nemusí čekat na zbytečně velká data.
Nejčastější zbytečnost: velké obrázky, bannery a hero sekce
Největší viník bývá paradoxně prvek, který má webu pomoci prodávat nebo působit vizuálně atraktivně. Typicky jde o hlavní banner na homepage, úvodní fotku služby, produktový slider nebo background video. Tyto prvky bývají nahrané v příliš vysokém rozlišení, bez komprese a často i v nevhodném formátu.
V praxi jsem opakovaně viděl stránky, kde:
- hero obrázek měl 3–6 MB,
- na mobil se stahoval stejný soubor jako na desktop,
- slider načítal 4–6 fotografií najednou, i když uživatel viděl jen jednu,
- background video běželo automaticky bez ohledu na připojení a zařízení.
Výsledek? LCP nad 4 sekundy, někdy i výrazně víc. To už je z pohledu UX i SEO problém. Google dlouhodobě doporučuje držet LCP ideálně pod 2,5 s, a čím víc se od této hranice vzdalujete, tím větší je riziko horší uživatelské zkušenosti i slabšího organického výkonu.
Největší zbytečnost tedy není „mít obrázky“, ale mít je špatně připravené. Rozdíl mezi 2MB a 120kB souborem je obrovský, a přitom pro běžného návštěvníka vizuálně často téměř nerozeznatelný.
Jak poznáte, že problém je právě v médiích
Než začnete upravovat codebase nebo měnit hosting, ověřte si, co přesně zpomaluje první vykreslení stránky. Nejrychlejší cesta je kombinace nástrojů PageSpeed Insights, Lighthouse, WebPageTest a Chrome DevTools.
V reportu sledujte hlavně:
- LCP element – co je největší viditelný prvek,
- TTFB – jestli server nečeká zbytečně dlouho,
- render blocking resources – zda CSS/JS neblokuje vykreslení,
- properly size images – jestli nejsou obrázky větší, než mají být,
- serve images in next-gen formats – zda používáte moderní formáty.
Velmi praktický test je jednoduchý: otevřete stránku v anonymním okně, zpomalte síť v DevTools na Fast 3G nebo Slow 4G a sledujte, co se načte jako první. Pokud se dlouho zobrazuje prázdná plocha nebo rozmazaný placeholder, zatímco hlavní obrázek dorazí až po několika sekundách, máte jasného kandidáta na optimalizaci.
Další indikátor najdete v HTML a waterfallu. Jestli se hned na začátku stahuje obrovský JPEG, často s parametrem width mnohem větším, než je reálná šířka containeru, problém je zřejmý. U WordPressu je to časté u šablon, které generují obrázky bez důsledného využití srcset a sizes.
Co s tím udělat hned: konkrétní úpravy, které mají největší dopad
Nejúčinnější bývá postupovat od největšího dopadu. U médií platí několik jednoduchých pravidel, která často zlepší výkon během jednoho dne.
- Převést obrázky do WebP nebo AVIF – u běžných fotografií bývá úspora 30–70 % oproti JPEG.
- Správně dimenzovat soubory – obrázek by neměl být výrazně větší než zobrazovaná plocha.
- Nepoužívat slider jako hlavní sdělení – každý další slide zvyšuje počet requestů a často i CLS.
- Lazy loadovat obsah pod foldem – ale ne hero obrázek; ten naopak potřebuje prioritu.
- Komprimovat a odstranit metadata – zejména u produktových a ilustračních fotografií.
- Použít CDN – u image-heavy webů výrazně pomáhá stabilitě i rychlosti doručení.
U důležitých obrázků nad foldem je vhodné nastavit preload a případně i vyšší prioritu načtení. Naopak všechny dekorativní prvky, které nejsou pro první obsahovou vrstvu nutné, mohou čekat. To je přesně ten rozdíl mezi webem, který působí rychle, a webem, který jen „má rychlý server“.
Pokud používáte WordPress, vyplatí se zkontrolovat, zda plugin pro optimalizaci obrázků skutečně vytváří více velikostí a servíruje správnou variantu podle zařízení. U některých instalací se sice soubory komprimují, ale web dál posílá desktopový rozměr i na mobil. To je typická zbytečná brzda.
Jak se měří skutečný přínos a proč nestačí jen zelená čísla v testu
Jedna z častých chyb je spoléhat se jen na „dobré skóre“ v PageSpeed Insights. To je užitečný orientační nástroj, ale skutečný výkon se pozná v datech z provozu. Sledujte proto kombinaci laboratorních a reálných dat.
V Google Search Console najdete report Core Web Vitals, který ukazuje, jak si web vede na skutečných uživatelích. V GA4 můžete sledovat dopad rychlosti na engagement, konverze nebo míru opuštění. Pokud po optimalizaci hero obrázku klesne LCP z 4,3 s na 2,1 s, často uvidíte i praktický dopad na chování uživatelů: více scrollů, delší dobu na stránce a vyšší počet odeslaných formulářů.
U e-commerce je to ještě viditelnější. Zpoždění o jednu sekundu v úvodním načtení může znamenat citelný propad v přechodu do detailu produktu nebo do košíku. Nejde o univerzální číslo pro každý web, ale trend je stabilní: čím dřív uživatel vidí relevantní obsah, tím vyšší je šance na další akci.
Praktický postup je jednoduchý:
- změřte stav před úpravou,
- identifikujte LCP element,
- optimalizujte největší média,
- znovu změřte v Lighthouse i v reálných datech,
- porovnejte dopad na konverzní poměr a engagement.
Kdy už problém není v jedné zbytečnosti, ale v celém přístupu
Pokud jste obrázky a bannery optimalizovali, ale web je pořád pomalý, je čas hledat druhou vrstvu problému. Často jde o kombinaci těžkého frontendu, zbytečných skriptů a nepřehledného tag managementu. Typická situace: stránka načítá několik marketingových pixelů, chat widget, heatmapu, AB testovací nástroj a k tomu ještě deset dalších JS knihoven. Výsledkem není jen delší načítání, ale i horší INP, tedy pomalejší reakce na interakci.
V této fázi už má smysl udělat technický audit. Zkontrolujte:
- kolik JS souborů se načítá a zda jsou všechny opravdu nutné,
- jestli se skripty nenačítají synchronně,
- zda nejsou obrázky a fonty blokované nevhodným nastavením cache,
- jestli server odpovídá rychle i při vyšší zátěži,
- zda se na mobilu neservíruje stejný objem dat jako na desktopu.
Je ale důležité začít tam, kde je největší efekt. A v naprosté většině případů to bývá právě zbytečně těžký vizuální obsah v úvodní části stránky. Když odstraníte nebo opravíte tento jeden problém, web se často zrychlí výrazně víc než po drahém upgradu hostingu. A to je důvod, proč se vyplatí dívat se na performance analyticky, ne pocitově.
