Obrázky a médiá na webe: formáty, kompresia a lazy loading

01Zistite, ktoré médiá návštevník skutočne potrebuje

Otvorte dôležitú stránku na bežnom telefóne a prejdite cestu od príchodu po rozhodnutie. Pri každom obrázku si zapíšte jeho účel, umiestnenie a očakávanú veľkosť. Detail produktu môže potrebovať ostrú hlavnú fotografiu aj samostatný súbor na priblíženie. Dekorácia za formulárom takú potrebu spravidla nemá. Médiá, ktorých význam neviete vysvetliť, zvážte odstrániť.

Odlišujte súbor uložený v administrácii od toho, ktorý web naozaj posiela. Veľký originál v knižnici nemusí prekážať, ak z neho systém pripravuje vhodné varianty. Malý náhľad v editore naopak nič nehovorí o sieťovom prenose. Od vývojára si vyžiadajte adresu načítaného obrázka, jeho rozmery, veľkosť prenosu a čas začatia požiadavky.

Na úvod vyberte domovskú stránku, jednu službu, detail produktu a dlhší článok. Je to praktický pracovný výber, nie štatisticky reprezentatívny audit. Zahrňte aj stránku, na ktorú redakcia pravidelne pridáva fotografie. Ukáže sa tak, či pravidlá fungujú po odovzdaní projektu, alebo iba na starostlivo pripravenej ukážke. Zistenia uložte tak, aby ste rovnaký výber vedeli neskôr zopakovať.

02Formát voľte podľa obsahu, nie podľa prípony

Pri fotografii porovnajte AVIF a WebP. Pri logu či jednoduchej ikone začnite vektorovým SVG. Zachovanie presných hrán alebo pixelov môže vyžadovať bezstratový export. Žiadny formát nie je automaticky najmenší pre každý motív, nástroj a nastavenie kvality. Tabuľka pomôže pri prvom rozhodnutí, výsledný súbor však musí prejsť vizuálnou kontrolou.

WebP podporuje stratovú aj bezstratovú kompresiu a priehľadnosť. AVIF je ďalšou možnosťou úsporného rastrového obrazu. Z ukážok iných autorov nevyvodzujte garantovanú úsporu pre vlastnú fotobanku. Ušetrené kilobajty pomáhajú len vtedy, keď stále vidieť povrch materiálu, kresbu výrobku a detail dôležitý pri nákupe.

SVG opisuje tvary a krivky. Zložitá ilustrácia však môže byť veľká a náročná na vykreslenie. Previesť fotografiu na rozsiahlu vektorovú mozaiku preto nie je rozumný cieľ. PNG používa bezstratovú kompresiu, no samotná priehľadnosť nie je dôvod posielať každú fotografiu v PNG. JPEG zostáva použiteľný pre fotografie, napríklad ak ho potrebuje nadväzujúci systém.

03Kompresiu schvaľujte na skutočných záberoch

Uchovajte kvalitný originál a všetky varianty vytvárajte z neho. Opakovaným ukladaním už stratovo komprimovaného obrázka môžete ďalej zhoršovať jeho kvalitu. Najskôr rozhodnite o výreze a rozmeroch, potom o kompresii. Odstrániť nepotrebné pixely ešte pred exportom je rozumnejšie než ich za každú cenu tlačiť do menšieho súboru.

Vyberte náročné motívy: tvár, lístie, tmavý prechod, jemnú textúru a snímku rozhrania s drobným textom. Exportované varianty si prezrite v cieľovej veľkosti aj pri priblížení. Nastavenie „kvalita 80“ neznamená rovnakú kvalitu v rôznych formátoch a nástrojoch. Dodávateľovi radšej ukážte konkrétny detail, ktorý musí zostať rozpoznateľný.

Produktový katalóg môže potrebovať iné nastavenie než portréty tímu. Pre jednotlivé typy obsahu spíšte stručné pravidlá a uložte schválené vzory. Limit veľkosti súboru používajte ako podnet na kontrolu. Jediná povinná hranica pre všetky obrázky môže viesť k rozmazaným návodom, zatiaľ čo nepotrebná dekorácia sa do nej bez problémov zmestí. Rozhoduje účel a kontext stránky.

04Srcset a sizes zabezpečia vhodnú veľkosť

Fotografia široká 3000 pixelov nemusí byť vhodná pre každú kartu na telefóne. Pripravte viac rozmerových variantov toho istého motívu. Srcset opisuje dostupné šírky a sizes očakávanú šírku v rozložení stránky. Prehliadač si vyberá podľa podmienok zariadenia. Popisná syntax responzívnych obrázkov ponúka možnosti, neurčuje vždy jeden povinný súbor.

Ilustračná ukážka počíta so stĺpcom širokým najviac 680 CSS pixelov a s celkovým bočným odsadením 32 pixelov na menšom displeji. Všetky tri súbory musia existovať a mať pomer strán 3:2. V skutočnej šablóne nastavte sizes podľa jej rozloženia. Ide o hlavný obrázok, preto sa jeho načítanie neodkladá.

<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="Stolár kontroluje povrch dreveného stola v dielni"
  style="display:block;width:100%;max-width:680px;height:auto">

Označenia 480w, 960w a 1440w musia sedieť so skutočnými rozmermi súborov. MDN vysvetľuje prepojenie srcset a sizes. Displej s vysokou hustotou bodov môže potrebovať viac obrazových pixelov, než obrázok zaberá v CSS. Kontrolujte vybraný súbor aj jeho vzhľad. Zmena šírky okna na notebooku sama osebe nie je úplný test telefónu.

05Picture rieši odlišný formát aj výrez

Responzívna veľkosť a úprava kompozície sú dve rôzne úlohy. Pri prvej zostáva motív rovnaký a mení sa rozlíšenie. Pri druhej potrebuje telefón napríklad tesnejší výrez, aby tvár alebo výrobok nezanikli v širokom zábere. Na taký výber slúži picture so zdrojmi. Vnútri zostáva img s použiteľnou základnou adresou a alternatívnym textom.

Ak ponúkate AVIF aj WebP, nastavte zodpovedajúce typy zdrojov a overte náhradný variant. Samotné pripravené súbory nezaručujú správny HTML výstup. Častou chybou je nový výrez s popisom, ktorý ešte opisuje pôvodnú fotografiu. Ak sa medzi zariadeniami mení pomer strán, aj rezervované miesto musí zodpovedať príslušnému rozloženiu.

CSS object-fit upravuje zobrazenie v rámčeku. Vizuálne orezanie veľkej fotografie však samo nezmenší prenášaný súbor. Pri zložitejšom motíve pripravte osobitný výrez, aby automatické orezanie zo stredu neskrylo podstatný detail. Na produktovej karte napríklad nesmie zmiznúť časť výrobku, podľa ktorej zákazník rozlišuje varianty.

06Hlavný obrázok nesmie čakať na lazy loading

Largest Contentful Paint, teda LCP, sleduje vykreslenie najväčšieho relevantného obrazového alebo textového prvku vo viditeľnej časti stránky. Na rôznych zariadeniach to nemusí byť rovnaký prvok. Najskôr si overte vlastný web. Ak ide o hlavnú fotografiu, web.dev výslovne odporúča neodkladať ju lazy loadingom.

Prehliadač má adresu dôležitého obrázka nájsť čo najskôr, ideálne už v počiatočnom HTML. Ak ju dostane až po stiahnutí a spustení viacerých skriptov, malá veľkosť súboru nevyrieši celé čakanie. Pozrite sa na sieťovú časovú os: kedy požiadavka začala, ako dlho trval prenos a kedy sa obrázok skutočne zobrazil.

Fetch priority umožňuje naznačiť prehliadaču dôležitosť zdroja. Vysokú prioritu prideľujte cielene pravdepodobnému LCP obrázku, nie celej galérii. Preload má zmysel pri konkrétnom probléme s neskorým objavením zdroja. Musí sa zhodovať so skutočne použitým variantom, inak môže spôsobiť zbytočný prenos. Každú úpravu overte na výslednom sieťovom zázname.

07Odložte vzdialené obrázky a rezervujte im miesto

Pre fotografie hlbšie v článku je vhodným východiskom loading="lazy". Natívne odkladanie obrázkov prenecháva načasovanie prehliadaču. Ten môže súbor stiahnuť ešte pred jeho vstupom do viditeľnej oblasti. Nesľubujte preto presnú hranicu ani nulový prenos všetkého, čo návštevník zatiaľ nevidí.

Každému obrázku ponechajte rozmery alebo iný spoľahlivý spôsob rezervácie priestoru. Po načítaní fotografie nemá čitateľ stratiť riadok textu či omylom stlačiť posunuté tlačidlo. Skúšajte pomalšie pripojenie, pretože rýchla lokálna kontrola môže posun ľahko skryť. Zástupná plocha musí zodpovedať výslednému pomeru strán.

Dlhšia galéria potrebuje samostatné preverenie prvého viditeľného snímku, ďalších záberov, otvorenia detailu a návratu. Nepridávajte knižnicu iba kvôli funkcii, ktorú rieši natívny atribút. Ak vlastné riešenie potrebujete, skontrolujte klávesnicu, pomalý či vypnutý JavaScript a dostupné základné odkazy. Odloženie nemá znamenať, že sa obsah v niektorých situáciách vôbec nezobrazí.

08Alternatívny text a popis pod obrázkom majú inú úlohu

Alternatívny text zastupuje význam obrázka v konkrétnom kontexte. Pri výrobku môže opísať vyhotovenie alebo viditeľný detail. Dekoratívny obrázok môže mať prázdny alt. Ak je obrázok jediným obsahom odkazu, treba vysvetliť účel odkazu. Pomôže rozhodovací strom W3C pre alternatívny text.

Popis pod obrázkom vidia všetci a môže objasniť zdroj, okolnosti alebo význam zachytenej situácie. Nevypĺňajte obe polia kópiou kľúčových slov. Zložitý diagram potrebuje viac než krátku vetu: W3C odporúča aj podrobnejší textový ekvivalent. Tabuľka či slovné vysvetlenie pomôžu aj čitateľovi na malom displeji.

Podstatnú cenu, podmienku ani postup nenechávajte iba v obrázku. Text v HTML sa dá zväčšiť, označiť a lepšie prispôsobiť rozloženiu. Pri slovenskej verzii upravte aj texty vložené do grafiky, nielen okolité odseky. Ku schváleniu média patrí pôvod a oprávnenie na použitie. Malý a rýchly súbor ešte neznamená, že ho firma môže zverejniť.

09Video navrhnite ako samostatnú časť stránky

Krátka produktová ukážka môže vysvetliť pohyb lepšie než fotografie. Nemusí sa však spúšťať pri každej návšteve. Začnite kvalitným náhľadom, zrozumiteľným tlačidlom prehrávania a prehrávačom ovládateľným klávesnicou. Zvážte, či návštevník potrebuje celé video okamžite, alebo mu najskôr pomôže krátky textový súhrn.

MDN opisuje preload ako odporúčanie pre prehliadač. Hodnota none vyjadruje, že video sa nemá načítavať vopred, nejde však o univerzálnu záruku sieťového správania. Autoplay potrebuje dáta na prehrávanie. Aktuálny prehľad web.dev už opisuje rozširujúcu sa podporu loading="lazy" pre video. Overte cieľové prehliadače aj správanie bez podpory.

Externý prehrávač môže ešte pred spustením pridať skripty a ďalšie pripojenia. Zvážte jednoduchý náhľad, ktorý ho načíta až po aktivácii, a zmerajte skutočný rozdiel. Titulky majú zachytiť reč aj dôležité zvuky; W3C ich odlišuje od samotného jazykového prekladu. Automatický prepis pred zverejnením opravte, najmä pri názvoch produktov, menách a odborných pojmoch.

10Modelový príklad: stránka so siedmimi fotografiami

Predstavte si stránku služby s jednou hlavnou fotografiou a šiestimi realizáciami nižšie. Predpokladajme, že pôvodne sa všetkých sedem súborov načíta hneď a každý má 900 kB. Počiatočný prenos obrázkov je 7 × 900 = 6300 kB. Používame desatinné kilobajty a pre jednoduchosť nepočítame hlavičky, vyrovnávaciu pamäť ani ostatné súbory stránky.

Navrhovaný variant má hlavný snímok s veľkosťou 180 kB a šesť menších fotografií po 90 kB. Navyše predpokladáme, že vzdialené fotografie prehliadač pri prvom zobrazení ešte nenačíta. Počiatočný obrazový prenos je 180 kB. Po prezretí všetkých fotografií sa prenesie 180 + 6 × 90 = 720 kB. Vstupy sú zvolené na vysvetlenie princípu, nepredstavujú namerané výsledky kompresie.

Výpočet oddeľuje dva účinky. Menšie súbory znižujú celkový prenos, odklad mení jeho načasovanie. Nehovorí, o koľko sa zlepší LCP ani počet objednávok. Hlavný obrázok môže stále čakať na server alebo skript. Až test ukáže, či návštevník uvidí dôležitý obsah skôr a či menšie fotografie zachovali svoj význam.

11Pri nasadení overte celú cestu od CMS po prehliadač

Automatické prevody v CMS, optimalizácia vo frameworku a obrázková CDN môžu pomôcť. Určite však, ktorá vrstva uchováva originál, aké rozmery vytvára a kedy. Niekoľko nezávislých prevodov za sebou sťažuje kontrolu kvality aj hľadanie chyby. Po zmene originálu overte, či sa aktualizovali všetky odvodené varianty.

Ak sa pod jednou adresou doručujú rôzne formáty, musí fungovať správne vyjednávanie a kľúč vyrovnávacej pamäte. Inak môže používateľ dostať nevhodný súbor. Pri dlhom uchovávaní verejných obrázkov pomáha verzovanie adries; MDN vysvetľuje pravidlá HTTP cache. Obnovenie stránky na vlastnom počítači ešte nedokazuje, čo uvidia ostatní.

Skontrolujte odpoveď servera, typ obsahu, prístup, veľké a malé písmená v adresách aj jazykové verzie. Žiadny zdroj zo srcset nesmie vracať chybu alebo HTML namiesto obrázka. Google odporúča dostupné obrázky v bežnom img so src. Obsah závislý od zložitej interakcie môže zbytočne komplikovať dohľadateľnosť. Overte aj náhľad pri zdieľaní odkazu, ktorý môže používať iný obrázok.

12Výsledok preverte a odovzdajte pravidlá redakcii

Porovnávajte rovnaké stránky, zariadenia, pripojenie a stav cache. Prvá návšteva a opakované otvorenie sú dva odlišné scenáre. V sieťovom paneli Chrome DevTools sledujte skutočné požiadavky a načasovanie. Osobitne kontrolujte vzhľad, stabilitu rozloženia a galériu. Menší počet bajtov neospravedlňuje nečitateľný návod.

• Hlavný obrázok prichádza včas a neodkladá ho plošný lazy loading.
• Vybraný rozmer zodpovedá rozloženiu aj detailom na bežnom telefóne.
• Obrázky majú rezervovaný priestor, správne výrezy a vhodné alternatívne texty.
• Galéria aj video sa dajú ovládať klávesnicou a fungujú na pomalšom pripojení.
• Adresy všetkých variantov fungujú a zmena sa prejaví aj cez cache.
• Redakcia má originály, schválené vzory a jasný postup pre nové médiá.

Rozdeľte zodpovednosť konkrétne: redaktor volí obsah a význam popisu, dizajnér schvaľuje výrez a vývojár overuje doručenie. Pri zmene šablóny znovu preverte sizes a načasovanie. Pri širšom projekte nadväzuje postup tvorby webu na mieru. Dodávateľovi ukážte skutočné stránky a fotografie. Všeobecné zadanie „zmenšiť obrázky“ neposkytuje dostatočné kritérium úspechu.

13Časté otázky

14Zdroje a metodika

Odkazy vedú na dokumentáciu MDN, web.dev, Chrome DevTools, Google Search Central a W3C WAI overenú 28. októbra 2026. Vlastnosti formátov dopĺňa prehľad obrazových typov MDN. Pracovný postup a kontrolný zoznam sú redakčným spracovaním týchto technických princípov.

Nevychádzame z vlastného porovnávacieho merania encoderov ani z merania klientského webu. Príklad siedmich fotografií používa vopred zvolené vstupy. Pred nasadením overte podporu použitých funkcií a výsledný HTML výstup. Samotné nastavenie v editore nie je dôkazom správneho doručenia.