Proč obrázky zpomalují web víc, než se zdá
Obrázek na stránce není jen vizuální prvek. Prohlížeč ho musí stáhnout, dekódovat, často změnit velikost, někdy načíst z pomalejšího serveru a teprve potom ho může zobrazit uživateli. Když je obrázků na stránce více, jejich vliv se sčítá. U e-shopu, magazínu nebo firemního webu s hero bannerem, galerií a několika produktovými náhledy to může znamenat rozdíl mezi rychlým webem a stránkou, která působí těžkopádně.
Google navíc v hodnocení kvality stránky sleduje metriky jako LCP a CLS. Velký obrázek nad přehybem často určuje právě LCP, tedy chvíli, kdy uživatel vidí hlavní obsah. Pokud se obraz načítá pomalu, zpozdí se i vnímání celého webu. Pokud se navíc po načtení posune rozložení kvůli chybějícím rozměrům, trpí CLS. Výsledek je stejný: horší UX, nižší konverze a slabší signál pro vyhledávače.
Začněte auditem: které obrázky jsou skutečný problém
Prvním krokem není komprese všeho, co na webu najdete. Nejprve je potřeba zjistit, které soubory skutečně škodí. Prakticky se vyplatí projít web ve PageSpeed Insights, Lighthouse, WebPageTest a v prohlížeči přes síťovou kartu v DevTools. Hledejte hlavně:
- obrázky nad 100–200 kB na běžných stránkách,
- hero bannery větší než je skutečně potřeba pro zobrazení,
- duplicity ve více formátech a velikostech bez logiky,
- obrázky bez atributů width a height,
- obrázky načítané hned na všech stránkách, i když jsou až dole pod obsahem.
Typický příklad z praxe: homepage firemního webu má hlavní banner o velikosti 4,8 MB v PNG, přestože se zobrazuje jako plošný vizuál bez průhlednosti. Po převodu do WebP a správném ořezu na skutečnou šířku klesne soubor třeba na 180 kB. V reálném provozu to může ušetřit několik sekund na pomalejším mobilním připojení.
Formát rozhoduje: JPEG, PNG, WebP nebo AVIF
Největší chyba bývá používat jeden formát na všechno. Každý typ obrázku má jiné použití. JPEG je vhodný pro fotografie, PNG pro prvky s průhledností a ostrou grafikou, ale dnes už je často lepší volbou WebP nebo AVIF. Ty umí výrazně menší soubory při stejné vizuální kvalitě.
Obecně platí:
- AVIF nabízí nejvyšší kompresi, ale ne všude je ideální kvůli náročnějšímu zpracování.
- WebP je dnes velmi bezpečná volba pro většinu webů.
- JPEG stále dává smysl jako kompatibilní záloha nebo pro jednodušší workflow.
- SVG je nejlepší pro ikony, loga a jednoduchou vektorovou grafiku.
Praktický postup je jednoduchý: pokud web běží na WordPressu, zapněte optimalizaci přes plugin nebo serverovou vrstvu, která umí generovat WebP. U vlastního vývoje je vhodné připravit více variant přes <picture> a nechat prohlížeč vybrat ideální formát podle podpory a velikosti viewportu.
Pro produktové fotky nebo článkové náhledy se vyplatí nastavit cílovou velikost podle reálného prostoru v layoutu. Není důvod servírovat obrázek široký 2400 px, když se na mobilu zobrazuje v šířce 390 px a na desktopu v 800 px.
Správná velikost a responzivní načítání jsou stejně důležité jako komprese
Mnoho webů má obrázky sice „optimalizované“, ale stále posílá zbytečně velké soubory. To je problém zejména u responzivních webů, kde jedna verzí obrázku obsluhuje všechna zařízení. Moderní řešení pracuje s více variantami přes srcset a sizes. Prohlížeč si pak stáhne jen tak velký obrázek, jaký skutečně potřebuje.
Užitečný příklad:
- mobil: 480 px široký náhled,
- tablet: 768 px,
- desktop: 1200 px,
- retina zařízení: 2× varianta jen tam, kde to dává smysl.
Bez těchto variant může mobilní návštěvník stahovat desktopový soubor, který je několikanásobně větší, než je nutné. To je zbytečná zátěž pro výkon i data uživatele. Z hlediska UX je to navíc citlivé u návštěv z mobilní sítě, kde se rozdíl projeví okamžitě.
Stejně důležité je doplnit u všech obrázků pevné rozměry. Pokud prohlížeč předem ví, kolik místa prvek zabere, stránka se nebude při načítání posouvat. Tím se výrazně zlepší CLS, což je jedna z metrik Core Web Vitals.
Lazy loading pomáhá, ale jen když se používá správně
Lazy loading je jeden z nejčastějších nástrojů pro zrychlení stránek s větším množstvím obrázků. Jeho princip je jednoduchý: obrázky pod přehybem se nenačítají hned, ale až ve chvíli, kdy se uživatel blíží k jejich zobrazení. To snižuje počet požadavků na začátku a urychluje vykreslení nadřazeného obsahu.
Chyba nastává ve chvíli, kdy se lazy loading použije i na hlavní obrázek nahoře na stránce. Hero banner, logo nebo první produktová fotka obvykle musí být načteny okamžitě. Pokud se odloží, zhorší se LCP. Proto platí jednoduché pravidlo: nad přehybem načítat prioritně, pod přehybem odložit.
V praxi je vhodné kombinovat lazy loading s prioritizací. U moderních prohlížečů lze hlavní obrázek označit jako prioritní, případně použít preload. Naopak galerie, reference, blogové náhledy nebo dlouhé produktové seznamy mohou být lazy-loaded bez výrazné ztráty uživatelského zážitku.
U WordPressu je dobré zkontrolovat, zda plugin nebo šablona nepoužívá lazy loading příliš agresivně. Někdy je potřeba ručně vyloučit první obrázek v obsahu, aby se nezhoršila rychlost načtení stránky.
Hosting, CDN a cache rozhodují o tom, odkud se obrázky načítají
I perfektně zmenšený obrázek bude pomalý, pokud se načítá z pomalého serveru bez cache. Obrázky patří mezi statický obsah, a právě proto dává smysl využít CDN a správně nastavené cache hlavičky. U návštěvníků z různých zemí nebo u rozsáhlejších e-shopů je rozdíl často zásadní.
Co má v praxi smysl zkontrolovat:
- zda server posílá obrázky s dlouhou expirací cache,
- zda se používá CDN s geograficky blízkým doručením,
- zda je aktivní komprese na úrovni serveru,
- zda se obrázky neservírují přes pomalý plugin nebo externí skript,
- zda hosting zvládá špičky bez zpomalení odpovědí.
U e-shopu s desítkami kategorií a stovkami produktů se vyplatí i image CDN, která umí obrázky měnit za běhu podle zařízení, formátu a kvality. To odlehčí serveru a zjednoduší správu. V případě WordPressu lze tímto způsobem výrazně zlepšit rychlost bez zásadního zásahu do obsahu.
Pro dlouhodobý provoz se vyplatí sledovat také reálná data v Google Search Console a GA4. Pokud stránky s těžkými obrázky mají vyšší míru opuštění nebo slabší konverze na mobilu, problém není jen technický, ale i obchodní.
Jak nastavit pravidla, aby se problém nevracel
Jednorázová optimalizace nestačí, pokud redakce nebo tým vývojářů dál nahrává velké soubory bez kontroly. Proto je vhodné nastavit jednoduchá interní pravidla. Každý obrázek před zveřejněním by měl projít kontrolou rozměru, formátu a účelu. U redakčních webů pomůže i krátký manuál pro editory.
Funkční minimum vypadá takto:
- nahrávat obrázky v rozměru odpovídajícím reálnému použití,
- používat WebP nebo AVIF tam, kde to dává smysl,
- u všech obrázků doplnit rozměry,
- lazy loading používat jen pod přehybem,
- pravidelně kontrolovat největší soubory na stránce,
- měřit dopad na LCP, CLS a celkovou rychlost načtení.
Dobře nastavený proces přináší rychlý efekt. Web se načítá svižněji, návštěvníci déle zůstávají na stránce a vyhledávače lépe vyhodnocují kvalitu zobrazení. Obrázky pak nejsou slabým místem webu, ale součástí jeho výkonu.