Optimalizácia obrázkov: AVIF a WebP 2026

Kompletný sprievodca optimalizáciou obrázkov pre web: Moderné formáty, lazy loading a stratégie pre bleskovo rýchly LCP v roku 2026

Obrázky sú neoddeliteľnou súčasťou moderného webu — dodávajú stránkam vizuálnu príťažlivosť, komunikujú emócie a pomáhajú používateľom pochopiť obsah rýchlejšie než samotný text. Lenže je tu aj druhá strana mince. Obrázky sú najväčšou výkonnostnou záťažou takmer každej webovej stránky. Podľa HTTP Archive tvoria v roku 2026 v priemere viac ako 50 % celkovej veľkosti stránky, pričom mediánová webová stránka načítava vyše 900 kB obrazových dát. Na mobiloch s pomalším pripojením sa táto záťaž prejavuje ešte výraznejšie.

Prečo by vás to malo zaujímať? Pretože Google od roku 2021 používa Core Web Vitals ako faktor hodnotenia vo vyhľadávaní a najvýznamnejšia z týchto metrík — Largest Contentful Paint (LCP) — priamo závisí od toho, ako rýchlo sa načíta a vykreslí najväčší viditeľný prvok na stránke. A v približne 70–80 % prípadov je týmto prvkom práve obrázok.

Takže áno, optimalizácia obrázkov nie je len technická záležitosť — je to priamy faktor ovplyvňujúci vaše SEO pozície, mieru konverzií a spokojnosť používateľov.

Dobrou správou je, že v roku 2026 máme k dispozícii viac nástrojov a techník než kedykoľvek predtým. Od moderných formátov ako AVIF a WebP, cez natívne lazy loading, atribút fetchpriority, až po obrazové CDN s automatickou optimalizáciou. Poďme si ich prejsť jeden po druhom.

Moderné obrazové formáty: AVIF, WebP a JPEG XL

Výber správneho obrazového formátu je úplne základný krok. Tradičné formáty JPEG a PNG stále dominujú na webe, ale moderné alternatívy ponúkajú dramaticky lepšiu kompresiu pri zachovaní vizuálnej kvality. A keď poviem „dramaticky", myslím tým naozaj veľké rozdiely.

AVIF — kráľ kompresie

AVIF (AV1 Image File Format) je v roku 2026 bezpochyby najefektívnejším obrazovým formátom pre web. Je založený na video kodeku AV1 a ponúka naozaj pôsobivé výsledky:

Až o 50 % menšie súbory v porovnaní s JPEG pri rovnakej vizuálnej kvalite
O 20–25 % menšie súbory než WebP
Podpora transparencie (alfa kanál), HDR a širokého farebného gamutu
Podporuje stratovú aj bezstratovú kompresiu

Podpora v prehliadačoch je na vynikajúcej úrovni — AVIF podporuje približne 93 % globálnych používateľov, vrátane Chrome, Firefox, Safari (od verzie 16.4) a Edge. Jedinou nevýhodou je pomalšie kódovanie, čo ho robí menej vhodným pre real-time generovanie, ale pre statické obrázky na webe je jednoducho ideálny.

WebP — spoľahlivý štandard

WebP od Googlu je už dlhšie štandardom modernej obrazovej kompresie na webe. Jeho výhody:

O 25–34 % menšie súbory než JPEG pri stratovej kompresii
O 26 % menšie súbory než PNG pri bezstratovej kompresii
Rýchlejšie dekódovanie než AVIF — čo je výhodné na slabších zariadeniach
Podpora animácií ako náhrada za GIF

S podporou približne 97 % prehliadačov je WebP v roku 2026 najbezpečnejšou voľbou ako primárny moderný formát. Aj keď AVIF ponúka lepšiu kompresiu, WebP zostáva vynikajúcim fallback formátom.

JPEG XL — budúcnosť s otáznikmi

JPEG XL (JXL) je technicky najpokročilejší formát so zaujímavými vlastnosťami:

Progresívne dekódovanie — obrázok sa zobrazuje postupne s rastúcou kvalitou
Bezstratová transkódia z JPEG — existujúce JPEG súbory je možné previesť na JXL a späť bez straty kvality
Natívna podpora HDR a širokého farebného gamutu
Výborná kompresia pre fotografie aj grafiku

Bohužiaľ, situácia s podporou v prehliadačoch zostáva komplikovaná. Chrome tento formát odstranil z experimentálnej podpory ešte v roku 2023 a zatiaľ ho nepridali späť. Safari ho podporuje od verzie 17, Firefox má experimentálnu podporu. Úprimne, pre produkčné nasadenie sa JPEG XL zatiaľ neodporúča ako primárny formát — no je to technológia, ktorú sa oplatí sledovať.

Implementácia s elementom <picture>

Element <picture> umožňuje servírovať rôzne formáty s automatickým fallbackom. Prehliadač si jednoducho vyberie prvý formát, ktorý podporuje:

<picture>
  <!-- AVIF — najlepšia kompresia, podpora ~93 % -->
  <source
    type="image/avif"
    srcset="hero-image.avif"
  />

  <!-- WebP — výborná kompresia, podpora ~97 % -->
  <source
    type="image/webp"
    srcset="hero-image.webp"
  />

  <!-- JPEG — univerzálny fallback -->
  <img
    src="hero-image.jpg"
    alt="Popis obrázka pre prístupnosť"
    width="1200"
    height="675"
  />
</picture>

Vždy uvádzajte atribúty width a height na elemente <img>. Prehliadač ich využíva na výpočet pomeru strán a rezerváciu priestoru ešte pred načítaním obrázka, čím predchádza nežiaducim posunom rozloženia (Cumulative Layout Shift — CLS). Toto je jednoduchá vec, ktorú veľa ľudí prehliadne, no jej dopad na UX je obrovský.

Responzívne obrázky so srcset a sizes

Servírovať rovnaký obrázok o šírke 2000 px na mobilné zariadenie so šírkou 375 px je obrovské plytvanie šírkou pásma. Atribúty srcset a sizes umožňujú prehliadaču vybrať si optimálnu veľkosť obrázka podľa zariadenia.

Ako funguje srcset s deskriptormi šírky

Atribút srcset definuje zoznam variantov obrázka s ich skutočnou šírkou v pixeloch (deskriptor w). Prehliadač potom na základe šírky viewportu, hustoty pixelov displeja a atribútu sizes vyberie najvhodnejší variant:

<img
  src="product-800.jpg"
  srcset="
    product-400.jpg   400w,
    product-800.jpg   800w,
    product-1200.jpg 1200w,
    product-1600.jpg 1600w,
    product-2000.jpg 2000w
  "
  sizes="
    (max-width: 640px) 100vw,
    (max-width: 1024px) 50vw,
    33vw
  "
  alt="Produktová fotografia"
  width="2000"
  height="1333"
/>

Vysvetlenie atribútu sizes

Atribút sizes informuje prehliadač o tom, akú šírku bude obrázok zaberať v rozložení stránky. V príklade vyššie:

Na obrazovkách do 640 px šírky zaberá obrázok 100 % šírky viewportu (100vw)
Na obrazovkách do 1024 px zaberá 50 % šírky viewportu (50vw)
Na väčších obrazovkách zaberá 33 % šírky viewportu (33vw)

Prehliadač pomocou týchto informácií a znalosti hustoty pixelov displeja vypočíta, aký veľký variant obrázka skutočne potrebuje. Napríklad na mobile so šírkou 375 px a hustotou 2x bude prehliadač hľadať obrázok o šírke cca 750 px a vyberie variant product-800.jpg.

Art direction s elementom <picture>

Niekedy nestačí len zmeniť rozlíšenie — na rôznych zariadeniach chcete zobraziť úplne iný orezový výrez obrázka. Na to slúži art direction s elementom <picture> a atribútom media:

<picture>
  <!-- Na mobilných zariadeniach — vertikálny výrez -->
  <source
    media="(max-width: 767px)"
    srcset="
      hero-portrait-400.avif 400w,
      hero-portrait-800.avif 800w
    "
    sizes="100vw"
    type="image/avif"
  />

  <!-- Na tabletoch — štvorcový výrez -->
  <source
    media="(max-width: 1023px)"
    srcset="
      hero-square-600.avif  600w,
      hero-square-1200.avif 1200w
    "
    sizes="100vw"
    type="image/avif"
  />

  <!-- Na desktopoch — široký horizontálny záber -->
  <source
    srcset="
      hero-wide-1200.avif 1200w,
      hero-wide-2000.avif 2000w
    "
    sizes="100vw"
    type="image/avif"
  />

  <img
    src="hero-wide-1200.jpg"
    alt="Hlavný banner stránky"
    width="2000"
    height="800"
  />
</picture>

Tento prístup je obzvlášť dôležitý pre hero obrázky a bannery. Výrez na mobilnom zariadení jednoducho musí byť odlišný od desktopovej verzie, aby zostal vizuálne účinný — inak sa vám stane, že na mobile nikto neuvidí to podstatné.

Atribút fetchpriority: Prioritizácia LCP obrázkov

Nie všetky obrázky na stránke sú rovnako dôležité. Atribút fetchpriority umožňuje explicitne povedať prehliadaču, ktoré zdroje by mal načítať prednostne a ktoré môžu pokojne počkať. Je súčasťou špecifikácie Fetch Priority API a od roku 2025 ho podporujú všetky moderné prehliadače.

Kedy použiť fetchpriority="high"

Atribút fetchpriority="high" by ste mali použiť na obrázok, ktorý je vaším LCP elementom — typicky hero obrázok alebo hlavná produktová fotografia. Tým poviete prehliadaču, aby tomuto obrázku priradil najvyššiu prioritu sťahovania:

<!-- LCP obrázok — najvyššia priorita -->
<img
  src="hero-banner.avif"
  alt="Hlavný banner"
  width="1920"
  height="1080"
  fetchpriority="high"
/>

Reálne výsledky: Prípadová štúdia Etsy

Spoločnosť Etsy implementovala fetchpriority="high" na svoje LCP obrázky na stránkach s výpismi produktov a zaznamenala 4% zlepšenie LCP v reálnych podmienkach. To je pomerne pozoruhodné, pretože ide o jednu jednoduchú zmenu atribútu v HTML — žiadne zložité refaktorovanie, žiadne nové závislosti. Google tím pre Chrome Web Platform potvrdil, že podobné zlepšenia v rozsahu 2–8 % sú typické naprieč rôznymi webmi.

Pravidlá pre správne použitie fetchpriority

Nikdy nekombinujte fetchpriority="high" s loading="lazy". Tieto dva atribúty si priamo protirečia — jeden hovorí „načítaj čo najrýchlejšie", druhý hovorí „počkaj". Prehliadač síce takúto kombináciu zvládne (lazy loading vyhrá), ale je to jasný signál chyby v kóde.

Používajte fetchpriority="low" pre obrázky, ktoré sú pod záhybom alebo nie sú okamžite viditeľné:

<!-- Galéria obrázkov pod záhybom -->
<div class="gallery">
  <img
    src="gallery-01.webp"
    alt="Fotografia z galérie 1"
    width="400"
    height="300"
    fetchpriority="low"
    loading="lazy"
  />
  <img
    src="gallery-02.webp"
    alt="Fotografia z galérie 2"
    width="400"
    height="300"
    fetchpriority="low"
    loading="lazy"
  />
</div>

Ako pravidlo platí: na stránke by mal byť maximálne jeden obrázok s fetchpriority="high" — váš LCP obrázok. Ak označíte príliš veľa obrázkov ako vysokoprioritných, efekt sa jednoducho stráca.

Lazy loading: Natívne aj pokročilé prístupy

Lazy loading je technika, pri ktorej sa obrázky načítavajú až vtedy, keď sa používateľ k nim priblíži scrollovaním. Tým sa výrazne znižuje objem dát načítaných pri prvotnom zobrazení stránky a zrýchľuje sa LCP aj Time to Interactive.

Natívne lazy loading s loading="lazy"

Najjednoduchší spôsob implementácie? Natívny atribút loading="lazy", ktorý v roku 2026 podporujú všetky moderné prehliadače:

<img
  src="article-photo.webp"
  alt="Ilustračná fotografia k článku"
  width="800"
  height="600"
  loading="lazy"
/>

Prehliadač automaticky odloží načítanie obrázka, kým sa nepriblíži k viditeľnej oblasti viewportu. Presná vzdialenosť, pri ktorej sa obrázok začne načítavať, závisí od prehliadača a typu pripojenia — na pomalších pripojeniach sa obrázky začnú načítavať skôr, čo je celkom šikovné riešenie.

Kritické pravidlo: Nikdy nepridávajte lazy loading na LCP obrázok

Toto je jedna z najčastejších chýb pri optimalizácii obrázkov a osobne som ju videl na desiatke projektov. Ak pridáte loading="lazy" na obrázok, ktorý je vaším LCP elementom, prehliadač odloží jeho načítanie a váš LCP sa dramaticky zhorší. Podľa dát z Chrome UX Report má táto chyba za následok zhoršenie LCP o 0,4–1,2 sekundy.

Lighthouse od verzie 12 tento anti-pattern aktívne detekuje a varuje pred ním.

Pravidlo je jednoduché: obrázky v hornej časti stránky nikdy nemajú mať loading="lazy". Tento atribút patrí výhradne na obrázky, ku ktorým sa používateľ musí doscrollovať.

Pokročilý lazy loading s Intersection Observer API

Pre prípady, keď potrebujete jemnejšiu kontrolu — napríklad vlastnú vzdialenosť spúšťania, animácie pri zobrazení alebo sledovanie analytiky — použite Intersection Observer API:

<img
  class="lazy-img"
  data-src="photo-fullsize.avif"
  src="photo-placeholder-lqip.jpg"
  alt="Fotografia s lazy loadingom"
  width="800"
  height="600"
/>

<script>
document.addEventListener('DOMContentLoaded', () => {
  const lazyImages = document.querySelectorAll('.lazy-img');

  const imageObserver = new IntersectionObserver(
    (entries, observer) => {
      entries.forEach((entry) => {
        if (entry.isIntersecting) {
          const img = entry.target;
          // Nahradenie placeholder obrázka skutočným zdrojom
          img.src = img.dataset.src;

          // Ak existuje srcset v data atribúte
          if (img.dataset.srcset) {
            img.srcset = img.dataset.srcset;
          }

          img.classList.add('lazy-img--loaded');
          observer.unobserve(img);
        }
      });
    },
    {
      // Začať načítanie 200px pred vstupom do viewportu
      rootMargin: '200px 0px',
      threshold: 0.01,
    }
  );

  lazyImages.forEach((img) => imageObserver.observe(img));
});
</script>

Hodnota rootMargin: '200px 0px' znamená, že obrázok sa začne načítavať 200 px predtým, než sa dostane do viditeľnej oblasti. To poskytuje dostatočný čas na stiahnutie.

Pre väčšinu scenárov je však natívne loading="lazy" úplne postačujúce a nepotrebujete žiadny JavaScript. Intersection Observer používajte iba vtedy, keď natívne riešenie naozaj nespĺňa vaše požiadavky.

Preloading kritických obrázkov

Zatiaľ čo lazy loading odkladá načítanie nepodstatných obrázkov, preloading robí presný opak — hovorí prehliadaču, aby začal sťahovať kritický obrázok čo najskôr, ešte predtým, než na neho narazí v HTML. To je obzvlášť užitočné pre LCP obrázky referencované v CSS (napríklad background-image) alebo načítavané JavaScriptom.

Základný preload pre LCP obrázok

<head>
  <!-- Preload LCP obrázka — prehliadač ho začne sťahovať okamžite -->
  <link
    rel="preload"
    as="image"
    href="hero-banner.avif"
    type="image/avif"
    fetchpriority="high"
  />
</head>

Atribút type je dôležitý pri preloadovaní moderných formátov — ak prehliadač nepodporuje daný formát, preload jednoducho ignoruje a nebude plytvať šírkou pásma.

Responzívny preload s imagesrcset a imagesizes

Ak váš LCP obrázok používa responzívne varianty, musíte v preloade použiť atribúty imagesrcset a imagesizes, aby prehliadač vedel vybrať správny variant:

<head>
  <!-- Responzívny preload pre hero obrázok -->
  <link
    rel="preload"
    as="image"
    imagesrcset="
      hero-400.avif   400w,
      hero-800.avif   800w,
      hero-1200.avif 1200w,
      hero-1920.avif 1920w
    "
    imagesizes="100vw"
    type="image/avif"
    fetchpriority="high"
  />
</head>

Dôležitý tip: Preloadujte maximálne 1–2 kritické zdroje. Nadmerné preloadovanie je kontraproduktívne, pretože zaberie šírku pásma iným zdrojom ako CSS alebo fonty. Prehliadač vás dokonca upozorní v konzole, ak preloaded zdroj nie je do 3 sekúnd použitý.

CSS content-visibility pre renderovací výkon

Vlastnosť content-visibility v CSS je jedna z najmenej známych, ale najúčinnejších techník na zlepšenie renderovacieho výkonu. Nesúvisí priamo so sťahovaním obrázkov, ale výrazne ovplyvňuje, ako rýchlo prehliadač vykreslí stránku. A upozorním vás — výsledky bývajú prekvapujúco dobré.

Ako funguje content-visibility: auto

Keď nastavíte content-visibility: auto na sekciu stránky, prehliadač preskočí renderovanie obsahu tejto sekcie, ak sa nachádza mimo viditeľnej oblasti. Nemusí vytvárať layout, paint ani compositing pre stovky elementov pod záhybom. Výsledok? Až 7-násobné zrýchlenie prvotného renderovania stránky.

<style>
  /* Sekcie pod záhybom s odloženým renderovaním */
  .section-below-fold {
    content-visibility: auto;
    contain-intrinsic-size: auto 500px;
  }

  /* Produktová mriežka s veľkým počtom položiek */
  .product-card {
    content-visibility: auto;
    contain-intrinsic-size: auto 350px;
  }

  /* Komentáre na blogu */
  .comments-section {
    content-visibility: auto;
    contain-intrinsic-size: auto 800px;
  }
</style>

<section class="hero">
  <!-- Hero sekcia — vždy sa renderuje okamžite -->
  <img src="hero.avif" alt="Hero" width="1920" height="1080" fetchpriority="high" />
</section>

<section class="section-below-fold">
  <h2>O nás</h2>
  <p>Obsah, ktorý sa renderuje až keď sa používateľ priblíži...</p>
  <img src="about-photo.webp" alt="O nás" width="800" height="600" loading="lazy" />
</section>

<section class="section-below-fold">
  <h2>Naše produkty</h2>
  <div class="product-grid">
    <!-- Produktové karty s content-visibility -->
  </div>
</section>

Pozor: content-visibility nezabraňuje sťahovaniu obrázkov

Tu je dôležitý detail, ktorý ľudia často prehliadnu. content-visibility: auto neovplyvňuje sieťové požiadavky. Obrázky v takejto sekcii sa stále začnú sťahovať, pretože prehliadač ich objaví pri parsovaní HTML. Ak chcete zabrániť aj sťahovaniu, musíte kombinovať content-visibility s loading="lazy" na obrázkoch.

Vlastnosť contain-intrinsic-size

Keď prehliadač preskočí renderovanie sekcie, potrebuje vedieť jej odhadovanú výšku, aby mohol správne vypočítať scrollbar a celkovú výšku stránky. Na to slúži contain-intrinsic-size. Kľúčové slovo auto pred hodnotou hovorí prehliadaču, aby si zapamätal skutočnú výšku po prvom vykreslení a použil ju pri opätovnom návrate k sekcii.

Podpora content-visibility je od septembra 2024 považovaná za Baseline — podporujú ju všetky moderné prehliadače vrátane Chrome, Firefox, Safari a Edge.

Obrazové CDN: Automatická optimalizácia na škále

Manuálna optimalizácia obrázkov je časovo náročná a (buďme úprimní) náchylná na chyby. Obrazové CDN automatizujú celý proces — od zmeny veľkosti, cez konverziu formátov, až po kompresiu — a to v reálnom čase na základe parametrov v URL.

Čo obrazové CDN robia

Automatická zmena veľkosti — generujú varianty obrázka pre rôzne zariadenia
Automatická konverzia formátov — servírujú AVIF, WebP alebo JPEG podľa podpory prehliadača (content negotiation cez hlavičku Accept)
Inteligentná kompresia — optimalizujú kvalitu s ohľadom na obsah obrázka
Globálna distribúcia — obrázky sa servírujú z najbližšieho edge servera
Caching — optimalizované varianty sa kešujú pre okamžité doručenie

Výsledkom je typicky 40–80 % zníženie veľkosti súborov bez akejkoľvek manuálnej práce.

Populárne riešenia v roku 2026

Cloudflare Images — integrované s Cloudflare CDN, výborný pomer cena/výkon
Imgix — výkonné API s viac ako 400 parametrami transformácie
Cloudinary — najkomplexnejšie riešenie s AI-poháňanou optimalizáciou
ImageKit — jednoduché nasadenie s globálnym CDN

Príklad URL-based transformácií

<!-- Cloudinary: automatický formát a kvalita -->
<img
  src="https://res.cloudinary.com/demo/image/upload/f_auto,q_auto,w_800/products/laptop.jpg"
  alt="Notebook"
  width="800"
  height="533"
/>

<!-- Imgix: responzívny obrázok s automatickou optimalizáciou -->
<img
  src="https://example.imgix.net/hero.jpg?auto=format,compress&w=800"
  srcset="
    https://example.imgix.net/hero.jpg?auto=format,compress&w=400   400w,
    https://example.imgix.net/hero.jpg?auto=format,compress&w=800   800w,
    https://example.imgix.net/hero.jpg?auto=format,compress&w=1200 1200w,
    https://example.imgix.net/hero.jpg?auto=format,compress&w=1920 1920w
  "
  sizes="100vw"
  alt="Hero obrázok"
  width="1920"
  height="1080"
/>

<!-- ImageKit: automatický formát s transformačnými parametrami -->
<img
  src="https://ik.imagekit.io/demo/tr:w-800,f-auto,q-80/products/camera.jpg"
  alt="Fotoaparát"
  width="800"
  height="600"
/>

Parameter f_auto alebo auto=format je kľúčový — hovorí CDN, aby automaticky servírovalo najefektívnejší formát na základe hlavičky Accept prehliadača. Moderný Chrome tak dostane AVIF, staršie Safari dostane WebP a veľmi starý prehliadač dostane JPEG.

Obrazové CDN sú obzvlášť výhodné pre e-commerce stránky a mediálne portály s tisíckami obrázkov, kde by manuálna optimalizácia bola prakticky nemožná.

Techniky kompresie a nástroje

Ak nepoužívate obrazové CDN, potrebujete obrázky optimalizovať pri build čase alebo pred nahraním na server. Našťastie, v roku 2026 máme na to niekoľko výborných nástrojov.

Sharp — výkonná Node.js knižnica

Sharp je najpopulárnejšia knižnica na spracovanie obrázkov v ekosystéme Node.js. Je postavená na libvips a ponúka výborný výkon aj pri veľkom objeme obrázkov:

// optimizeImages.mjs — build-time skript na optimalizáciu obrázkov
import sharp from 'sharp';
import { readdir, mkdir } from 'node:fs/promises';
import { join, parse } from 'node:path';

const INPUT_DIR = './src/images';
const OUTPUT_DIR = './dist/images';

// Konfigurácia veľkostí pre responzívne obrázky
const SIZES = [400, 800, 1200, 1600, 2000];

// Odporúčané nastavenia kvality pre jednotlivé formáty
const FORMAT_CONFIG = {
  avif: { quality: 65, effort: 6 },     // AVIF: 60-70 kvalita je optimálna
  webp: { quality: 80, effort: 5 },     // WebP: 75-85 kvalita je optimálna
  jpeg: { quality: 82, mozjpeg: true },  // JPEG: mozjpeg pre lepšiu kompresiu
};

async function optimizeImage(inputPath) {
  const { name } = parse(inputPath);
  const image = sharp(inputPath);
  const metadata = await image.metadata();

  const tasks = [];

  for (const width of SIZES) {
    // Preskočiť veľkosti väčšie ako originál
    if (width > metadata.width) continue;

    for (const [format, config] of Object.entries(FORMAT_CONFIG)) {
      const outputPath = join(OUTPUT_DIR, `${name}-${width}.${format}`);

      tasks.push(
        sharp(inputPath)
          .resize(width, null, {
            withoutEnlargement: true,
            kernel: sharp.kernel.lanczos3,
          })
          .toFormat(format, config)
          .toFile(outputPath)
          .then((info) => {
            console.log(
              `${name}-${width}.${format}: ${(info.size / 1024).toFixed(1)} kB`
            );
          })
      );
    }
  }

  await Promise.all(tasks);
}

async function processAllImages() {
  await mkdir(OUTPUT_DIR, { recursive: true });
  const files = await readdir(INPUT_DIR);
  const imageFiles = files.filter((f) =>
    /\.(jpe?g|png|tiff?)$/i.test(f)
  );

  console.log(`Spracovávam ${imageFiles.length} obrázkov...`);
  const startTime = Date.now();

  await Promise.all(
    imageFiles.map((file) => optimizeImage(join(INPUT_DIR, file)))
  );

  const duration = ((Date.now() - startTime) / 1000).toFixed(1);
  console.log(`Hotovo za ${duration}s`);
}

processAllImages();

Odporúčané nastavenia kvality

Nastavenia kvality kompresie sú vždy kompromisom medzi veľkosťou súboru a vizuálnou kvalitou. Na základe rozsiahlych testov a skúseností komunity v roku 2026 platia tieto odporúčania:

AVIF: kvalita 60–70 (nižšie hodnoty sú prijateľné vďaka vynikajúcej kompresii)
WebP: kvalita 75–85 (dobrý balans medzi veľkosťou a kvalitou)
JPEG (mozjpeg): kvalita 78–85 (mozjpeg kódovanie je efektívnejšie než štandardný JPEG)
PNG: používajte len pre obrázky s transparenciou a ostrými hranami (logá, ikony) — pre fotografie vždy preferujte stratové formáty

Ďalšie užitočné nástroje

Squoosh (squoosh.app) — webová aplikácia od tímu Google Chrome na vizuálne porovnanie kompresie. Výborná na jednorazovú optimalizáciu a experimentovanie s nastaveniami
ImageOptim (macOS) — desktopová aplikácia na bezstratovú optimalizáciu JPEG a PNG súborov. Automaticky odstraňuje EXIF dáta a optimalizuje kompresnú tabuľku
svgo — Node.js nástroj na optimalizáciu SVG súborov, ktorý dokáže znížiť veľkosť SVG o 30–60 %

Build-time vs. runtime optimalizácia

Existujú dva hlavné prístupy k optimalizácii obrázkov:

Build-time optimalizácia — obrázky sa optimalizujú počas build procesu (napr. vo Webpack, Vite, Next.js). Výhoda: žiadna záťaž na serveri v produkcii. Nevýhoda: dlhší build a nemožnosť dynamického prispôsobenia
Runtime optimalizácia — obrázky sa optimalizujú na požiadanie obrazovým CDN alebo serverovým middleware. Výhoda: automatické prispôsobenie zariadeniu. Nevýhoda: prvý request je pomalší (kým sa vytvorí kešovaný variant)

Pre väčšinu projektov je kombinácia oboch ideálna: kritické hero obrázky sa optimalizujú pri build čase pre predvídateľný výkon, zatiaľ čo dynamický obsah (používateľské nahrávky, produktové fotografie) sa optimalizuje cez CDN. V praxi to funguje skvele.

Praktický checklist: Optimalizácia LCP obrázka krok za krokom

Tak, teraz keď poznáte všetky techniky, poďme ich spojiť do praktického procesu. Postupujte podľa tohto checklistu a váš LCP obrázok bude optimalizovaný na maximum:

Identifikujte svoj LCP element
Použite Chrome DevTools (záložka Performance) alebo PageSpeed Insights na identifikáciu, ktorý element je vaším LCP. Nezabudnite, že LCP sa líši pre mobilné a desktopové zariadenia.
Konvertujte do moderných formátov
Vytvorte AVIF a WebP verziu obrázka. Použite element <picture> s fallback reťazcom: AVIF → WebP → JPEG.
Vytvorte responzívne varianty
Vygenerujte varianty pre rôzne šírky (napr. 400, 800, 1200, 1600, 2000 px). Implementujte srcset a sizes atribúty.
Pridajte fetchpriority="high"
Na LCP obrázok pridajte fetchpriority="high". Uistite sa, že žiadny iný obrázok na stránke nemá rovnakú prioritu.
Pridajte preload do <head>
Pre LCP obrázok pridajte <link rel="preload"> s príslušnými atribútmi imagesrcset a imagesizes.
Overte, že LCP obrázok NEMÁ loading="lazy"
Skontrolujte, že na LCP obrázku nie je atribút loading="lazy". Toto je najčastejšia chyba — a vy ju nechcete robiť.
Pridajte loading="lazy" na ostatné obrázky
Všetky obrázky pod záhybom by mali mať loading="lazy" a voliteľne fetchpriority="low".
Nastavte explicitné rozmery
Uistite sa, že každý <img> element má atribúty width a height pre prevenciu CLS.
Aplikujte content-visibility na sekcie pod záhybom
Pridajte content-visibility: auto s contain-intrinsic-size na sekcie, ktoré nie sú hneď viditeľné.
Merajte a iterujte
Overte zlepšenia pomocou Lighthouse, WebPageTest alebo Chrome UX Report. Cieľový LCP pre dobré skóre je pod 2,5 sekundy.

Kompletný príklad optimalizovaného LCP obrázka

Tu je príklad, ktorý všetko spája dokopy:

<!-- V <head> — preload pre LCP obrázok -->
<link
  rel="preload"
  as="image"
  imagesrcset="
    hero-400.avif   400w,
    hero-800.avif   800w,
    hero-1200.avif 1200w,
    hero-1920.avif 1920w
  "
  imagesizes="100vw"
  type="image/avif"
  fetchpriority="high"
/>

<!-- V <body> — LCP obrázok s plnou optimalizáciou -->
<picture>
  <source
    type="image/avif"
    srcset="
      hero-400.avif   400w,
      hero-800.avif   800w,
      hero-1200.avif 1200w,
      hero-1920.avif 1920w
    "
    sizes="100vw"
  />
  <source
    type="image/webp"
    srcset="
      hero-400.webp   400w,
      hero-800.webp   800w,
      hero-1200.webp 1200w,
      hero-1920.webp 1920w
    "
    sizes="100vw"
  />
  <img
    src="hero-1200.jpg"
    srcset="
      hero-400.jpg   400w,
      hero-800.jpg   800w,
      hero-1200.jpg 1200w,
      hero-1920.jpg 1920w
    "
    sizes="100vw"
    alt="Hlavný banner — optimalizovaný pre LCP"
    width="1920"
    height="1080"
    fetchpriority="high"
  />
</picture>

Najčastejšie chyby, ktorým sa vyhnite

Lazy loading na LCP obrázku — najväčší performance anti-pattern. Zvyšuje LCP o stovky milisekúnd
Chýbajúce rozmery obrázkov — spôsobuje CLS, keď sa obrázok načíta a posunie okolný obsah
Príliš veľa preloadov — preloadovanie viac ako 2–3 zdrojov znižuje efektivitu, pretože všetky súťažia o šírku pásma
Servírovanie len jedného formátu — bez AVIF/WebP variantov prichádzate o 25–50 % úspory
Servírovanie obrovských obrázkov na mobily — bez srcset mobilní používatelia sťahujú desktop verzie. Obrázok 2000 px na 375 px mobile? To je desaťnásobné plytvanie
CSS background-image pre LCP obrázky — obrázky v CSS sú objavené neskôr ako obrázky v HTML, čo spomaľuje LCP. Ak musíte použiť background-image, doplňte preload
Ignorovanie kompresie — mnohé stránky servírujú obrázky priamo z fotoaparátu s veľkosťou 5–10 MB. Vždy komprimujte
Zabudnuté EXIF dáta — JPEG súbory z fotoaparátov obsahujú EXIF metadata (GPS súradnice, nastavenia fotoaparátu), ktoré zbytočne zväčšujú súbor a môžu byť aj bezpečnostným rizikom

Meranie a monitorovanie: Ako overiť výsledky

Optimalizácia bez merania je len hádanie. Tu sú nástroje a metriky, na ktoré sa zamerať.

Laboratórne nástroje

Lighthouse (zabudovaný v Chrome DevTools) — poskytuje skóre výkonu a konkrétne odporúčania pre obrázky vrátane detekcie chýbajúcich moderných formátov, neoptimálnych rozmerov a lazy loadingu na LCP
WebPageTest (webpagetest.org) — umožňuje testovať z rôznych lokácií a zariadení, poskytuje filmstrip zobrazenie a detailnú waterfall analýzu sieťových požiadaviek
PageSpeed Insights — kombinuje laboratórne dáta z Lighthouse s reálnymi dátami z Chrome UX Report

Terénne dáta (Real User Monitoring)

Laboratórne nástroje sú užitočné pre vývoj, ale pre skutočné pochopenie výkonu potrebujete terénne dáta od reálnych používateľov:

Chrome UX Report (CrUX) — agregované dáta od reálnych používateľov Chrome. Dostupné cez PageSpeed Insights alebo BigQuery
Web Vitals JavaScript knižnica — umožňuje zbierať Core Web Vitals metriky a posielať ich do vašej analytiky

// Monitorovanie LCP v produkcii pomocou web-vitals knižnice
import { onLCP } from 'web-vitals';

onLCP((metric) => {
  // Odoslanie do vašej analytiky
  console.log('LCP:', metric.value, 'ms');
  console.log('LCP element:', metric.entries[0]?.element);

  // Príklad odoslania do Google Analytics 4
  gtag('event', 'web_vitals', {
    event_category: 'Web Vitals',
    event_label: metric.id,
    value: Math.round(metric.value),
    metric_name: 'LCP',
    metric_delta: Math.round(metric.delta),
  });
});

Cieľové hodnoty v roku 2026

Google definuje tieto prahy pre Core Web Vitals:

LCP: Dobré pod 2,5 s | Vyžaduje zlepšenie 2,5–4 s | Slabé nad 4 s
CLS: Dobré pod 0,1 | Vyžaduje zlepšenie 0,1–0,25 | Slabé nad 0,25
INP: Dobré pod 200 ms | Vyžaduje zlepšenie 200–500 ms | Slabé nad 500 ms

Optimalizácia obrázkov priamo ovplyvňuje LCP a CLS — dve z troch Core Web Vitals metrík. Takže ak sa chcete zlepšiť v Core Web Vitals, obrázky sú skvelé miesto, kde začať.

Záver

Optimalizácia obrázkov pre web nie je jednorázový úkon, ale kontinuálny proces, ktorý by mal byť súčasťou vášho vývojového workflow. Poďme si zhrnúť kľúčové techniky:

Moderné formáty — AVIF a WebP s fallback reťazcom cez <picture> element vám ušetria 25–50 % dát
Responzívne obrázky — srcset a sizes zabezpečia, že každé zariadenie dostane optimálnu veľkosť
fetchpriority — fetchpriority="high" na LCP obrázku urýchli jeho načítanie o 2–8 %
Lazy loading — loading="lazy" na obrázkoch pod záhybom znižuje počiatočnú záťaž, ale nikdy ho nepoužívajte na LCP obrázku
Preloading — <link rel="preload"> pre LCP obrázky, obzvlášť ak sú v CSS alebo načítavané JavaScriptom
content-visibility — až 7-násobné zrýchlenie renderovania sekcií pod záhybom
Obrazové CDN — automatická optimalizácia s 40–80 % úsporou veľkosti bez manuálnej práce
Správna kompresia — nástrojmi ako Sharp s odporúčanými nastaveniami kvality pre každý formát

Implementácia týchto techník je investíciou, ktorá sa vracia v podobe lepších SEO pozícií, vyšších konverzií a spokojnejších používateľov. Podľa štúdií Googlu vedie každé zlepšenie LCP o 100 ms k merateľnému nárastu konverznej miery. Amazon zistil, že každých 100 ms oneskorenia stojí 1 % tržieb. A Vodafone zaznamenalo 8 % nárast predajov po 31 % zlepšení LCP.

Začnite s identifikáciou vášho LCP obrázka, aplikujte techniky z tohto sprievodcu jednu po druhej a nechajte si meranie výsledkov ako kompas. Každá milisekunda sa počíta — a v konkurenčnom digitálnom prostredí roku 2026 sú rýchle stránky jednoducho nevyhnutnosťou.