Obrázky a média na webu: formáty, komprese a lazy loading
Rychlý web nepotřebuje všechny obrázky okamžitě, ale hlavní obrázek musí dostat včas. Začněte správnými rozměry, porovnejte AVIF a WebP se zachováním potřebných detailů a odložte média, která návštěvník zatím neuvidí. Rozhodující je spojení kvality, načasování a skutečně doručeného souboru. Pouhá změna přípony nebo zapnutí lazy loadingu pro celou stránku nestačí.
Na firemním webu fotografie prodává detail výrobku, vysvětluje službu nebo dokládá skutečnou realizaci. Když je příliš rozmazaná, ztrácí důvod existence. Když kvůli ní telefon dlouho čeká na první obrazovku, komplikuje přístup ke stejné nabídce. Optimalizace proto potřebuje dvě podmínky: srozumitelný obsah a přiměřené nároky na zařízení návštěvníka.
Následující postup můžete použít při úpravě jedné šablony i při předání webu dodavateli. Technické podklady jsme ověřili 28. října 2026. Výpočet přenosu je výslovně modelový, nikoli výsledek měření klientského webu. O uspořádání první obrazovky pojednává také pravidlo tří vteřin.
01Nejdřív zjistěte, která média návštěvník skutečně potřebuje
Otevřete důležitou stránku na běžném telefonu a projděte cestu od příchodu k rozhodnutí. U každého obrázku si zapište jeho účel, místo na stránce a očekávanou velikost. Produktový detail může potřebovat ostrou hlavní fotografii i samostatný soubor pro přiblížení. Dekorace za formulářem takovou potřebu zpravidla nemá. Nechte odstranit média, jejichž význam neumíte vysvětlit.
Potom oddělte soubor uložený v administraci od souboru, který web skutečně posílá. Velký originál v knihovně nemusí být problém, pokud z něj systém vytváří vhodné varianty. Malý náhled v editoru naopak nic neříká o síťovém přenosu. Vývojář by měl doložit adresu načteného obrázku, jeho rozměry, velikost přenosu a okamžik zahájení požadavku.
Pro začátek vyberte úvodní stránku, jednu službu, detail produktu a dlouhý článek. Je to návrh pracovního vzorku, nikoli statisticky reprezentativní audit. Zahrňte i stránku, do které redakce pravidelně nahrává vlastní fotografie. Právě tam se ukáže, zda pravidla fungují po předání projektu, nebo jen v pečlivě připravené ukázce.
02Formát vybírejte podle obsahu, ne podle stáří přípony
Pro fotografii stojí za porovnání AVIF a WebP. U loga a jednoduché ikony začněte vektorem SVG. Zachování přesných hran nebo pixelů může vyžadovat bezeztrátový export. Žádný formát není automaticky nejmenší pro každý motiv, encoder a nastavení kvality. Výchozí rozhodnutí usnadní tato tabulka; konečný soubor musí projít vizuální kontrolou.
| Formát | Kdy ho zvažovat | Co ověřit |
|---|---|---|
| AVIF | Fotografie a složitější rastrové ilustrace | Detail, barevné přechody, rychlost zpracování a podporu celého publika. |
| WebP | Fotografie, průhledná grafika i bezeztrátové varianty | Zda ztrátový export nepoškozuje text, okraje a produktové detaily. |
| SVG | Loga, ikony, jednoduchá schémata | Složitost, zbytečná vložená data a bezpečný proces pro nahrávané soubory. |
| JPEG | Fotografie, kompatibilní náhradní varianta | Ztrátové artefakty; formát nepodporuje průhledné pozadí. |
| PNG | Přesná rastrová grafika a archivní podklady | Zda stejnou kvalitu nezajistí menší bezeztrátový WebP nebo SVG. |
WebP podporuje ztrátovou i bezeztrátovou kompresi a průhlednost. AVIF je další kandidát pro úsporné rastrové obrazy. Neodvozujte z obecných ukázek garantovanou úsporu pro svou fotobanku. Ušetřené kilobajty mají smysl, pokud zůstane vidět povrch materiálu, kresba výrobku a informace důležitá pro nákup.
SVG popisuje tvary a křivky, ale složitá ilustrace může obsahovat mnoho dat a být náročná na vykreslení. Převést fotografii na obrovskou vektorovou mozaiku není užitečný cíl. PNG je bezeztrátový; průhlednost sama o sobě však není důvod posílat každou fotografii jako PNG. JPEG zůstává praktickou fotografickou variantou, zejména tam, kde ho vyžaduje navazující systém.
03Kompresi schvalujte na skutečném motivu
Uchovejte kvalitní originál a všechny varianty vytvářejte z něj. Opakované ukládání již ztrátově zkomprimovaného souboru může zhoršovat obraz bez užitečného přínosu. Nejprve rozhodněte o výřezu a rozměrech, potom o kompresi. Komprimovat nepotřebné miliony pixelů je horší zadání než odstranit je ještě před exportem.
Vyberte několik obtížných motivů: obličej, listí, tmavý přechod, jemnou texturu a snímek rozhraní s malým textem. Pro každý exportujte kandidáty a prohlédněte je v cílové velikosti i přiblížení. Číslo „kvalita 80“ není společná jednotka různých formátů a nástrojů. Dodavateli raději ukažte detail, který musí zůstat rozeznatelný.
Pro produktový katalog může být přijatelné jiné nastavení než pro portréty týmu. Sepište krátké pravidlo pro jednotlivé typy obsahu a uložte schválené příklady. Rozpočet na velikost souboru používejte jako upozornění k revizi. Pevný limit bez ohledu na obsah snadno vede k rozmazaným návodům, zatímco zbytečná dekorace limitem projde. O výsledku rozhoduje účel obrázku a celý kontext stránky.
04Srcset a sizes doručí vhodnou velikost
Jeden obrázek široký 3000 pixelů není automaticky vhodný pro každou kartu na telefonu. Připravte několik rozměrových variant stejného motivu. Srcset popíše dostupné šířky a sizes očekávanou šířku obrázku v rozvržení. Prohlížeč vybírá s ohledem na podmínky zařízení. Popisná syntaxe responzivních obrázků mu dává možnosti, neslibuje vždy jediný přesný soubor.
Následující ilustrativní ukázka předpokládá sloupec široký nejvýše 680 CSS pixelů a na menším displeji boční odsazení dohromady 32 pixelů. Všechny tři soubory musí skutečně existovat a mít poměr stran 3:2. V reálné šabloně upravte sizes podle jejího rozvržení. Ukázka je určena pro hlavní obrázek, proto se neodkládá.
<img
src="/images/workshop-960.webp"
srcset="/images/workshop-480.webp 480w,
/images/workshop-960.webp 960w,
/images/workshop-1440.webp 1440w"
sizes="(max-width: 720px) calc(100vw - 32px), 680px"
width="1440" height="960"
loading="eager" fetchpriority="high"
alt="Truhlář kontroluje povrch dřevěného stolu v dílně"
style="display:block;width:100%;max-width:680px;height:auto">Šířky 480w, 960w a 1440w musí odpovídat skutečným souborům. MDN popisuje vztah srcset a sizes. Telefon s vysokou hustotou bodů může potřebovat více obrazových pixelů, než kolik zabírá obrázek v CSS. Kontrolujte proto vybraný soubor i jeho vzhled. Nehodnoťte výsledek jen podle šířky okna na notebooku.
05Picture řeší formát i odlišný výřez
Responzivní velikost a změna kompozice jsou odlišné úkoly. U první zachováváte stejný obrázek v několika rozlišeních. U druhé může telefon potřebovat těsnější výřez, aby obličej nebo produkt nezmizel v širokém záběru. Pro takovou volbu slouží picture a jeho zdroje. Uvnitř zůstává img s použitelnou základní adresou a alternativním textem.
Pokud nabízíte AVIF a WebP, nastavte správný typ u zdrojů a zkontrolujte náhradní variantu. Připravené soubory nejsou totéž jako správně sestavený HTML výstup. Častou chybou je zdroj s jinou kompozicí, ale popisem odpovídajícím původní fotografii. U přepínaných poměrů stran také rezervujte správný prostor pro příslušné rozvržení.
CSS object-fit upravuje zobrazení uvnitř rámečku. Samotné vizuální oříznutí velké fotografie nesnižuje její přenosovou velikost. U složitého motivu může být lepší připravit samostatný výřez než nechat středový ořez odříznout rozhodující detail. Na produktové kartě například nesmí zmizet část výrobku, podle které zákazník rozezná variantu.
06Hlavní obrázek nesmí čekat na lazy loading
Largest Contentful Paint, zkráceně LCP, sleduje vykreslení největšího relevantního obrazového nebo textového prvku v zobrazené části stránky. Na různých šířkách může jít o jiný prvek. Nejprve ověřte, co je jím na vašem webu. Pokud je to hlavní fotografie, web.dev výslovně doporučuje nepoužívat pro ni lazy loading.
Adresa důležitého obrázku má být objevitelná včas, ideálně už z počátečního HTML. Jestli ji prohlížeč dostane až po stažení a spuštění několika skriptů, malý soubor sám čekání nevyřeší. Zkontrolujte síťovou časovou osu: kdy se objevil požadavek, jak dlouho se stahoval a kdy se hotový obrázek opravdu vykreslil.
Fetch priority umožňuje naznačit důležitost stahování. Vysokou prioritu používejte cíleně u pravděpodobného LCP obrázku, nikoli plošně pro galerii. Preload má význam, když napravuje konkrétní pozdní objevení zdroje. Musí odpovídat skutečně použité variantě; jinak můžete přidat zbytečný přenos. Každý takový zásah ověřte na výsledném síťovém záznamu.
07Odkládejte obsah pod první obrazovkou a rezervujte mu místo
Pro fotografie hlouběji v článku je vhodným výchozím řešením loading="lazy". Nativní odkládání obrázků nechává načasování na prohlížeči. Ten může obrázek stáhnout ještě před vstupem do viditelné oblasti. Neslibujte proto přesnou hranici ani nulový přenos všeho, co uživatel zatím nevidí.
U každého obrázku zachovejte rozměry nebo jiný spolehlivý způsob rezervace prostoru. Návštěvník nemá při načtení fotografie ztratit řádek textu nebo omylem klepnout na posunuté tlačítko. Zkontrolujte skutečné chování při pomalém připojení, protože rychlá lokální zkouška může změnu rozvržení snadno skrýt. Zástupná plocha má odpovídat výslednému poměru stran.
Dlouhá galerie potřebuje vlastní zkoušku: první viditelný snímek, další snímky, otevření detailu a návrat zpět. Nepřidávejte vlastní knihovnu jen kvůli funkci, kterou vyřeší nativní atribut. Pokud ji potřebujete kvůli konkrétnímu chování, ověřte klávesnici, vypnutý či pomalý JavaScript a dostupnost základních odkazů. Odložení nesmí znamenat, že obsah někdy vůbec nepřijde.
08Alternativní text, popisek a samotný obsah mají různé role
Alternativní text má zastoupit význam obrázku v daném kontextu. Produktová fotografie může popsat provedení nebo viditelný detail. U čistě dekorativního obrázku je vhodný prázdný alt. U obrázku, který je jediným obsahem odkazu, je důležitý účel odkazu. Rozhodování shrnuje strom pro alternativní text od W3C.
Popisek je viditelný všem a může vysvětlit zdroj, okolnosti nebo význam zobrazené situace. Nepoužívejte obě pole jako dvě kopie seznamu klíčových slov. U složitého diagramu samotná krátká věta nestačí: W3C doporučuje také podrobný textový ekvivalent. Tabulka nebo vysvětlení v článku pomůže i čtenáři na malém displeji.
Nedávejte rozhodující cenu, podmínku nebo návod pouze do obrázku. Text v HTML lze zvětšit, označit a lépe přizpůsobit rozvržení. Při lokalizaci upravte i text vložený do grafiky a popisy, ne pouze okolní odstavce. Ke schválení média patří rovněž původ a oprávnění k jeho použití. Rychlé stažení souboru neříká nic o tom, zda jej firma smí zveřejnit.
09Video řešte jako samostatnou součást stránky
Krátká ukázka produktu může vysvětlit pohyb lépe než sada fotografií. Nemusí se ale automaticky spustit při každé návštěvě. Začněte dobrým náhledovým obrázkem, srozumitelným tlačítkem přehrávání a přehrávačem, který lze ovládat klávesnicí. Rozmyslete si, zda návštěvník potřebuje celé video, nebo nejdřív několik vět s jeho obsahem.
MDN popisuje preload jako doporučení pro prohlížeč. Hodnota none vyjadřuje, že se video nemá předem načítat; není to univerzální záruka všech síťových podmínek. Autoplay mění situaci, protože přehrávání potřebuje data. Podle aktuálního přehledu web.dev se rozšiřuje i podpora loading="lazy" pro video. Ověřte cílové prohlížeče a chování bez této podpory.
Externí přehrávač může přidat skripty a další připojení ještě před přehráním. Zvažte lehký náhled, který plný přehrávač načte až po aktivaci, a ověřte skutečný dopad. Titulky musí odpovídat řeči a důležitým zvukům; W3C rozlišuje přístupné titulky od pouhého jazykového překladu. Automatický přepis před zveřejněním zkontrolujte, zejména názvy produktů a odborné pojmy.
10Modelový příklad: co se změní na stránce se sedmi fotografiemi
Představte si stránku služby s jednou hlavní fotografií a šesti snímky realizací hlouběji pod ní. Pro jednoduchý výpočet předpokládejme, že původně se všech sedm souborů načítá hned a každý má 900 kB. Počáteční obrazový přenos je 7 × 900 = 6300 kB. Používáme desetinné kilobajty a ignorujeme hlavičky, mezipaměť i ostatní soubory stránky.
V návrhové variantě má hlavní snímek 180 kB a každá menší fotografie 90 kB. Předpokládejme navíc, že vzdálené fotografie prohlížeč při prvním zobrazení ještě nenačte. Počáteční přenos obrázků je potom 180 kB. Při prohlédnutí všech šesti dalších fotografií se přenese celkem 180 + 6 × 90 = 720 kB. Jde o zvolené vstupy, nikoli naměřené výsledky komprese.
| Model | Při prvním zobrazení | Po načtení všech fotografií |
|---|---|---|
| Původní soubory bez odložení | 6300 kB | 6300 kB |
| Menší varianty a odložená galerie | 180 kB | 720 kB |
Příklad odděluje dva přínosy: menší soubory snižují celkový přenos, odložení mění jeho okamžik. Neříká, o kolik se zlepší LCP nebo objednávky. Hlavní obrázek může stále čekat na server nebo skript. Teprve test ukáže, zda návštěvník vidí důležitý obsah dříve a zda zmenšené fotografie stále plní svůj účel.
11Při nasazení ověřte celou cestu od CMS po prohlížeč
Automatický převod v CMS, optimalizace ve frameworku a obrázková CDN mohou být užitečné. Sepište však, která vrstva vlastní originál, které rozměry vytváří a kdy. Několik nezávislých převodů za sebou komplikuje kontrolu kvality i hledání problémů. U změny zdroje ověřte také to, zda se obnovily všechny odvozené velikosti.
Při použití stejné adresy pro různý formát musí správně fungovat vyjednávání a klíč mezipaměti. Jinak může návštěvník dostat nevhodnou variantu. U dlouho uchovávaných veřejných souborů pomáhá verzování adres; MDN vysvětluje pravidla HTTP cache. Nestačí na svém počítači obnovit stránku a předpokládat, že stejný obrázek vidí všichni.
Zkontrolujte odpověď serveru, typ obsahu, práva přístupu, adresy se správnou velikostí písmen a obrázky v jazykových verzích. Žádná varianta srcset nesmí vracet chybu nebo HTML místo obrázku. Google doporučuje dostupné obrázky v běžném img se src; obsah, který vzniká jen složitou interakcí, zbytečně komplikuje dohledatelnost. Ověřte také náhled při sdílení odkazu, který může mít vlastní obrázek.
12Před předáním ověřte výsledek a nastavte pravidla pro redakci
Porovnávejte stejné stránky, zařízení, připojení a stav mezipaměti. První návštěva a opakované otevření odpovídají na různé otázky. V síťovém panelu Chrome DevTools sledujte skutečné požadavky a jejich časování. Samostatně ověřte vzhled, posuny rozvržení a práci s galerií. Menší součet bajtů není omluvou pro nečitelný návod.
- Hlavní obrázek se načítá včas a nemá plošně přidaný lazy loading.
- Vybraná velikost odpovídá rozvržení a ostrým detailům na běžném telefonu.
- Obrázky mají rezervovaný prostor, správné výřezy a vhodné alternativní texty.
- Galerie i video fungují při ovládání klávesnicí a na pomalejším připojení.
- Všechny adresy variant fungují a změna obsahu se projeví i přes mezipaměť.
- Redakce má originály, příklady správných exportů a jasný postup pro nová média.
Odpovědnost rozdělte konkrétně: redaktor vybírá obsah a význam popisku, návrhář schvaluje výřez a vývojář ověřuje doručení. Při nové šabloně znovu zkontrolujte sizes a načasování. Jestli řešíte širší proměnu webu, navazuje postup tvorby webu na míru. Na schůzku s dodavatelem přineste několik skutečných stránek a fotografií, nikoli jen obecný požadavek „zmenšit obrázky“.
13Časté otázky
Je AVIF vždy lepší než WebP?
Ne. Porovnejte konkrétní motiv při srovnatelné vizuální kvalitě a zohledněte zpracování i cílové prohlížeče. Nejmenší soubor není užitečný, pokud poškozuje detail, který zákazník potřebuje. Podle prostředí může být vhodné nabídnout více formátů.
Jakou maximální velikost má mít obrázek na webu?
Univerzální limit neexistuje. Malá ikona, hlavní fotografie a obrázek pro přiblížení mají odlišný účel. Nastavte rozpočty podle šablon a typů médií, kontrolujte celkový přenos a u překročení žádejte zdůvodnění. Začněte správnými rozměry.
Mám zapnout lazy loading pro všechny fotografie?
Ne. Hlavní obrázek, který může tvořit LCP, neodkládejte. Lazy loading používejte u vhodných snímků mimo první obrazovku a ověřte chování galerie. Prohlížeč může obsah načíst ještě před jeho vstupem do viditelné oblasti.
Stačí zmenšit obrázek pomocí CSS?
CSS může změnit zobrazenou velikost, ale samo nepřipraví menší přenášený soubor. Potřebujete rozměrové varianty a správné propojení přes srcset a sizes nebo ekvivalentní funkci obrázkového systému. Výsledek ověřte v síťových požadavcích.
Musí mít každý obrázek dlouhý alternativní text?
Ne. Popis má vystihovat význam v kontextu. Dekorace může mít prázdný alt, obrázek v odkazu musí pomoci pochopit jeho účel. Složitý diagram potřebuje také dostupné podrobnější vysvětlení, například text nebo tabulku vedle obrázku.
Vyřeší obrázková CDN optimalizaci automaticky?
Pomůže vytvářet a doručovat varianty, ale potřebuje správné vstupy, rozměry, pravidla cache a kontrolu výsledku. Neurčí sama obchodně důležitý výřez ani vhodný textový popis. Ověřte skutečně načtenou variantu, ne pouze nastavení služby.
Znamená menší přenos automaticky lepší LCP?
Nemusí. Rozhoduje také včasné objevení souboru, odpověď serveru a okamžik vykreslení. Menší obrázek čekající na skript může přijít stále pozdě. Měřte celý průběh načtení a oddělujte laboratorní zkoušku od zkušenosti skutečných návštěvníků.
14Zdroje a metodika
Odkazy v textu vedou na dokumentaci MDN, web.dev, Chrome DevTools, Google Search Central a W3C WAI ověřenou 28. října 2026. Vlastnosti formátů doplňuje přehled obrazových typů MDN. Doporučený pracovní postup a kontrolní seznam jsou redakční syntézou těchto technických principů.
Nevycházíme z vlastního srovnávacího měření encoderů ani z měření konkrétního klientského webu. Model se sedmi fotografiemi má předem zvolené vstupy. Před nasazením ověřte kompatibilitu konkrétních funkcí ve svém prostředí a výsledný HTML výstup, nikoli pouze nastavení v editoru.