Znalosti manGowebu
Čá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.


Editor nahraje do CMS fotku. Má 8 MB a 6000 px na šířku. Menší varianta neexistuje, protože „CMS si to snad zmenší sám". Alt text skončí jako obrazek_final_v2.jpg, protože políčko nešlo přeskočit. A původ obrázku? Stažený z Googlu, protože vypadal dobře a byl po ruce.

To není jedna drobná chyba. To jsou čtyři různé problémy v jednom souboru.

Na média se proto nedívejte jen jako na „obrázky u stránky". Jeden obrázek je zároveň:

Obrázek jako bajty: formáty

Média bývají největší datová část stránky. Web Almanac 2024 (data z HTTP Archive, říjen 2024) u desktopové homepage měří medián 1 054 KB obrázků proti 613 KB JavaScriptu. JavaScript sice přebral prvenství v počtu požadavků, ale v přenesených bajtech obrázky pořád bolí hodně.

První místo, kde to můžete ovlivnit, je formát. U fotografií dnes dává smysl generovat víc variant: AVIF jako nejúspornější volbu, WebP jako širší zálohu a JPEG jako poslední jistotu. Podle Google studie je WebP při srovnatelné kvalitě 25–34 % menší než JPEG. AVIF jde ještě dál: web.dev uvádí úspory vyšší než 50 % oproti JPEG. Skutečná úspora závisí na motivu, kvalitě a enkodéru, ale u velké fotky nejde o kosmetiku – řeč je o stovkách kilobajtů.

Z toho neplyne „zapni AVIF a hotovo". AVIF se enkóduje pomaleji a nehodí se na každý typ grafiky. A zatím ho nasadilo jen zlomek webů – Web Almanac 2024 (Media) měří AVIF na zhruba 1 % obrázků, WebP na 12 %. Správná strategie proto není vybrat jednoho vítěze, ale nabídnout prohlížeči sadu variant. Prohlížeč si vezme první formát, 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>

V Nua site máme komponentu <Image>, která tuhle práci udělá za vás. U webů mimo tenhle stack si hlavně zkontrolujte, že pipeline opravdu vyrábí formáty, velikosti a rozměry, které čekáte.

Responzivní obrázky

Od responzivních obrázků chceme dvě různé věci a je dobré je nemíchat.

První je resolution switching: na různě velké obrazovky poslat různě velké soubory stejného obrázku. To řeší 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.

sizes nejsou detail. Prohlížeč vybírá správný soubor dřív, než spočítá layout, takže sám ještě neví, kolik místa obrázek dostane. Musíte mu to říct vy.

<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á věc je art direction: na různých zařízeních nechcete jen jinou velikost, ale jiný ořez nebo jiný obrázek. Na desktopu široký záběr osoby v místnosti, na mobilu detail obličeje, aby člověk nezanikl v malém formátu. Na to použijete <picture> s <source media="…">. Stejný element zvládá i přepínání formátu z předchozí sekce.

Obrázek, co zpomaluje web

Formát a velikost řeší, kolik dat musí prohlížeč stáhnout. Pořadí a priorita řeší, kdy je stáhne. A právě to často rozhoduje o Core Web Vitals.

LCP element, tedy největší viditelná věc po načtení stránky, bývá velmi často hero obrázek. Když ho prohlížeč stáhne pozdě, návštěvník čeká na hlavní vizuál a LCP se zhorší.

Tady vzniká častá chyba: loading="lazy" se nasadí plošně na všechny obrázky. Jenže lazy loading patří na obsah pod ohybem, tedy na obrázky, které nejsou vidět při prvním vykreslení. Když lazy načtete i hero, odložíte stahování zrovna toho obrázku, na kterém LCP stojí. Hero obrázek nemá být lazy. Pokud je kandidátem na LCP, dejte mu fetchpriority="high".

Druhá věc je posun layoutu. Když obrázek nemá v HTML rozměry, prohlížeč při prvním vykreslení neví, kolik místa mu má nechat. Jakmile se fotka načte, obsah pod ní poskočí. To měří metrika CLS. Řešení je jednoduché a pořád se zanedbává: na <img> vždy width a height, případně rezervované místo v CSS přes aspect-ratio.

Animace patří do videa, ne do GIFu

GIF je špatná náhrada videa. Má slabou kompresi, omezené barvy a u krátkých smyček bývá násobně větší než ekvivalentní video. Soubor, který by jako MP4 měl stovky kilobajtů, může jako GIF narůst na několik megabajtů.

Praktická náhrada je krátké video vložené jako <video autoplay muted loop>. muted je podstatné, protože automatické přehrávání bez zvuku má v prohlížečích mnohem lepší šanci projít. U mobilů se často hodí přidat i playsinline.

S formáty je to u videa méně čisté než u obrázků. WebM mívá dobrý poměr velikost/kvalita, MP4 má pořád nejširší kompatibilitu. Buď generujte obě varianty, nebo zůstaňte u MP4, pokud je cílem jednoduchost. I u videa se vyplatí dát prohlížeči rozumně velký soubor, ne jednu obří smyčku pro všechna zařízení. A hlídejte kodek: MP4 je obálka, ne přesná specifikace. Fajn open source nástroj na správný export je https://handbrake.fr/.

Homepage je místo, kde se sbíhají požadavky všech oddělení. Marketing chce kampaň, obchod produkt, vedení vizi. Odpovědí bývá carousel, hero video nebo vrstva animací. U každého z nich se vyplatí položit jednu otázku: je to věc vkusu, nebo to má měřitelný dopad? Většinou má.

Carousel. Data dlouhodobě ukazují, že carousely lidi přehlížejí. V nejcitovanější studii (Erik Runyon, University of Notre Dame, 2013) kliklo na hlavním webu na carousel jen něco přes 1 % návštěvníků, a z toho 84 % na první snímek. Na cílenějších webech to bylo o trochu lepší (1,7–2,3 %), ale i tam první pozice brala 48–62 % všech kliků. Vidí se v podstatě jen první snímek, zbytek propadá. NN/G to potvrzuje eyetrackingem: lidé velké rotující obrázky často hned odscrollují a obsah minou, a kvůli pohybu je vyhodnocují jako reklamu a ignorují (na animované reklamy se podívají jen ve 27 % případů).

Můj názor je vyhraněný: jediný důvod pro carousel je neschopnost organizace domluvit se na prioritách. Pět snímků znamená, že nikdo neměl odvahu říct, co je první. Návštěvník to za vás nevyřeší, on první snímek vezme jako jediný a zbytek nechá rotovat naprázdno. K tomu připočtěte výkon: každý snímek je další obrázek ke stažení, často nad ohybem, takže rotující galerie umí pohřbít LCP. A automaticky se posouvající obsah je problém i pro přístupnost, protože uživatel nestíhá číst a nemá pohyb pod kontrolou.

Hero video. Samo o sobě nevadí. Velký tichý záběr nad ohybem umí být silnější než statická fotka. Problém není jestli, ale jak. Video musí být uděláno technicky rozumně: lazy načítání, žádné blokování prvního vykreslení, žádné kažení LCP. Když se načítá blbě a brzdí první vykreslení, máte na homepage nejtěžší prvek stránky přesně tam, kde uživatel čeká na hlavní vizuál. Platí pro něj stejná pravidla jako pro hero obrázek z předchozích sekcí, jen je toho víc ke stažení.

Animace. Reveal-on-scroll, plovoucí prvky a podobné efekty jsou spíš nice-to-have. Často jsou víc pro klienta než pro návštěvníka, hezky se prezentují na schvalovačce a v reálném provozu nic nepřidají. Mě osobně animace moc nezajímají a chci je nepřeplácané. Otázka zase není vkus, ale technologický dopad. Efekty navázané na scroll stojí výkon a při přehnání působí rušivě. A pohyb, který se spustí sám, naráží na přístupnost: část uživatelů má v systému zaplý prefers-reduced-motion a očekává, že web pohyb utlumí.

U všech tří prvků je to stejné. Neptejte se, jestli se to líbí. Ptejte se, co to stojí a co to přináší, a měřte obojí.

Obrázek jako obsah: alt text

Alt text je místo, kde se médium vrací k tomu, že je to obsah. WCAG (kritérium 1.1.1 Non-text Content, úroveň A) chce textovou alternativu. Ne mechanicky pro každý obrázek stejně, ale podle kontextu.

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ě, některé čtečky místo něj přečtou 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 odkazu, ne popis fotky.

Nejlepší test je jednoduchý: kdyby obrázek zmizel, jaká informace by čtenáři chyběla? To patří do alt textu. Když by nechybělo nic, obrázek je dekorace.

Zbývá praktická otázka, na kterou se málokdy myslí: čí je to práce? Alt text je obsah. Je to pole obsahového modelu jako titulek nebo perex, takže odpovědnost přirozeně patří tomu, kdo vlastní obsah, tedy editorovi, ne vývojáři. Konkrétní podoba je hodně případ od případu a dnes s nástupem AI ho často generujeme automaticky. To je rozumný start, ale potřebuje lidskou kontrolu: AI popíše, co na obrázku je, ne proč tam je. Záměr zná člověk, který obrázek do stránky dal. Hlavní je rozhodnout explicitně, čí to je práce. Když to nikdo nevlastní, alt text propadne mezi židle a skončí buď prázdný, nebo generický, a přístupnost tím tiše odejde.

Mediální podklad má život mimo stránku

Mediální podklad není jen upload do pole v CMS. Je to věc, kterou budete za rok hledat, ořezávat, nahrazovat, používat v jiné jazykové verzi nebo dokazovat, odkud pochází.

U každého důležitějšího podkladu se vyplatí mít pár metadat: originál, zdroj, autora, licenci, datum získání, varianty a informaci, kde se používá. U větších týmů to řeší DAM. U menšího webu stačí dobře navržená knihovna médií v CMS nebo i jednoduchá evidence. Podstatné je, aby podklad nebyl anonymní soubor s názvem final_final.jpg.

To souvisí i s obsahovým modelem. Když je fotka autora samostatný mediální podklad, můžete ji změnit jednou a použít ve všech článcích. Když ji pokaždé nahráváte znovu do stránky, vyrábíte si stejnou duplikaci jako u textového obsahu.

A reálná, neanonymní média jsou přesně ten materiál, ze kterého vizuální design staví systém, který obstojí v provozu. Layout vyladěný na hezkou stock fotku spadne ve chvíli, kdy do něj přijde skutečný snímek v jiném poměru stran nebo nepřijde žádný. Média tu kapitolu nezavírají, předávají do ní reálný vstup.

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 nabízí obrázky zdarma i komerčně bez povinného uvedení autora. To ale neznamená, že řeší všechny právní vrstvy. Licence se týká autorského práva k fotce, ne automaticky ochranných známek, log, rozpoznatelných lidí nebo uměleckých děl, které jsou na fotce vidět. Podmínky zároveň omezují odpovědnost Unsplash vůči vám na nízkou částku.

U placených fotobank bývá smluvní krytí a rozsah licence jiný, ale není to jeden univerzální stav. Liší se standardní licence, rozšířená licence, editorial použití, merchandising i převod práv na klienta. Shutterstock například nabízí u standardní licence indemnifikaci do 10 000 USD, u rozšířené licence do 250 000 USD. Prakticky z toho plyne jednoduché pravidlo: u každého cizího média si uložte zdroj, typ licence a důkaz, že jste ji získali oprávněně. U fotek s rozpoznatelnými lidmi, značkami nebo cizím uměleckým dílem řešte i souhlasy.

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

DAM pro malý web většinou zbytečný je. Pravidla pro média zbytečná nejsou.

Stačí minimum: CMS nesmí bez kontroly posílat návštěvníkům osmimegabajtový originál, hlavní obrázky mají mít správné rozměry a priority, a u každého cizího podkladu musí být jasné, odkud pochází a pod jakou licencí se používá. To není aparát pro velký tým. To je prevence pomalého webu, rozbité přístupnosti a nepříjemného e-mailu od právníka.

Praktický checklist

Tři typické záměny

Číst plnou verzi ve wiki →

10 / 26