Obrázky a rychlost webu: kde se dá ušetřit nejvíc

Nejvíc ušetříte na rozlišení, ne na kompresi. Fotka zmenšená ze 4032 na 1600 pixelů zhubne o osmdesát procent dřív, než vůbec sáhnete na kvalitu JPEG. Obrázky přitom tvoří na typickém webu třetinu až polovinu všech přenesených dat: podle Web Almanacu za rok 2025 připadá na mediánové mobilní stránce zhruba 911 KB na obrázky z celkových 2,5 MB. Když k menšímu rozlišení přidáte moderní formát a srcset, spadne tahle položka běžně o 60 až 80 procent.

Kolik z váhy stránky mají obrázky na svědomí?

Medián je milosrdné číslo. Na českých firemních webech, které někdo poskládal ve WordPressu a nikdy se nepodíval do složky uploads, vídám 4 až 8 MB obrázků na jedné podstránce. Loni jsem měřil úvodní stránku penzionu: čtrnáct fotek nahraných rovnou z telefonu majitele, dohromady 62 MB. Na mobilním připojení se načítala přes minutu.

Důvod je prozaický. Fotka z dnešního mobilu má 4032 × 3024 pixelů a váží 2 až 5 MB, u telefonů s 48megapixelovým snímačem a zapnutou nejvyšší kvalitou klidně 10 MB. Snímek ze zrcadlovky uložený jako JPEG na plnou kvalitu se dostane přes 15 MB. Na web přitom potřebujete zlomek.

Cílové hodnoty, se kterými pracuju:

• Náhled v kategorii nebo výpisu článků (400 px široký): 15 až 35 KB
• Fotka produktu na detailu (1200 px): 60 až 120 KB
• Velký úvodní obrázek přes celou šířku (1920 px): 120 až 250 KB
• Logo, ikona, piktogram: pod 10 KB, ideálně SVG

Přes 300 KB u jednoho obrázku je skoro vždycky známka zbytečně velkého rozlišení, ne špatné komprese. A pokud nad jednou fotkou hloubáte půl hodiny, ale na stránce vám sedí pět měřicích skriptů, řešte nejdřív zpomalení způsobené skripty třetích stran.

Který formát vybrat: JPEG, PNG, WebP, nebo AVIF?

Na fotografie AVIF, s WebP jako druhou volbou a JPEG jako záchranou. Na loga a ikony SVG. PNG jen tam, kde potřebujete průhlednost a ostré hrany a WebP z nějakého důvodu nejde použít.

Formát	Na co	Fotka 1600 × 900	Úspora proti JPEG
JPEG (kvalita 80)	fotografie, záložní varianta	kolem 220 KB	výchozí stav
PNG	průhlednost, ostré hrany, snímky obrazovky	u fotky 600 KB a víc	horší než JPEG
WebP (kvalita 78)	fotografie i grafika, umí průhlednost	kolem 150 KB	25 až 35 %
AVIF (kvalita 50)	fotografie, hlavně velké plochy	kolem 105 KB	40 až 55 %

Berte to jako řádové poměry, ne jako zákon. U fotky s velkou plochou oblohy nebo rozostřeným pozadím sráží AVIF velikost i o 60 procent, u detailní textury látky nebo šperku bývá rozdíl proti WebP sotva deset procent. A u malých náhledů pod 20 KB se úspora ztrácí úplně, protože režie hlavičky souboru je u AVIF vyšší.

AVIF podporují všechny hlavní prohlížeče, Safari od verze 16.4 z března 2023. Podle caniuse je globální pokrytí kolem 94 procent a na českém provozu to bývá o kousek lepší, protože podíl starých iPhonů je nižší než světový průměr. Přesné číslo pro váš web ale nikdo neuhodne, koukněte se do Analytics. Zbytek návštěvníků obslouží záložní JPEG přes značku picture, což za vás udělá plugin nebo CDN. Ručně to psát nemusíte.

Největší úspora je v rozlišení, ne v kompresi

Fotka široká 4032 pixelů zobrazená v článku na 760 pixelech nese pětkrát víc pixelů na šířku, tedy zhruba pětadvacetkrát víc obrazových dat, než kolik se skutečně vykreslí. Ten rozdíl nedožene žádná komprese. Tady chybuje nejvíc lidí.

Řešení má dvě části. První je zmenšit originál na maximum, které web reálně použije: u běžného webu stačí 2000 pixelů na šířku, u e-shopu s lupou na produktu 2400. Druhá je srcset, kdy v kódu nabídnete prohlížeči několik velikostí a on si sám vybere podle šířky displeje a hustoty pixelů. Atribut sizes mu k tomu řekne, jak široký ten obrázek v rozvržení bude.

WordPress generuje srcset sám z registrovaných velikostí, jenže hodnota sizes bývá špatně, protože šablona ji nenastaví podle skutečného rozvržení. Od verze 6.7 doplňuje WordPress u odložených obrázků sizes="auto", takže si šířku dopočítá prohlížeč z hotového rozvržení. Funguje to dobře. Jen pozor: u pár šablon s pevnou nebo fit-content šířkou obrázku se po přechodu na 6.7 objevily rozmazané fotky. Když to na svém webu vidíte, hledejte chybu v CSS u obrázků, ne ve WordPressu.

Kdy odložené načítání škodí?

Odložené načítání (loading="lazy") ušetří data u obrázků pod ohybem stránky, ale na první obrázek viditelný hned po otevření nepatří nikdy. Prohlížeč ho totiž začne stahovat až poté, co dopočítá rozvržení, a zrovna tenhle obrázek bývá tím prvkem, podle kterého Google měří LCP.

Rozdíl není kosmetický. Podle měření na velkém vzorku stránek má dobré LCP asi 79 procent webů, které hlavní obrázek neodkládají, proti zhruba 52 procentům těch, které ho odkládají. Konkrétní procenta se rok od roku posouvají, poměr zůstává. Jak to souvisí s dalšími metrikami, rozebírám v článku o tom, co Core Web Vitals opravdu měří.

WordPress od verze 6.3 první obrázky sám přeskakuje a pravděpodobnému LCP obrázku přidává fetchpriority="high". Když přesto v PageSpeed Insights vidíte hlášku o odloženém LCP obrázku, skoro jistě za to může optimalizační plugin, který si lazy loading řeší po svém a chování jádra přebíjí. Vypněte v něm odložené načítání obrázků a změřte znovu.

Width a height do kódu patří vždycky

Bez rozměrů v HTML prohlížeč neví, kolik místa má obrázku nechat. Vykreslí text, pak dorazí fotka a všechno pod ní odskočí dolů. Uživatel právě mířil na odkaz a klikl vedle. Google tenhle jev měří jako CLS a hranice pro dobré hodnocení je 0,1.

Stačí do značky img doplnit width a height v pixelech podle skutečného poměru stran a v CSS nechat width: 100%; height: auto;. Prohlížeč si z atributů odvodí poměr stran a místo si rezervuje dopředu. Typický průšvih z praxe: minifikační plugin atributy odstraní jako „zbytečné“, CLS vyskočí na 0,25 a nikdo nechápe proč.

Jaká kvalita komprese stačí?

Nižší, než si většina lidí myslí. Mezi kvalitou 95 a 80 nikdo na fotografii na webu rozdíl nepozná, přitom soubor je poloviční. Hodnoty, které nasazuju:

• JPEG: 75 až 82. Pod 70 začínají být vidět čtverce v plochách jedné barvy.
• WebP: 70 až 80. WordPress používá ve výchozím stavu 82.
• AVIF: 45 až 60. Stupnice není stejná jako u JPEG, padesátka u AVIF odpovídá zhruba osmdesátce u JPEG.
• Obrázky pro displeje s dvojnásobnou hustotou: klidně o deset bodů níž, stejně se zmenšují.

Výš jděte jen tam, kde je v obrázku text nebo tenká linka: snímky obrazovky, technické výkresy, tabulky. Pro ty sáhněte radši po PNG nebo WebP v bezeztrátovém režimu.

A ještě jedna položka, na kterou se zapomíná: metadata. Fotka z mobilu si nese EXIF, GPS souřadnice a barevný profil, dohromady 20 až 80 KB. Odstranění je jedno zaškrtávátko v každém rozumném nástroji a u tisíce fotek to dělá desítky megabajtů. Bonusem je, že z fotek přestanete vysílat, kde bydlíte.

Čím to udělat ve WordPressu, na Shoptetu nebo přes CDN?

WordPress umí WebP od verze 5.8 a AVIF od 6.5, ale jen když to zvládne knihovna na serveru (Imagick s podporou libheif nebo dostatečně nová GD). Na levnějších sdílených hostinzích tahle podmínka často neplatí, takže si to nejdřív ověřte ve Zdraví webu. Nahrát AVIF ručně jde vždycky, automatický převod nahraných JPEG obvykle ne. Na ten potřebujete plugin nebo CDN.

Z pluginů se v praxi osvědčily ShortPixel, Imagify, EWWW Image Optimizer a Converter for Media. Liší se hlavně tím, jestli počítají kredity za obrázek, nebo běží lokálně na vašem serveru. Ceníky se mění každou chvíli, konkrétní částky si ověřte přímo u dodavatele. U lokálního zpracování počítejte s tím, že tisíc fotek na sdíleném hostingu u Wedosu nebo Forpsi zabere klidně hodinu a server u toho jede naplno.

CDN řeší totéž jinak. Obrázek si při prvním požadavku převede na formát, který prohlížeč umí, a dál ho servíruje z mezipaměti. Cloudflare to má v placených tarifech, Bunny nabízí Optimizer jako doplňkovou službu. Výhodou je, že originály na serveru zůstanou nedotčené a kdykoli se dá vrátit zpátky.

Na Shoptetu se o převod do WebP starat nemusíte, od roku 2024 probíhá automaticky při doručení obrázku do prohlížeče. Prostor je jinde: v tom, co nahrajete. Když do administrace nasypete fotky široké 6000 pixelů, Shoptet z nich udělá WebP, ale pořád zbytečně velký. Upgates se chová podobně.

Jak na e-shop s tisíci fotkami, aby se to nezvrtlo?

Hromadné zásahy do médií se nedají vzít zpátky, takže na pořadí kroků záleží:

1. Změřte výchozí stav. Vezměte tři typické stránky (domovskou, kategorii, detail produktu) a zapište si celkovou váhu a LCP. Bez čísla před zásahem nezjistíte, jestli něco pomohlo. Rychlý přehled dá i bezplatná SEO kontrola webu.
2. Udělejte zálohu složky s médii. Celou, ne jen databázi.
3. Najděte dvacet nejtěžších souborů. Většinou zjistíte, že problém dělá pár desítek fotek, ne všech pět tisíc.
4. Určete maximální rozlišení pro každý typ. Náhled 400 px, detail 1200 px, lupa 2400 px. Zapište to do zadání, ať to platí i pro fotky nahrané příští rok.
5. Pusťte převod po dávkách. Pět set obrázků, kontrola vzorku očima, další dávka. Když se pokazí kvalita, přijdete na to u páté stovky, ne u páté tisícovky.
6. Zapněte AVIF nebo WebP se záložní variantou a ověřte v prohlížeči, že se opravdu servíruje nový formát.
7. Projděte odložené načítání a rozměry. První obrázek na stránce bez lazy, všechny obrázky s width a height.
8. Zkontrolujte export do Zboží.cz a Heureky. Některé porovnávače si s WebP ve feedu neporadí, do XML tedy patří adresa původního JPEG.
9. Změřte znovu za týden a porovnejte s bodem jedna.

Ještě jedna věc k převodu na jiný formát: pokud se mění adresy souborů, musí staré adresy vést správně nastaveným přesměrováním 301, jinak přijdete o pozice ve vyhledávání obrázků. A když už se v médiích hrabete, projděte rovnou i alt popisky obrázků. Rychlost neovlivní, návštěvnost ano.

Časté dotazy

Vyplatí se přecházet na AVIF, když už mám WebP?

U velkých fotografií ano, úspora bývá 20 až 30 procent proti WebP. U malých náhledů pod 20 kilobajtů se nevyplatí, tam jde o jednotky kilobajtů a někdy je AVIF dokonce větší. Rozumný kompromis je nasadit AVIF na velké obrázky a u náhledů zůstat na WebP.

Kolik má vážit fotka na webu?

Náhled v kategorii 15 až 35 kilobajtů, fotka produktu na detailu 60 až 120 kilobajtů, velký obrázek přes celou šířku obrazovky 120 až 250 kilobajtů. Fotka přímo z mobilu má 2 až 5 megabajtů, takže ji před nahráním vždycky zmenšete. Když jednotlivý obrázek přesáhne 300 kilobajtů, bývá příčinou zbytečně velké rozlišení.

Uškodí převod obrázků na WebP pozicím ve vyhledávání?

Ne, pokud se nezmění adresa souboru nebo pokud stará adresa vede přesměrováním 301 na novou. Google i Seznam WebP indexují běžně. Problém nastane jen tehdy, když se obrázky přejmenují bez přesměrování. Pak se odkazy z vyhledávání obrázků lámou a pozice se budují znovu.