Média a podklady

Editor nahraje do CMS fotku z foťáku. Originál, 8 MB, 6000 px na šířku. Žádná menší varianta, protože „CMS si to snad zmenší sám". Alt text vyplní jako obrazek_final_v2.jpg, protože to políčko nešlo přeskočit. A obrázek je stažený z Googlu, protože vypadal dobře a byl po ruce. Jedno nahrání, čtyři dluhy.

Tahle scénka je celá kapitola v malém, protože jeden obrázek není jedna věc. Je to obsah, který něco sděluje. Je to mediální podklad, který někde leží a má vlastníka a licenci. Jsou to bajty, které tečou po síti a rozhodují, jak rychle se stránka načte. A je to právní položka, ke které buď máte práva, nebo nemáte. Každá vrstva má jiného člověka, který za ni odpovídá, a jinou chybu, kterou nejčastěji udělá. Tady je rozplétáme.

V obsahovém modelu je médium současně typ pole (media asset) a vlastní typ obsahu s referencí do knihovny podkladů. Jednovětou definici pojmů jako AVIF nebo lazy loading najdete ve společném slovníku. Tady jde o to, jak je použít.

Obrázek jako bajty: formáty

Média jsou nejtěžší část stránky. Web Almanac 2024 (data z HTTP Archive, říjen 2024) měří na desktopu medián 1 054 KB obrázků na stránku proti 613 KB JavaScriptu. JS sice přebral prvenství v počtu požadavků, ale v přenesených bajtech vedou obrázky, zhruba 40 % mediánové váhy stránky. Volba formátu je tedy první páka, kterou máte.

Pořadí je dnes jasné. AVIF je při srovnatelné kvalitě asi o polovinu menší než JPEG a o 20–30 % menší než WebP. WebP je oproti JPEG menší o 25–35 %. Na reálné produktové fotce 2000×2000 to vypadá takhle: JPEG v kvalitě 80 váží kolem 540 KB, WebP kolem 350 KB, AVIF kolem 210 KB. Úspora proti JPEG skoro 60 %, za stejný vizuální dojem.

Z toho ale neplyne „zapni AVIF a hotovo". AVIF se enkóduje pomaleji, starší prohlížeče ho neumí, a u ostrých hran nebo malých ikon nemusí vyhrát. Správná strategie není jeden formát, ale sada variant. Nabídnete AVIF jako první volbu, WebP jako zálohu, JPEG jako poslední záchranu, a prohlížeč si vezme první, který umí. Technicky to obstará element <picture> s několika <source>:

<picture>
  <source srcset="foto.avif" type="image/avif">
  <source srcset="foto.webp" type="image/webp">
  <img src="foto.jpg" alt="…" width="2000" height="2000">
</picture>

Responzivní obrázky: dvě úlohy, ne jedna

„Responzivní obrázky" znějí jako jedna věc. Jsou to dvě, a pletou se.

První úloha je resolution switching: tentýž obrázek v několika velikostech, ze kterých prohlížeč vybere nejmenší, který stačí. Řeší ji srcset a sizes na <img>. Do srcset vypíšete varianty s jejich šířkami, do sizes řeknete prohlížeči, jak široký obrázek na stránce reálně bude. A to je podstatné. Prohlížeč vybírá soubor dřív, než spočítá layout, takže sám nezjistí, kolik místa obrázek dostane. Musíte mu to říct.

<img srcset="foto-480.jpg 480w, foto-960.jpg 960w, foto-1920.jpg 1920w"
     sizes="(max-width: 600px) 100vw, 50vw"
     src="foto-960.jpg" alt="…">

Druhá úloha je art direction: na různých zařízeních chcete jiný obrázek, ne jen jinou velikost téhož. Na desktopu široký záběr krajiny, na mobilu těsný ořez na obličej, aby v malém formátu nezanikl. To je práce pro <picture> s <source media="…">. Stejný element zvládá i přepínání formátu z předchozí sekce.

Záměna obojího je běžná. <picture> se nasadí tam, kde stačil srcset, a vznikne zbytečná složitost. Nebo se přes srcset posílá ten samý ořez do všech velikostí, a na mobilu je hero fotka k nepoznání.

Obrázek jako výkonové břemeno

Formát a velikost řeší, kolik bajtů teče. Pořadí a priorita řeší, kdy tečou, a to rozhoduje o Core Web Vitals. LCP element, ta největší věc viditelná po načtení, je na drtivé většině stránek hero obrázek. A jak rychle ho doručíte, tím je z velké části dané LCP.

Tady se dělá nejčastější chyba celé kapitoly. loading="lazy" se vyhlásí za osvědčený postup a nasadí plošně na všechny obrázky. Jenže lazy loading je cílená optimalizace pro obsah pod ohybem, který možná nikdo neuvidí. Když dopadne i na hero, odložíte stahování zrovna toho obrázku, na kterém LCP stojí. Metriku tím zhoršíte. Hero obrázek nemá být nikdy lazy. Naopak dostane fetchpriority="high", aby se začal stahovat dřív než ostatní.

Automatika to plete sama. WordPress nebo Elementor umí přiřadit fetchpriority či lazy špatnému elementu, třeba obrázku v mega menu nebo prvnímu obrázku v DOM, který ale leží pod ohybem. Výsledek vypadá jako optimalizace a chová se jako brzda. Vyplatí se ověřit, na kterém elementu priorita reálně sedí.

Druhá výkonová past je posun layoutu. Když obrázek nemá v HTML rozměry, prohlížeč při prvním vykreslení neví, kolik místa mu nechat, a jakmile se fotka načte, obsah pod ní poskočí. To je CLS. Řešení je triviální a pořád se zanedbává: na <img> vždy width a height (nebo místo rezervovat v CSS přes aspect-ratio). Pozor na časté nedorozumění. Tahle čísla neurčují, jak velký obrázek nakonec bude, to řeší CSS. Jsou tam jen kvůli poměru stran, aby si prohlížeč rezervoval správný prostor předem.

Animace patří do videa, ne do GIFu

GIF je z webu, který už neexistuje, a výkonu webu škodí. Jeho komprese je tak neefektivní, že soubor bývá 10 až 50× větší než ekvivalentní H.264 video. Pětivteřinová smyčka, která jako MP4 váží 200 KB, jako GIF naroste na 4 až 8 MB. K tomu se GIF dekóduje na CPU a nejde hardwarově akcelerovat, kdežto <video> může dekódovat GPU, takže běží plynuleji a procesor netrpí. Lighthouse to říká přímo: „use video formats for animated content".

Praktická náhrada GIFu je <video autoplay muted loop>. WebM je menší než MP4, ale ne všude podporovaný, takže generujte oba. A video není automaticky lehké: 1080p MP4 se smyčkou 10 vteřin snadno váží 8 až 15 MB, což je na 3G přes 45 vteřin stahování „okamžitého" obsahu na pozadí. Titulky a transkripty videa už jsou téma přístupnosti.

Obrázek jako obsah: alt text

Alt text je místo, kde se médium vrací zpět k tomu, že je to obsah. WCAG (kritérium 1.1.1 Non-text Content, úroveň A) chce textovou alternativu, ale ne mechanicky. Záleží na kontextu, ne na obrázku samém.

Dekorativní obrázek, který nic nesděluje, dostane prázdné alt="". Čtečka ho pak přeskočí. Pozor na rozdíl: alt="" není totéž jako chybějící atribut. Když alt chybí úplně, leckterá čtečka místo něj přečte název souboru, takže uživatel uslyší obrazek_final_v2.jpg. To je horší než ticho.

Funkční obrázek se popisuje funkcí, ne vzhledem. Ikona lupy v tlačítku hledání má alt="Hledat", ne „lupa". Obrázek, který je odkazem, má v alt cíl toho odkazu, ne popis fotky. W3C na to má rozhodovací strom (alt Decision Tree), který provede typickými případy. Důsledek pro strukturu je zásadní: alt text je pole typu obsahu, ne dodatečná vrstva nalepená po publikaci. Patří k podkladu od začátku, stejně jako u strukturovaného obsahu v obsahovém modelu. A je to současně signál pro SEO, nejen pro přístupnost.

Obrázek jako podklad: knihovna a varianty

Teď k tomu, kde médium fyzicky žije. Prosté souborové úložiště a správa digitálních podkladů (DAM) se liší jednou věcí: v DAM se podklady pojmenovávají, kategorizují a opatřují metadaty konzistentně. To z hromady souborů dělá knihovnu, ve které se dá hledat.

Sem patří konvence pojmenování. Název má dávat kontext i mimo systém, třeba YYYYMMDD_Znacka_Kampan_TypPodkladu_Verze. Žádné speciální znaky (!, ?, @, #, $), které matou operační systém i vyhledávání. A platí to jen tehdy, když konvenci dodržují všichni, kdo nahrávají, jinak je to dekorace.

Knihovna podkladů je přímá nadstavba principu z obsahového modelu: reference, ne duplikace. Jeden zdroj pravdy pro každé médium, na který obsah odkazuje, místo aby si tutéž fotku kopíroval do každé stránky. Logo se vymění na jednom místě a propíše se všude.

A pak je tu problém variant. Jedna fotka neexistuje jednou. Existuje v několika formátech (AVIF, WebP, JPEG) × několika velikostech (480, 960, 1920…) × ořezech pro sociální sítě a OG náhledy. To je rozhodnutí, ne náhoda. Buď varianty generujete při buildu (Astro nebo Next mají image pipeline, výsledek jsou statické soubory bez závislosti na dodavateli), nebo za běhu přes image CDN (Cloudinary, Imgix, Cloudflare Images). Tam požádáte URL parametrem a CDN sama změní velikost, zkomprimuje a podle hlavičky Accept vrátí AVIF nebo WebP a uloží výsledek do cache na edge. Build-time se vyplatí malému webu se statickými variantami. CDN se vyplatí, když obsah nahrávají uživatelé a variant je moc na ruční správu. Doručení a edge cache rozvádí hosting a CDN.

Obrázek jako právní riziko

Poslední vrstva se na výkonu ani přístupnosti nepozná, a přesto umí stát nejvíc. „Stažené z Googlu" nebo „z Unsplashe, je to zadarmo" není totéž jako „máme k tomu práva".

Unsplash (od roku 2021 patří Getty) nabízí obrázky zdarma i komerčně bez uvedení autora. Háček je v tom, co nedává. Neposkytuje žádné smluvní krytí, jeho maximální odpovědnost vůči vám je 100 dolarů. Pro srovnání, Shutterstock dává krytí přes 25 000 dolarů na obrázek. Unsplash navíc neověřuje souhlasy fotografovaných osob ani ochranné známky, takže u fotek s rozpoznatelnými lidmi nebo značkami nesete riziko vy.

Že „zadarmo" neznamená „bez rizika", ukazuje reálná kauza: majitel webu použil volně stažený obrázek a dostal zpětnou licenční výzvu od Copytracku. Obrázek i účet toho, kdo ho nahrál, byly mezitím smazané, protože je nahrál někdo, kdo k němu sám neměl práva. Doložitelnost licence je proto pole podkladu, ne dodatečná starost, a navazuje na inventuru podkladů v rámci práva, soukromí a souhlasu.

Není to zbytečné pro malý web?

„Knihovna podkladů, konvence pojmenování, varianty, to je aparát pro velkou redakci, my máme pětistránkovou vizitku." Zčásti ano. Ruční pojmenovávání podle striktní konvence nebo placené DAM jsou na pět stránek zbytečně těžký aparát, a image CDN je vedle Astro image pipeline zbytečná závislost na dodavateli.

Co se neškáluje dolů, jsou otázky. Máme k téhle fotce licenci? Má hero obrázek rozumný formát a rozměry? Má hero obrázek lazy loading? Nemá mít. Má dekorativní obrázek alt="" a funkční smysluplný alt? Tyhle platí pro vizitku stejně jako pro velký web. Inventuru toho, co reálně máme a v jaké kvalitě, odhalí už discovery. Škáluje se aparát, ne otázka.

Praktický checklist

• Hero / LCP obrázek není lazy a má fetchpriority="high".
• Pod ohybem se používá loading="lazy", cíleně, ne plošně.
• Každý <img> má width a height (nebo rezervované místo přes CSS), aby nevznikal CLS.
• Formáty jako sada variant: AVIF, WebP jako záloha, JPEG jako záchrana přes <picture>.
• Responzivní varianty přes srcset + sizes (resolution switching) a <picture> jen tam, kde je potřeba art direction.
• Animace jako <video> (MP4 i WebM), ne GIF.
• Alt text je pole podkladu: dekorativní alt="", funkční popisuje funkci.
• Každý podklad má vlastníka, licenci a název podle konvence bez speciálních znaků.
• Varianty se generují systematicky (build-time, nebo image CDN), ne ručně ad hoc.

Tři typické záměny

• srcset = <picture>. srcset + sizes přepíná rozlišení téhož obrázku. <picture> mění obrázek nebo formát podle zařízení (art direction). Záměna přidá složitost, kde nemá co dělat, nebo pošle špatný ořez na mobil.
• Lazy loading je vždy dobrý. Plošný lazy loading odloží i hero a zhorší LCP. Je to cílená optimalizace pod ohyb.
• Zadarmo = bez rizika. Unsplash zdarma neznamená právní krytí: žádné smluvní krytí, neověřené souhlasy fotografovaných osob a ochranné známky.

Zdroje

• HTTP Archive / Web Almanac 2024 — page weight a media: medián 1 054 KB obrázků vs. 613 KB JS na desktopu, 18 obrázků na stránku.
• ShortPixel, FreeImages — AVIF vs. WebP vs. JPEG, reálné velikosti na testovacích fotkách.
• web.dev (Google) — responsive images, fetch priority, optimize CLS, video performance.
• MDN — responsive images, picture element, fix image LCP.
• W3C WAI — Images Tutorial, alt Decision Tree, dekorativní obrázky (WCAG 1.1.1).
• Mux, Uploadcare, Lighthouse — GIF vs. HTML5 video, efektivita komprese a dekódování.
• Cloudinary, Imgix — image CDN, transformace on-the-fly, auto formát.
• Smartsheet, Brandfolder, ImageRelay — DAM, metadata a konvence pojmenování.
• Unsplash Help, PicDefense, LicenseOrg — licence, smluvní krytí, souhlasy fotografovaných osob, kauza Copytracku.

Média jsou jedním z typů obsahu v obsahovém modelu: knihovna podkladů je reference, ne duplikace, a alt text je pole. Jejich váha a doručení rozhodují o Core Web Vitals, alt text a titulky o přístupnosti, licence o právu, soukromí a souhlasu. Doručení variant stojí na hostingu a CDN, alt a názvy souborů jsou signál pro SEO a inventura podkladů patří do discovery. Pojmy sjednocuje slovník.