Képoptimalizálás 2026: AVIF, WebP útmutató

Miért a képek a webes teljesítmény legnagyobb ellenségei — és legjobb szövetségesei?

Ha valaha is próbáltál már javítani egy weboldal teljesítményén, szinte biztosan a képekkel kellett először megküzdened. És ez nem véletlen. A HTTP Archive 2025-ös Web Almanac adatai szerint a képek jelentik a legnehezebb erőforrástípust a weboldalak összsúlyában. A medián mobilos főoldal 2,6 MB-os méretéből a képek teszik ki a legnagyobb részt, a medián főoldal pedig 19 képet tölt be — szemben a belső oldalak 13-as átlagával.

De az igazán megdöbbentő adat ez: a weboldalak 72%-ánál a Largest Contentful Paint (LCP) elemet egy kép képezi mobilon.

Ezek a számok egyértelműen üzennek: ha az LCP mutatódat szeretnéd javítani — márpedig 2026-ban ez továbbra is az egyik legfontosabb Core Web Vitals mutató, ami közvetlenül befolyásolja a Google keresési rangsorolást —, akkor a képoptimalizálás nem opcionális. Alapvető szükséglet. Ebben az útmutatóban végigmegyünk a modern képoptimalizálás minden kulcsfontosságú aspektusán: a formátumválasztástól a reszponzív képeken át a betöltési prioritásokig és az automatizált megoldásokig.

A modern képformátumok csatája: JPEG vs. WebP vs. AVIF

A képformátum kiválasztása az első és talán leghatásosabb döntés, amit meghozhatunk. 2026-ban három formátum verseng a webes dominanciáért, és őszintén szólva, mindegyiknek megvan a maga helye az eszköztárunkban.

JPEG: az öreg harcos

A JPEG közel három évtizede a web alapértelmezett fotóformátuma. Az előnyei — univerzális böngészőtámogatás, gyors dekódolás, jó tömörítés fotóknál — vitathatatlanok. A hátrányai viszont egyre nyilvánvalóbbak: nem támogat átlátszóságot, a tömörítési arány messze elmarad a modern formátumoktól, és alacsony minőségi beállítások mellett jellegzetes blokk-artifaktumok jelennek meg. Szóval igen, a JPEG még él, de már nem ő a király.

WebP: az arany középút

A Google által fejlesztett WebP 2026-ra elérte a 97%-os böngészőtámogatottságot — gyakorlatilag univerzálisnak tekinthető. A számok magukért beszélnek: a WebP átlagosan 30-34%-kal kisebb fájlméretet produkál, mint az egyenértékű JPEG, és 26%-kal kisebbet, mint a PNG. Támogatja az átlátszóságot, az animációt, illetve a veszteséges és veszteségmentes tömörítést egyaránt.

Van egy kevésbé ismert, de fontos előnye is: a dekódolási sebesség. A böngészők a WebP képeket általában gyorsabban dekódolják, mint az AVIF-et — és ez különösen fontos lehet alacsonyabb teljesítményű mobileszközökön, ahol a CPU-kapacitás szűkösebb.

AVIF: a jövő bajnoka

Az AV1 videókodek alapjain épülő AVIF a jelenlegi legjobb tömörítési arányokat kínálja webes képek számára. Az összehasonlító tesztek alapján az AVIF fájlok mediánja 50,3%-kal kisebb az egyenértékű JPEG-eknél, a WebP-hez képest pedig 20-25%-os további méretcsökkenést ér el hasonló vizuális minőség mellett. Ráadásul támogatja a HDR-t, a nagyobb színmélységet, és vizuálisan kevesebb artifaktumot produkál alacsony bitrátán.

Viszont van egy fontos figyelmeztetés. Bár az AVIF böngészőtámogatottsága gyorsan javul, 2026-ban még nem éri el a WebP szintjét. Az AVIF kódolása (tömörítése) is jelentősen lassabb, mint a WebP-é vagy a JPEG-é, ami a build-folyamatot lassíthatja. A dekódolás szintén valamivel több CPU-erőforrást igényel.

A helyes stratégia: progresszív formátumszolgáltatás

Na de akkor mit csináljunk? A legjobb megközelítés 2026-ban az úgynevezett progresszív formátumszolgáltatás, ahol AVIF-et szolgálunk ki elsődlegesen, WebP-t tartalékként, és JPEG-et végső visszaesési opcióként. Ezt a HTML <picture> elem teszi lehetővé:

<picture>
  <!-- AVIF: legjobb tömörítés, ahol támogatott -->
  <source srcset="hero.avif" type="image/avif">
  <!-- WebP: kiváló tartalék, szinte mindenhol működik -->
  <source srcset="hero.webp" type="image/webp">
  <!-- JPEG: univerzális visszaesés -->
  <img src="hero.jpg" alt="Hőskép leírása" width="1200" height="630">
</picture>

A böngésző automatikusan az első támogatott formátumot választja, tehát minden felhasználó a számára legoptimálisabb változatot kapja. Ez a megközelítés akár 40-50%-os sávszélesség-megtakarítást eredményezhet a hagyományos JPEG-hez képest — és közben senki sem lát törött képet. Elég jó üzlet, nem?

Reszponzív képek: a helyes méretű kép a helyes eszközre

A formátumválasztás mellett a képméret a másik kritikus tényező. Gondolj bele: ha egy 1920×1080 pixeles háttérképet szolgálsz ki egy 375 pixeles szélességű mobil képernyőre, a felhasználó a szükségesnél ötször több adatot tölt le. A böngészőnek ráadásul a kép átméretezésére is erőforrást kell fordítania. Ez pazarlás a felhasználó sávszélességéből és az eszköz CPU-kapacitásából egyaránt.

A srcset és sizes attribútumok

A HTML srcset attribútuma lehetővé teszi, hogy több különböző méretű képváltozatot kínáljunk a böngészőnek, ami a képernyőméret, pixelsűrűség, zoom szint és hálózati feltételek alapján automatikusan a legmegfelelőbbet választja. A sizes attribútum pedig megmondja a böngészőnek, hogy az adott kép a layout-ban mekkora helyet fog elfoglalni.

<img
  srcset="
    hero-400w.jpg   400w,
    hero-800w.jpg   800w,
    hero-1200w.jpg 1200w,
    hero-1600w.jpg 1600w,
    hero-2000w.jpg 2000w
  "
  sizes="
    (max-width: 600px) 100vw,
    (max-width: 1024px) 80vw,
    50vw
  "
  src="hero-1200w.jpg"
  alt="Példa reszponzív kép"
  width="1200"
  height="630"
  loading="lazy"
>

A fenti példában a sizes attribútum elmondja a böngészőnek: 600 px-es képernyőszélesség alatt a kép a viewport teljes szélességét foglalja el (100vw), 1024 px alatt 80%-ot, ennél szélesebb képernyőn pedig 50%-ot. A böngésző ezek alapján — a saját pixelsűrűsége ismeretében — kiválasztja a legmegfelelőbb képváltozatot a srcset-ből.

Kombináció a picture elemmel

A formátumszolgáltatás és a reszponzív képek kombinálhatók egy összetett, de rendkívül hatékony megoldássá:

<picture>
  <source
    srcset="
      hero-400w.avif  400w,
      hero-800w.avif  800w,
      hero-1200w.avif 1200w,
      hero-1600w.avif 1600w
    "
    sizes="(max-width: 600px) 100vw, (max-width: 1024px) 80vw, 50vw"
    type="image/avif"
  >
  <source
    srcset="
      hero-400w.webp  400w,
      hero-800w.webp  800w,
      hero-1200w.webp 1200w,
      hero-1600w.webp 1600w
    "
    sizes="(max-width: 600px) 100vw, (max-width: 1024px) 80vw, 50vw"
    type="image/webp"
  >
  <img
    srcset="
      hero-400w.jpg  400w,
      hero-800w.jpg  800w,
      hero-1200w.jpg 1200w,
      hero-1600w.jpg 1600w
    "
    sizes="(max-width: 600px) 100vw, (max-width: 1024px) 80vw, 50vw"
    src="hero-1200w.jpg"
    alt="Hőskép leírása"
    width="1200"
    height="630"
  >
</picture>

Ez a kombináció biztosítja, hogy minden eszközön a lehető legkisebb fájlméretet szolgáljuk ki — mind formátum, mind méret szempontjából. A gyakorlati megtakarítás akár 70-80%-os is lehet egy nem optimalizált JPEG-hez képest. Komolyan, ennél jobb befektetést nehéz találni a webfejlesztésben.

Hány képváltozatot érdemes generálni?

Jogos kérdés. Ha túl sok változatot generálunk, az a build-folyamatot lassítja és a cache hatékonyságát rontja. A szakértők ajánlása szerint legalább 4-5, de legfeljebb 12-15 különböző szélesség elegendő a legtöbb esetben.

Egy bevált kiindulópont: 400, 800, 1200, 1600 és 2000 pixeles szélességek. Ez lefedi a mobiltól a nagy felbontású asztali kijelzőkig terjedő spektrumot anélkül, hogy a cache-elhetőség sérülne.

LCP-optimalizálás: a hőskép betöltési stratégiája

Az LCP (Largest Contentful Paint) a felhasználó által érzékelt betöltési sebesség egyik legfontosabb mutatója. A Google elvárása, hogy az LCP 2,5 másodperc alatt legyen az oldalmegtekintések legalább 75%-ánál. És mivel a mobilos oldalak 72%-ánál kép az LCP elem, a hőskép (hero image) betöltési stratégiája kritikus fontosságú.

Soha ne lazy-loadolj LCP képet!

Ez talán a leggyakoribb és legfájdalmasabb hiba, amit fejlesztők elkövetnek. Saját tapasztalatom szerint is rengeteg production site-on láttam már ezt. Amikor a loading="lazy" attribútumot az LCP képre alkalmazzuk, azt üzenjük a böngészőnek, hogy ez a kép alacsony prioritású — holott pont az ellenkezőjét szeretnénk.

A Shopify kutatásai szerint azoknál az oldalaknál, amelyek nem lazy-loadolják az LCP képet, akár 3 másodperccel gyorsabb az LCP. Három másodperc!

Amikor loading="lazy"-t adsz a hero képhez, megváltoztatod a böngésző ütemezését: a kép alacsonyabb prioritást kap, más erőforrások indulnak el előbb, és a böngésző megvárja a layout-ot, mielőtt lekérné a hero képet. Ez a késleltetés eltolja a legnagyobb elem megjelenítésének időpontját, és feleslegesen növeli az LCP-t.

A fetchpriority attribútum: LCP-gyorsító

A fetchpriority attribútum 2026-ban már széles körben támogatott, és lehetővé teszi a betöltési prioritások finomhangolását. A Google saját tesztjei szerint a fetchpriority="high" hozzáadása az LCP képhez 2,6 másodpercről 1,9 másodpercre javította az LCP-t. Ez 27%-os javulás egyetlen attribútum hozzáadásával — nem rossz, ugye?

<!-- Az LCP (hero) képnél: fetchpriority="high", NEM loading="lazy" -->
<img
  src="hero-image.webp"
  alt="Főoldal hőskép"
  width="1200"
  height="630"
  fetchpriority="high"
  decoding="async"
>

<!-- A hajtás alatti képeknél: loading="lazy", fetchpriority="low" -->
<img
  src="gallery-image-1.webp"
  alt="Galéria kép"
  width="600"
  height="400"
  loading="lazy"
  fetchpriority="low"
  decoding="async"
>

Preload a hero képhez

Az LCP kép betöltését tovább gyorsíthatjuk a <link rel="preload"> direktívával, ami a HTML feldolgozás legkorábbi szakaszában elindítja a kép letöltését — még mielőtt a böngésző elérné az <img> taget a DOM-ban:

<head>
  <!-- Hero kép preload-olása a lehető legkorábban -->
  <link
    rel="preload"
    as="image"
    href="hero-image.avif"
    type="image/avif"
    fetchpriority="high"
  >

  <!-- Reszponzív preload: ha több méretben is van -->
  <link
    rel="preload"
    as="image"
    href="hero-image.avif"
    imagesrcset="
      hero-400w.avif  400w,
      hero-800w.avif  800w,
      hero-1200w.avif 1200w
    "
    imagesizes="(max-width: 600px) 100vw, 50vw"
    type="image/avif"
  >
</head>

Fontos megjegyzés: a preload-ot óvatosan használd! Csak az LCP képre és esetleg 1-2 kritikus erőforrásra alkalmazd, különben a böngésző prioritási rendszerét borítod fel, és az eredmény pont az ellenkező lesz a kívántnak.

Lazy loading: a hajtás alatti képek intelligens kezelése

Míg az LCP képnél kerülendő a lazy loading, a hajtás alatti (below-the-fold) képeknél kifejezetten ajánlott. A natív loading="lazy" attribútum 2026-ban már minden modern böngészőben stabilan támogatott, és nulla JavaScript kód hozzáadásával aktiválható. Egyszerűen szép megoldás.

A natív lazy loading működése

Amikor loading="lazy"-t adunk egy képhez, a böngésző csak akkor kezdi el letölteni, amikor a kép közel kerül a viewport-hoz (jellemzően néhány száz pixelen belül). Ez drámaian csökkenti az oldal kezdeti betöltési idejét — különösen képgazdag oldalakon, mint galériák, e-kereskedelmi termékoldalak vagy hírportálok.

<!-- Hajtás alatti képek: natív lazy loading -->
<img
  src="product-1.webp"
  alt="Termék neve"
  width="400"
  height="300"
  loading="lazy"
  decoding="async"
>

<!-- Iframe-ek is lazy-loadolhatók -->
<iframe
  src="https://www.youtube.com/embed/VIDEO_ID"
  width="560"
  height="315"
  loading="lazy"
  title="Videó címe"
></iframe>

Kritikus szabály: width és height mindig legyen megadva!

Ha lazy-loadolt képeknél nem adjuk meg a width és height attribútumokat (vagy CSS-ben az aspect-ratio-t), az szinte garantáltan CLS (Cumulative Layout Shift) problémát okoz. A böngésző nem tudja, mekkora helyet foglaljon le a képnek, és amikor az betöltődik, az egész oldal elrendezése megugrik.

Ez nemcsak rossz felhasználói élmény, hanem rontja a CLS Core Web Vitals mutatót is.

<!-- ROSSZ: nincs méretmegadás → CLS probléma -->
<img src="photo.webp" alt="Fotó" loading="lazy">

<!-- JÓ: explicit méretek → nincs layout shift -->
<img src="photo.webp" alt="Fotó" loading="lazy"
     width="800" height="600">

<!-- SZINTÉN JÓ: CSS aspect-ratio -->
<style>
  .responsive-img {
    width: 100%;
    height: auto;
    aspect-ratio: 4 / 3;
  }
</style>
<img src="photo.webp" alt="Fotó" loading="lazy"
     class="responsive-img">

Képtömörítés: a minőség és a méret egyensúlya

A képformátum és méret mellett a tömörítési szint is döntő. A cél az, hogy megtaláljuk azt a pontot, ahol a fájlméret-csökkenés már jelentős, de a vizuális minőség-romlás még nem észrevehető. Tudom, könnyebb mondani, mint megcsinálni — de vannak jó kiindulópontok.

Ajánlott tömörítési beállítások

A legtöbb felhasználási esetben az alábbi minőségi beállítások jó kiindulópontot jelentenek:

JPEG: 75-85% minőség. A 80%-os beállítás általában a legjobb egyensúlyt kínálja.
WebP: 75-85% minőség veszteséges módban. Ugyanolyan vizuális minőséget tud produkálni kisebb fájlmérettel, mint a JPEG.
AVIF: 60-75% minőség. Az AVIF kódoló hatékonyabb, ezért alacsonyabb minőségi számnál is kiváló vizuális eredményt ad.
PNG: Csak akkor használd, ha az éles kontúrok és az átlátszóság egyaránt szükséges (pl. logók, ikonok). Lossless formátum, a tömörítés korlátozott.

Automatizált képtömörítés a build-folyamatban

A kézi képoptimalizálás nem skálázható — ezt a saját bőrömön tapasztaltam elég sokszor. A modern fejlesztési munkafolyamatokban a képtömörítést a build-folyamatba érdemes integrálni. Íme egy Vite-alapú megoldás a vite-plugin-image-optimizer használatával:

// vite.config.js
import { defineConfig } from 'vite';
import { ViteImageOptimizer } from 'vite-plugin-image-optimizer';

export default defineConfig({
  plugins: [
    ViteImageOptimizer({
      jpg: {
        quality: 80,
        progressive: true,
      },
      png: {
        quality: [0.65, 0.80],
        speed: 4,
      },
      webp: {
        quality: 80,
        effort: 4,
      },
      avif: {
        quality: 65,
        effort: 4,
        chromaSubsampling: '4:2:0',
      },
    }),
  ],
});

Node.js alkalmazásokban a sharp könyvtár a de facto standard a szerver oldali képfeldolgozáshoz. A sharp a C nyelven írt libvips könyvtárat használja, ami extrém gyors és memóriahatékony:

// sharp-image-pipeline.js
const sharp = require('sharp');
const path = require('path');

async function optimizeImage(inputPath, outputDir) {
  const filename = path.basename(inputPath, path.extname(inputPath));
  const widths = [400, 800, 1200, 1600, 2000];

  for (const width of widths) {
    const pipeline = sharp(inputPath).resize(width);

    // WebP változat generálása
    await pipeline
      .clone()
      .webp({ quality: 80, effort: 4 })
      .toFile(path.join(outputDir, `${filename}-${width}w.webp`));

    // AVIF változat generálása
    await pipeline
      .clone()
      .avif({ quality: 65, effort: 4 })
      .toFile(path.join(outputDir, `${filename}-${width}w.avif`));

    // JPEG tartalék
    await pipeline
      .clone()
      .jpeg({ quality: 80, progressive: true })
      .toFile(path.join(outputDir, `${filename}-${width}w.jpg`));
  }

  console.log(`Kész: ${widths.length * 3} változat generálva`);
}

// Használat
optimizeImage('./images/hero.jpg', './dist/images');

Ez a script egyetlen forráskép alapján 15 optimalizált változatot generál (5 szélesség × 3 formátum), amelyeket aztán a <picture> és srcset elemekkel szolgálhatsz ki.

Image CDN-ek: automatizált képoptimalizálás skálán

Ha nem akarsz a build-folyamatban bajlódni a képkonverziókkal, vagy dinamikus tartalmad van (felhasználók által feltöltött képek, e-kereskedelmi termékkatalógus), akkor az Image CDN-ek jelentik a legpraktikusabb megoldást. Ezek a szolgáltatások automatikusan, valós időben optimalizálják a képeket az URL-ben megadott paraméterek alapján.

Hogyan működik egy Image CDN?

Az Image CDN-ek alapvetően egy intelligens közvetítő réteget képeznek a forráskép és a felhasználó között. Amikor egy kép URL-jét lekérik, a CDN a következőket csinálja:

Felismeri a böngésző képességeit (User-Agent, Accept header alapján)
Automatikusan kiválasztja a legjobb formátumot (AVIF, WebP vagy JPEG)
Az URL paraméterek alapján átméretezi, vágja és tömöríti a képet
Cache-eli az eredményt az edge szervereken
A felhasználóhoz legközelebbi szerverről szolgálja ki

<!-- Cloudinary példa: automatikus formátum és minőség -->
<img
  src="https://res.cloudinary.com/demo/image/upload/f_auto,q_auto,w_800/hero-image.jpg"
  alt="Automatikusan optimalizált kép"
  width="800"
  height="450"
>

<!-- imgix példa: reszponzív kép automatikus formátummal -->
<img
  srcset="
    https://example.imgix.net/hero.jpg?auto=format&w=400  400w,
    https://example.imgix.net/hero.jpg?auto=format&w=800  800w,
    https://example.imgix.net/hero.jpg?auto=format&w=1200 1200w
  "
  sizes="(max-width: 600px) 100vw, 50vw"
  src="https://example.imgix.net/hero.jpg?auto=format&w=800"
  alt="imgix által optimalizált kép"
  width="800"
  height="450"
>

Az f_auto (Cloudinary) vagy auto=format (imgix) paraméter az automatikus formátumválasztást aktiválja: ha a böngésző támogatja az AVIF-et, azt kapja; ha csak WebP-t, akkor azt; egyébként JPEG-et. A q_auto paraméter pedig intelligens, tartalom-alapú tömörítési szintet alkalmaz automatikusan.

Az Image CDN-ek használatával átlagosan 30-50%-os javulás érhető el az oldalbetöltési sebességben és 20-35%-os csökkenés a sávszélesség-felhasználásban — mindezt anélkül, hogy manuálisan kellene foglalkoznod a képoptimalizálással. Ha van rá büdzsé, megéri.

CLS megelőzés: layout shift nélküli képmegjelenítés

A Cumulative Layout Shift (CLS) mutató azt méri, mennyire ugrálnak az oldalelemek betöltés közben. A képek az egyik leggyakoribb CLS-okozók — de szerencsére viszonylag egyszerűen megelőzhető a probléma.

Explicit méretek megadása

A legegyszerűbb és leghatékonyabb megoldás: add meg a width és height HTML attribútumokat. A modern böngészők ezekből automatikusan kiszámítják az aspect-ratio-t, és lefoglalják a szükséges helyet a layout-ban, még mielőtt a kép letöltődne:

<!-- A böngésző a width/height alapján automatikusan
     beállítja az aspect-ratio-t (4:3 ebben az esetben) -->
<img src="photo.webp" alt="Kép" width="800" height="600">

<!-- CSS-ben adjunk hozzá reszponzív viselkedést -->
<style>
  img {
    max-width: 100%;
    height: auto;
  }
</style>

Az aspect-ratio CSS tulajdonság

Összetettebb esetekben (háttérképek, CSS-szel méretezett konténerek) a CSS aspect-ratio tulajdonság a legjobb megoldás:

<style>
  .image-container {
    width: 100%;
    aspect-ratio: 16 / 9;
    background-color: #f0f0f0; /* Placeholder szín */
    overflow: hidden;
  }

  .image-container img {
    width: 100%;
    height: 100%;
    object-fit: cover;
  }
</style>

<div class="image-container">
  <img src="banner.webp" alt="Banner" loading="lazy">
</div>

LQIP: alacsony minőségű placeholder technika

A Low-Quality Image Placeholder (LQIP) egy ügyes trükk: egy nagyon kis fájlméretű (általában 1-2 KB), erősen elmosódott előnézeti képet jelenít meg, amíg a teljes méretű kép betöltődik. Ez nem csak a CLS-t előzi meg, hanem vizuálisan is sokkal jobb élményt nyújt, mint egy üres hely vagy egy szürke doboz:

<style>
  .lqip-wrapper {
    position: relative;
    overflow: hidden;
    aspect-ratio: 16 / 9;
  }

  .lqip-wrapper .placeholder {
    position: absolute;
    inset: 0;
    filter: blur(20px);
    transform: scale(1.1); /* Blur edge artefaktumok elrejtése */
    transition: opacity 0.3s ease;
  }

  .lqip-wrapper img.loaded + .placeholder {
    opacity: 0;
  }
</style>

<div class="lqip-wrapper">
  <img
    src="photo-full.webp"
    alt="Fotó"
    loading="lazy"
    width="1200"
    height="675"
    onload="this.classList.add('loaded')"
  >
  <!-- Inline base64 LQIP: ~1-2 KB -->
  <img
    class="placeholder"
    src="data:image/jpeg;base64,/9j/4AAQSkZJRgABAQ..."
    alt=""
    aria-hidden="true"
  >
</div>

A decoding attribútum: ne blokkolj feleslegesen

A kevésbé ismert, de hasznos decoding attribútum lehetővé teszi, hogy jelezzük a böngészőnek, hogyan kezelje a kép dekódolását. Alapértelmezetten a böngésző szinkron módon dekódolja a képeket, ami blokkolhatja a fő szálat és késleltetheti a renderelést.

<!-- decoding="async": a böngésző aszinkron módon dekódolja a képet,
     nem blokkolva a fő szálat -->
<img
  src="photo.webp"
  alt="Fotó"
  width="800"
  height="600"
  decoding="async"
  loading="lazy"
>

<!-- decoding="sync": szinkron dekódolás (ritkán szükséges,
     csak ha azonnali megjelenítés kritikus) -->
<img
  src="critical-diagram.webp"
  alt="Kritikus diagram"
  width="800"
  height="400"
  decoding="sync"
>

A legtöbb esetben a decoding="async" a helyes választás, különösen lazy-loadolt képeknél. Az LCP képnél is használható — a böngésző intelligensen kezeli az aszinkron dekódolást, és nem okoz felesleges késleltetést az LCP mérésénél.

SVG optimalizálás: vektoros grafika a webre

Bár eddig főként raszteres képekről volt szó, a vektoros SVG formátum is megérdemli a figyelmet. Az SVG-k ideálisak ikonok, logók, illusztrációk és egyszerű animációk számára, mert méretfüggetlenül élesek maradnak, és a fájlméretük általában töredéke az egyenértékű raszteres képnek.

SVG méretcsökkentés az SVGO-val

Az SVG fájlok gyakran tele vannak felesleges metaadatokkal, kommentekkel, rejtett rétegekkel és redundáns attribútumokkal — különösen, ha grafikus szerkesztőkből (Figma, Illustrator, Sketch) exportáljuk őket. Az SVGO (SVG Optimizer) ezeket automatikusan kitakarítja:

# SVGO telepítése és használata
npm install -g svgo

# Egyetlen fájl optimalizálása
svgo input.svg -o output.svg

# Könyvtár összes SVG fájljának optimalizálása
svgo -f ./icons -o ./icons-optimized

# Konfigurálható beállítások: svgo.config.js
module.exports = {
  plugins: [
    'preset-default',
    'removeDimensions',
    {
      name: 'removeAttrs',
      params: {
        attrs: '(data-.*)',
      },
    },
  ],
};

Az SVGO tipikusan 20-60%-os méretcsökkentést ér el az SVG fájlokon, ami gzip tömörítéssel kombinálva tovább csökken. Nem rossz egy egyszerű npm package-ért.

Képoptimalizálási checklist: minden egy helyen

Rendben, sok mindent leírtam — szóval itt egy tömör checklist, amit bármely projekt képoptimalizálásánál alkalmazhatsz:

Formátumstratégia: Használj progresszív formátumszolgáltatást a <picture> elemmel: AVIF → WebP → JPEG.
Reszponzív képek: Generálj több méretváltozatot (400-2000 px szélességben) és használd a srcset + sizes attribútumokat.
LCP kép prioritása: Az LCP (hero) képen használj fetchpriority="high"-t, NE használj loading="lazy"-t. Fontold meg a <link rel="preload"> használatát is.
Lazy loading: A hajtás alatti képeken használj loading="lazy"-t, de mindig add meg a width és height attribútumokat a CLS megelőzéséhez.
Tömörítési beállítások: JPEG/WebP: 75-85%, AVIF: 60-75%.
Dekódolás: Használj decoding="async"-ot a legtöbb képnél.
SVG optimalizálás: Futtasd az SVGO-t a vektoros grafikákon.
Build automatizálás: Integráld a képoptimalizálást a build-folyamatba (sharp, vite-plugin-image-optimizer) vagy használj Image CDN-t.
Mérés: Rendszeresen ellenőrizd az LCP-t és CLS-t a PageSpeed Insights-ban, a Chrome DevTools-ban és valós felhasználói adatokkal (CrUX).

Mérés és monitorozás: honnan tudod, hogy működik?

Az optimalizálás csak akkor ér valamit, ha mérhető eredményeket produkál. Nézzük a legfontosabb eszközöket.

Chrome DevTools: a fejlesztő legjobb barátja

A Chrome DevTools Network fülén szűrhetsz képekre (Img), és láthatod minden kép méretét, formátumát és betöltési idejét. A Performance fülön pedig azonosíthatod, melyik kép az LCP elem, és pontosan mennyi idő telik el a betöltéséig. Ezek az információk aranyat érnek a hibakeresésben.

Lighthouse és PageSpeed Insights

A Lighthouse automatikusan felismeri a képoptimalizálási lehetőségeket, és konkrét javaslatokat ad: „Serve images in next-gen formats", „Properly size images", „Efficiently encode images". A PageSpeed Insights ráadásul valós felhasználói adatokat (CrUX) is mutat, szóval nem csak szintetikus, hanem tényleges felhasználói tapasztalatok alapján értékelheted a teljesítményt.

Automatizált monitorozás

Az egyszeri mérés sajnos nem elég — a képoptimalizálás hatékonyságát folyamatosan figyelni kell. Eszközök mint a DebugBear, SpeedCurve vagy a Web Vitals JavaScript könyvtár segítenek ebben:

// Web Vitals könyvtár használata LCP monitorozáshoz
import { onLCP } from 'web-vitals';

onLCP((metric) => {
  console.log('LCP érték:', metric.value, 'ms');
  console.log('LCP elem:', metric.entries[0]?.element);

  // Küldés analytics szolgáltatásba
  sendToAnalytics({
    name: metric.name,
    value: metric.value,
    id: metric.id,
    navigationType: metric.navigationType,
  });
});

Összefoglalás: a képoptimalizálás nem egyszeri feladat

A webes képoptimalizálás 2026-ban is a teljesítményoptimalizálás egyik leghatásosabb területe. A statisztikák egyértelműek: a mobilos LCP elemek 72%-a kép, és az oldalak összsúlyának legnagyobb részét a képek adják. Egyetlen fetchpriority="high" attribútum 27%-kal javíthatja az LCP-t, a modern formátumok (AVIF, WebP) pedig 30-50%-kal csökkenthetik a fájlméretet.

De — és ezt nem győzöm hangsúlyozni — a képoptimalizálás nem egy egyszeri projekt. Ez egy folyamatos gyakorlat. Minden új tartalom feltöltésekor, minden dizájn-változásnál, minden új eszköz vagy böngésző megjelenésekor újra kell értékelni a stratégiát.

A jó hír, hogy a modern eszközök — Image CDN-ek, build-plugin-ek, natív böngésző attribútumok — nagyrészt automatizálhatóvá teszik ezt a folyamatot.

Kezdd a legnagyobb hatású lépéssel: azonosítsd az LCP képet az oldalaidon, add hozzá a fetchpriority="high"-t, távolítsd el a loading="lazy"-t, és konvertáld WebP/AVIF formátumba. Ez az egy lépés önmagában drasztikus javulást hozhat a Core Web Vitals mutatóidban.