Znalostní wiki OKF
Část 2 · Postav kostru

Média a podklady

Obrázek je současně obsah, mediální podklad, výkonové břemeno a právní riziko. Každá vrstva má jiného vlastníka a jinou typickou chybu.


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>

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 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

Tři typické záměny

Číst plnou verzi ve wiki →

9 / 26