Obrázky jsou na běžném webu největší nálož dat. HTTP Archive to měří na milionech stránek: běžná stránka na mobilu dnes váží kolem 2,3 MB (medián) a asi 900 kB z toho jsou obrázky — víc než skripty, styly, fonty a samotné HTML dohromady. Proto se rychlost webu nejčastěji vyhrává právě tady. Na otázku „AVIF vs WebP" mám krátkou odpověď hned: WebP je dnes bezpečná volba pro celý web, AVIF ušetří něco navíc hlavně u fotek. Jenže formát je až druhá otázka. Nejvíc rychlosti se u obrázků neztrácí špatným formátem, ale lazy loadingem na špatném místě.
Co umí WebP a AVIF, co JPEG neumí
JPEG a PNG fungují přes třicet let a nikdo vás za ně nepenalizuje. Jen platíte daty: novější formáty zabalí stejný obraz do citelně menšího souboru.
WebP vyvinul Google a podle jeho vlastní srovnávací studie je při stejné vizuální kvalitě o 25–34 % menší než JPEG. Umí průhlednost jako PNG i animace jako GIF, takže jedním formátem nahradíte tři. Podpora: podle caniuse.com ho zobrazí zhruba 96 % prohlížečů v provozu; vypadávají jen opravdu letité systémy.
AVIF je mladší formát postavený na videokodeku AV1. Komprimuje ještě úsporněji — u fotek bývá soubor menší až o polovinu proti JPEG a znatelně menší i proti WebP; u grafiky s textem a ostrými hranami se náskok proti WebP ztrácí. Daň za to je pomalejší enkódování: převod trvá násobně déle, což pocítí hlavně systémy, které obrázky konvertují průběžně. Podpora je dnes kolem 93 %: Safari umí AVIF naplno od verze 16.4 (rok 2023), iPhony od iOS 16 — a Edge ho překvapivě přidal až ve verzi 121, tedy v lednu 2024.
AVIF vs WebP: verdikt pro běžný web
Prakticky z toho plyne:
- WebP nasaďte všude. Je to dnešní bezpečný standard: umí ho každý nástroj, generuje ho většina systémů a nic tím nerozbijete.
- AVIF berte jako bonus. Dává smysl tam, kde ho něco vyrábí automaticky — obrázkové CDN, plugin, framework. Ručně přeukládat hotovou galerii z WebP do AVIF se nevyplatí: úspora bývá v jednotkách až nižších desítkách procent a hodiny práce vám nikdo nevrátí.
- AVIF nikdy bez zálohy. Těch chybějících 7 % prohlížečů jsou reální lidé, často na starších iPhonech. Samotné WebP se dnes běžně nasazuje i bez fallbacku; u AVIF záloha pořád patří k řemeslu.
Zálohu řeší prvek <picture>: prohlížeč si vezme první formát, kterému rozumí.
<picture>
<source srcset="produkt.avif" type="image/avif">
<img src="produkt.webp" alt="Popis produktu" width="800" height="600">
</picture>
Druhá cesta je nechat rozhodování na serveru: prohlížeč při každém požadavku hlásí, které formáty umí, a server nebo CDN mu pošle tu nejlepší variantu. Adresa pak klidně končí .jpg, a přitom chodí WebP — a <picture> v šabloně vůbec nepotřebujete. Touhle cestou jde i Shoptet, jak hned uvidíte.
Čtete už třetí návod a pořád nevíte, čím začít? Začněte auditem. Projdu váš web ručně a do 48 hodin dostanete konkrétní priority — žádnou třicetistránkovou zprávu, kterou nikdo nečte. Zdarma.
Konverzi možná už máte zapnutou
Než začnete cokoliv kupovat, ověřte si, co už váš systém dělá sám.
Shoptet převádí obrázky na WebP automaticky. Vyzkoušela jsem to na produktové fotce z jednoho e-shopu na Shoptetu: stejnou adresu končící .jpg jsem stáhla jednou jako starý prohlížeč a podruhé jako moderní. Starý dostal JPEG, moderní WebP — ze stejné adresy, bez jakéhokoliv nastavování. AVIF zatím Shoptet neposílá; o moc ale nepřicházíte.
WordPress umí WebP nahrávat od verze 5.8 (2021) a AVIF od verze 6.5 (2024). Jestli ale obrázky při nahrání skutečně konvertuje a komprimuje, záleží na hostingu a šabloně — v praxi to za vás nejspolehlivěji vyřeší plugin. ShortPixel konvertuje do WebP i AVIF automaticky při nahrání a umí dávkově zpracovat i existující knihovnu médií.
Ruční práce má smysl u jednotlivých důležitých obrázků, typicky hlavní fotky na úvodní stránce. Squoosh (squoosh.app, zdarma, běží v prohlížeči) ukáže originál a komprimovanou verzi vedle sebe, takže kvalitu posoudíte vlastníma očima, a exportuje WebP i AVIF. Dodavatel, který potřebuje převést stovky souborů najednou, na to má nástroje jako sharp nebo ImageMagick.
Ke kompresi jedno vodítko: při kvalitě kolem 80–85 na monitoru rozdíl proti originálu nenajdete. Výš jděte jen tam, kde si lidé fotku přibližují — typicky u produktů, kde rozhoduje struktura látky nebo dřeva.
Lazy loading: jeden atribut a jedna drahá past
Lazy loading znamená, že se obrázek stáhne, až když k němu návštěvník doroluje. Dnes na to stačí atribut přímo v HTML, žádný skript:
<img src="foto.webp" loading="lazy" width="800" height="600" alt="…">
Rozumí mu všechny běžné prohlížeče a vzdálenost, v jaké se obrázek začne přednačítat, si řídí samy — Chrome například na rychlém připojení začíná stahovat zhruba 1 250 pixelů před okrajem obrazovky. Nemusíte nic ladit; obrázek je obvykle stažený dřív, než k němu člověk doroluje.
Past je v tom, kam atribut dát. Google v dokumentaci na web.dev píše výslovně: obrázky viditelné na první obrazovce lazy loading mít nesmí. Nejhorší kombinace je loading="lazy" na hlavní fotce nahoře — tedy na prvku, který nejspíš rozhoduje o metrice LCP. Prohlížeč načtení odloží, hlavní obrázek naskočí pozdě a technika, která měla web zrychlit, ho zpomalí. Potkávám to i u webů, za které si firmy zaplatily nemalé peníze: šablony totiž rády nasadí lazy loading plošně na všechno.
Správně je to obráceně: hlavnímu obrázku dejte přednost.
<img src="hero.webp" fetchpriority="high" width="1600" height="900" alt="…">
Atribut fetchpriority="high" říká prohlížeči, ať obrázek stáhne přednostně, a web.dev ho pro LCP obrázek přímo doporučuje. Hranice dobrého LCP je 2,5 sekundy — je to jedna ze tří metrik Core Web Vitals, a pokud ji váš web neplní, začněte u postupu na opravu LCP.
Rozměry: ať stránka neskáče a mobil nestahuje zbytečná data
Dvě věci k rozměrům, obě levné:
Width a height do každého obrázku. Prohlížeč si díky nim rezervuje místo dřív, než se obrázek stáhne, a stránka při načítání neposkakuje. Poskakování má vlastní metriku (CLS) i vlastní návod na opravu.
Víc velikostí přes srcset. Atribut srcset nabídne stejný obrázek v několika šířkách a prohlížeč si vybere podle displeje — mobil pak nestahuje fotku určenou pro velký monitor. Nemusíte ho psát ručně: WordPress, Shoptet i moderní frameworky ho generují samy. Jen nenahrávejte fotky rovnou z telefonu v plném rozlišení — zmenšete je ještě před nahráním, ze šestitisícové šířky srcset nikoho nezachrání.
A jedna věta k CDN: služba, která obrázky doručuje ze serveru blízko návštěvníkovi a cestou je zkonvertuje i zmenší, se vyplácí až u webů s tisíci fotek nebo se zahraničním publikem; běžnému firemnímu webu udělá víc radosti všechno výše.
Co chtít po dodavateli: kontrola v šesti bodech
Tohle je seznam, který můžete poslat dodavateli doslova — a podle odpovědí poznáte, jak na tom jste:
- Servírují se obrázky ve WebP (ať už souborem, nebo automaticky přes server/CDN)?
- Má hlavní obrázek stránky
fetchpriority="high"— a určitě nemáloading="lazy"? - Mají všechny ostatní obrázky
loading="lazy"? - Má každý obrázek v kódu
widthaheight? - Generuje se
srcset, aby mobil dostával menší verze? - Jsou soubory komprimované (kvalita ~80) a zmenšené na rozměry, ve kterých se skutečně zobrazují?
Ověření je pak na dvě minuty v PageSpeed Insights: sekce s doporučeními vám vypíše konkrétní obrázky, které stránku zdržují, včetně odhadu, kolik dat by šlo ušetřit.
Ještě dovětek, ať nic nepřeženete: tenhle článek řeší výkon. Aby obrázky pomáhaly i ve vyhledávání, potřebují popisné názvy souborů a alt texty — to je samostatné řemeslo a pokrývá ho průvodce optimalizací obrázků pro SEO.
Časté otázky
Jak poznám, jestli můj web už WebP nebo AVIF používá?
Nejrychleji v prohlížeči: pravé tlačítko, Prozkoumat, záložka Síť (Network), filtr na obrázky — sloupec Typ ukáže skutečný formát každé odpovědi. Přípona v adrese totiž nic nedokazuje: adresa může končit .jpg, a server přitom posílá WebP.
Musím kvůli novému formátu znovu nahrát všechny obrázky?
Nemusíte, konverze se dělá ze souborů, které na webu už máte — pluginy i CDN zpracují existující knihovnu dávkově. Jen počítejte s tím, že převod z už jednou komprimovaného JPEG kvalitu nevylepší; pokud máte k dispozici kvalitnější originály, konvertujte z nich.
Nevadí Googlu, že adresa končí .jpg, ale přichází WebP?
Nevadí. Vyjednávání formátu mezi prohlížečem a serverem je standardní webová technika, kterou používají velká CDN i Shoptet; Google se řídí tím, co server skutečně pošle. Do vyhledávání obrázků se WebP i AVIF indexují normálně.
Stránka obecných rad je fajn. Konkrétní seznam pro váš web je lepší. Audit máte zdarma.
Nejlevnější zrychlení, jaké web má
Ze všech technických oprav mívají obrázky nejlepší poměr účinku k ceně: žádná přestavba webu, jen formáty, atributy a rozměry. PageSpeed Insights vám ukáže skóre — co ale změnit a v jakém pořadí, z něj majitel webu většinou nevyčte. V auditu proto vytahuju konkrétní soubory, na kterých stránka čeká, a k nim úpravy, které stačí předat dodavateli. Za audit se u mě neplatí a u menších webů bývají právě obrázky oprava, po které je zrychlení vidět nejdřív.
Zdroje k faktům v článku:
- Web Almanac 2024 (HTTP Archive): medián mobilní stránky 2 311 kB, z toho 900 kB obrázky (ověřeno 26. 7. 2026): almanac.httparchive.org/en/2024/page-weight
- Podpora prohlížečů: WebP ~96 %, AVIF ~93 %, Safari 16.4, iOS 16, Edge 121 (data caniuse, ověřeno 26. 7. 2026): caniuse.com/avif
- Srovnávací studie WebP vs JPEG, úspora 25–34 % (ověřeno 26. 7. 2026): developers.google.com/speed/webp/docs/webp_study
- Lazy loading: nikdy na obrázky v prvním viewportu; prahy přednačítání (ověřeno 26. 7. 2026): web.dev/articles/browser-level-image-lazy-loading; fetchpriority="high" pro LCP obrázek: web.dev/articles/fetch-priority
- WordPress: WebP od 5.8, AVIF od 6.5 (ověřeno 26. 7. 2026): make.wordpress.org — WordPress 6.5 adds AVIF support
- Shoptet a WebP: vlastní test 26. 7. 2026 — stejná adresa
.jpgna cdn.myshoptet.com vrací JPEG, nebo WebP podle hlavičky Accept prohlížeče; AVIF nevrací
