Optimalizace obrázků v roce 2026: AVIF, WebP a Lazy Loading

Obrázky zůstávají nejtěžšími prvky na většině webových stránek. V našich projektech v DigiForge běžně vidíme, že obrázky tvoří podstatnou část celkové hmotnosti stránky. V roce 2026 je situace jasná: AVIF a WebP jsou dva moderní formáty, po kterých sáhnout, responzivní obrázky pomocí srcset jsou základ a lazy loading je tak standardní, že jeho špatné provedení může výkonu spíše uškodit. Tento článek shrnuje naše praktické zkušenosti do přehledného a autoritativního pracovního postupu, který můžete použít v jakémkoli projektu.

Výběr správného formátu: AVIF vs WebP

Po léta byl WebP hlavním formátem nové generace. AVIF přišel později a sliboval lepší kompresi a podporu HDR, ale za cenu vyšších nároků na kódování a podpory prohlížečů, která stále není univerzální (Safari byl poslední, kdo přidržoval). Zde je stav v roce 2026:

• AVIF obvykle poskytuje menší velikosti souborů než WebP při stejné vnímané kvalitě. Podporuje 10bitové barvy, HDR, bezeztrátovou alfu a dokonce i animace. Kódování je výrazně pomalejší než u WebP, takže je méně vhodné pro generování v reálném čase, ale pro statické assety připravené při sestavení je v pořádku.
• WebP je univerzálně podporován ve všech moderních prohlížečích. Nabízí předvídatelnou kvalitu, rychlé kódování a vynikající nástroje (cwebp, sharp, imagemin). Pro weby náročné na obsah, kde záleží na rychlosti kódování, je WebP stále pragmatickou volbou.
• JPEG XL (JXL) zpočátku sliboval, ale nikdy nezískal podporu prohlížečů. Chromium odstranilo jeho příznak a Safari jej nikdy neimplementovalo. Neztrácejte s ním čas, dokud se situace nezmění.

Naše doporučení: Poskytujte AVIF s WebP fallbackem. Použijte <picture>, aby si prohlížeče vybraly nejprve AVIF, poté WebP a nakonec původní JPEG/PNG. Tím maximalizujete kompresi pro ty, kteří ji mohou využít, aniž byste někoho nechali bez obrázku. Většina moderních prohlížečů podporuje AVIF, takže fallback je důležitý, ale není primární cestou.

<picture>
  <source srcset="image.avif" type="image/avif">
  <source srcset="image.webp" type="image/webp">
  <img src="image.jpg" alt="...">
</picture>

Responzivní velikosti: Nejen srcset

Atribut srcset s sizes je dobře známý, ale mnoho implementací, které auditujeme, má sizes špatně. Prohlížeč používá sizes k určení, kterého kandidáta z srcset stáhne – není to jen návrh. Chybějící sizes má výchozí hodnotu 100vw, což znamená, že prohlížeč může vybrat největší obrázek i na malé obrazovce, čímž plýtvá šířkou pásma.

Pro jednoduché responzivní obrázky, kde se obrázek škáluje s viewportem, napište:

<img src="image-800.jpg" 
     srcset="image-400.jpg 400w, image-800.jpg 800w, image-1200.jpg 1200w"
     sizes="(max-width: 600px) 100vw, (max-width: 1200px) 50vw, 33vw"
     alt="...">

Je tu však nuance. sizes by mělo odrážet skutečnou šířku CSS, kterou obrázek zabírá v daném zlomu, nikoli zlomek viewportu. Pro hero obrázek, který je vždy na celou šířku, je sizes="100vw" správně. Pro galerii, kde každý obrázek zabírá jednu třetinu řádku, použijte 33vw. Pokud má obrázek padding nebo je uvnitř kontejneru s max-width, musíte vypočítat skutečnou vykreslenou šířku – někdy je nutné použít calc() v sizes.

Width Descriptors vs. Hustota pixelů

Používejte w deskriptory (např. 400w) a sizes pro flexibilní obrázky, jejichž zobrazená velikost se mění s rozložením. Deskriptory hustoty (1x, 2x) jsou vhodné pouze pro obrázky s pevnou velikostí, jako jsou loga nebo ikony, kde znáte přesné fyzické rozměry. U obsahových obrázků vždy používejte w – poskytuje prohlížeči skutečnou flexibilitu vybrat nejlepšího kandidáta na základě šířky viewportu a poměru pixelů zařízení.

Při použití <picture> pro výběr formátu musí mít každý <source> vlastní srcset a volitelně sizes. Pokud je rozložení stejné, můžete sdílet stejné sizes napříč zdroji, ale vyhněte se zbytečnému duplikování.

Lazy Loading: nativní, Intersection Observer nebo obojí?

Nativní lazy loading (loading="lazy") je od roku 2020 podporován ve všech hlavních prohlížečích. Nevyžaduje žádný JavaScript, funguje s obrázky i iframe a je tou nejjednodušší cestou. Má však v praxi důležité zvláštnosti:

• Nativní lazy loading odkládá načítání, dokud prohlížeč nevyhodnotí, že je prvek blízko viewportu. Práh je definován prohlížečem – Chrome používá velkorysý okraj pro brzké načítání, Firefox menší. To znamená, že obrázky se ve Firefoxu mohou načítat později, než byste čekali.
• V některých starších implementacích nefunguje dokonale s srcset. Starší verze Safari (před 16.4) měly chyby. V roce 2026 jsou tyto případy vzácné, ale stále stojí za testování.
• U elementů <picture> by loading="lazy" mělo být na tagu <img>, nikoli na <source>.

Používáme hybridní přístup: nativní lazy loading jako základ a odlehčený polyfill pomocí Intersection Observer (IO) pro starší prohlížeče (i když v roce 2026 jde o okrajový případ). IO může také spouštět animace postupného zobrazení nebo načítat náhledy s nízkou kvalitou. Naše implementace:

const lazyImages = document.querySelectorAll('img[loading="lazy"]');

if ('loading' in HTMLImageElement.prototype) {
  // Native lazy loading works – do nothing extra
} else {
  const observer = new IntersectionObserver((entries) => {
    entries.forEach(entry => {
      if (entry.isIntersecting) {
        const img = entry.target;
        img.src = img.dataset.src;
        observer.unobserve(img);
      }
    });
  });
  lazyImages.forEach(img => observer.observe(img));
}

Spojení všeho dohromady: Praktický pracovní postup

V DigiForge dodržujeme tento postup pro každý projekt, ať už jde o statický web, web řízený CMS nebo webovou aplikaci:

1. Zdrojové obrázky: Designéři dodávají ve vysokém rozlišení PNG nebo TIFF. Originály uchováváme ve složce _originals pro budoucí rekomprimaci, pokud se objeví nové formáty.
2. Generování formátů: Použijte Node.js skript s sharp nebo Makefile s ImageMagick k vytvoření AVIF, WebP a záložních JPEG/PNG v 3–5 šířkách (např. 480, 800, 1200, 1920). U velkých projektů to spouštíme paralelně pomocí worker threads pro urychlení sestavení.
3. Ladění kvality: Spouštějte CI kontroly, které porovnávají velikost souboru s percepční metrikou (SSIM nebo Butteraugli). Blokujeme pull requesty, pokud celková váha obrázků typické stránky překročí rozumný práh podle typu obsahu.
4. Značkování: Vygenerujte <picture> s řazením type (AVIF, WebP, záložní) a <img> s loading="lazy" (kromě prvního hero). Pro responzivní velikosti generujeme sizes podle skutečného CSS – to často pochází ze souboru design tokens sdíleného mezi designem a vývojem.
5. Serving z CDN: U statických webů servírujeme předem zakódovaná aktiva z CDN s dlouhými cache hlavičkami (např. Cache-Control: public, max-age=31536000, immutable). Pokud používáte image CDN jako Cloudinary nebo imgix, mnoho kroků je automatizováno pomocí URL transformací, ale kritické obrázky stále předkódujeme, abychom se vyhnuli nákladům na studený start.

Stránky jako Unsplash [3] a Pixabay [1] poskytují obrázky ve vysokém rozlišení, které často váží několik megabajtů v surové podobě. Náš postup je dramaticky zmenšuje bez znatelné ztráty kvality. Podobně obrázky generované AI z nástrojů jako ChatGPT Images [4] často vycházejí ve vysokém rozlišení bez optimalizace, takže je klíčové je prohnat stejným kompresním workflow. Stock obrázky z Shutterstock [5] nebo Bing Images [2] mají podobné vlastnosti – velké soubory, které mohou při neoptimalizování poškodit výkon.

Časté nástrahy, které vidíme (a opravujeme)

• Chybějící sizes úplně: Prohlížeč stáhne největšího kandidáta z srcset, protože předpokládá 100vw. Vždy uvádějte sizes – i jednoduché 100vw je lepší než nic.
• Používání JPEG na všechno: Mnoho týmů stále servíruje JPEG jako jediný formát. V roce 2026 už to není omluvitelné – WebP a AVIF jsou vyspělé a jejich přidání je minimální práce.
• Přílišné líné načítání: Každý obrázek s loading="lazy" zpožďuje první smysluplné vykreslení. Pro kritické obrázky používejte loading="eager" a zvažte přednačtení hero obrázku pomocí <link rel="preload" as="image" href="..."> pro maximální rychlost LCP.
• Žádná záložní varianta pro animované formáty: Pokud používáte animovaný AVIF (který má omezenou podporu), poskytněte záložní WebP nebo GIF přes <picture>.
• Kódování obrázků za běhu v serverless funkcích: Kódování AVIF je náročné na CPU. Při návalu požadavků může dojít k timeoutu nebo skokovému nárůstu nákladů. Vždy předgenerovávejte assety během sestavení, kromě obrázků nahraných uživateli, které nelze předpřipravit.

Také jsme viděli týmy, které spoléhají na jediný zdroj obrázku bez verzování. Když designér aktualizuje hero banner, starý soubor se přepíše a naruší se CDN cache. Používejte hash v názvech souborů (např. hero-a1b2c3.avif), aby nové verze dostaly novou URL a staré mohly být neomezeně cachovány.

Doporučení nástrojů

Pro vývojáře, kteří preferují CLI, jsou cwebp (z libwebp) a avifenc (z libavif) solidní a skriptovatelné. Pro Node.js pipeline je sharp nepřekonatelný – je rychlý, zvládá všechny formáty a umí výstup AVIF (vyžaduje libvips s podporou AVIF). Pro ad-hoc srovnání používáme Squoosh nebo nástroje jako icdif (Image Compare Diff).

U rozsáhlých projektů zvažte použití CDN pro obrázky, jako je Cloudinary, imgix nebo Image Optimizer od Fastly. Tyto služby automatizují změnu velikosti a vyjednávání formátu pomocí URL parametrů a často zvládají kódování AVIF na vlastní cache vrstvě, takže na původním serveru neplatíte za výpočetní výkon. Dejte si však pozor na vendor lock-in a náklady – u webu s mnoha obrázky může být měsíční účet značný. Často doporučujeme hybridní přístup: předgenerujte nejběžnější velikosti a formáty a nechte CDN zpracovávat vzácné breakpointy nebo uživatelské nahrávky.

Pokud používáte CMS nebo generátor statických stránek, existují pluginy pro většinu frameworků (např. @next/image pro Next.js, gatsby-plugin-sharp pro Gatsby, eleventy-img pro Eleventy). Tyto nástroje automaticky generují obrázky a značky, ale přesto doporučujeme zkontrolovat jejich výchozí nastavení kvality – bývají konzervativní (bezztrátové nebo téměř bezztrátové), aby se předešlo stížnostem, což může plýtvat bajty.

Závěr

Optimalizace obrázků v roce 2026 je o kompromisech: AVIF ušetří nejvíce bajtů, ale stojí CPU; WebP je spolehlivý střed. Responzivní velikosti musí být přesné, ne přibližné. Lazy loading je téměř automatický, ale vyžaduje promyšlené použití, aby nepoškodil LCP. Dobře vyladěný pipeline pro obrázky může dramaticky snížit hmotnost stránky – to je přímý přínos pro uživatelský zážitek, Core Web Vitals a konverzní poměr.

Postavili jsme pipeline pro weby, které obsluhují desítky milionů optimalizovaných obrázků měsíčně. Principy jsou stejné bez ohledu na měřítko: kódovat při sestavení, elegantně padat zpět, responzivně měnit velikost a načítat líně, ale ne hltavě. Pokud chcete provést audit své současné strategie pro obrázky nebo potřebujete pomoci s implementací pipeline, kontaktujte DigiForge – obvykle dokážeme výrazně snížit hmotnost stránky už při prvním průchodu.