Képoptimalizálás 2026-ban: AVIF, WebP és lusta betöltés

A képek továbbra is a legnehezebb elemek a legtöbb weboldalon. A DigiForge-nél készült fejlesztéseink során rendszeresen tapasztaljuk, hogy a képek teszik ki az oldal teljes súlyának jelentős részét. 2026-ra letisztult a helyzet: az AVIF és a WebP a két modern formátum, amelyeket érdemes használni, a reszponzív képek srcset segítségével alapkövetelmények, a lusta betöltés pedig annyira elterjedt, hogy a rossz implementációja valójában ronthat a teljesítményen. Ez a cikk a gyakorlati tapasztalatainkat sűríti egy világos, határozott munkafolyamatba, amelyet bármely projektre alkalmazhatsz.

A megfelelő formátum kiválasztása: AVIF vs WebP

Évekig a WebP volt a következő generációs formátum. Az AVIF később érkezett, jobb tömörítést és HDR-támogatást ígérve, de magasabb kódolási költséggel és olyan böngészőtámogatással, ami még mindig nem univerzális (a Safari volt az utolsó lemaradó). Így áll a helyzet 2026-ban:

• AVIF általában kisebb fájlméretet biztosít, mint a WebP azonos észlelt minőség mellett. Támogatja a 10 bites színeket, a HDR-t, a veszteségmentes alfát és az animációt is. A kódolás lényegesen lassabb, mint a WebP esetében, így kevésbé alkalmas valós idejű generálásra, de jól használható a build időben előre elkészített statikus eszközökhöz.
• WebP minden modern böngészőben univerzálisan támogatott. Kiszámítható minőséget, gyors kódolást és kiváló eszköztárat (cwebp, sharp, imagemin) kínál. Tartalomban gazdag oldalaknál, ahol a kódolási sebesség számít, a WebP továbbra is a pragmatikus alapértelmezés.
• JPEG XL (JXL) korán ígéretes volt, de soha nem szerzett böngészőtámogatást. A Chromium eltávolította a jelzőjét, a Safari pedig soha nem implementálta. Ne vesztegesd rá az időt, amíg a helyzet meg nem változik.

A javaslatunk: Szolgálj ki AVIF-et WebP visszaeséssel. Használd a <picture> elemet, hogy a böngészők először AVIF-et, majd WebP-t, végül az eredeti JPEG/PNG-t válasszák. Ez maximalizálja a tömörítést azok számára, akik támogatják, miközben soha nem hagy senkit üres képernyő előtt. A legtöbb modern böngésző támogatja az AVIF-et, így a visszaesés fontos, de nem az elsődleges útvonal.

<picture>
  <source srcset="image.avif" type="image/avif">
  <source srcset="image.webp" type="image/webp">
  <img src="image.jpg" alt="...">
</picture>

Reszponzív méretek: nem csak a srcset

A srcset attribútum sizes-szel együtt jól ismert, de az általunk auditált implementációk közül sok hibásan használja a sizes-t. A böngésző a sizes alapján dönti el, melyik srcset-jelöltet töltse le – ez nem csupán egy javaslat. Ha a sizes hiányzik, az alapértelmezett 100vw, ami azt jelenti, hogy a böngésző akár a legnagyobb képet is letöltheti egy kis képernyőn is, ezzel pazarolva a sávszélességet.

Egyszerű reszponzív képeknél, ahol a kép a nézetablakkal együtt skálázódik, írd a következőt:

<img src="image-800.jpg" 
     srcset="image-400.jpg 400w, image-800.jpg 800w, image-1200.jpg 1200w"
     sizes="(max-width: 600px) 100vw, (max-width: 1200px) 50vw, 33vw"
     alt="...">

De van itt egy árnyalat. A sizes értékének a tényleges CSS-szélességet kell tükröznie, amelyet a kép az egyes töréspontokon elfoglal, nem pedig a nézőtér hányadát. Egy olyan hero képnél, amely mindig teljes szélességű, egyszerűen a sizes="100vw" a helyes. Egy galériánál, ahol minden kép a sor egyharmadát teszi ki, használjuk a 33vw-t. Ha a képnek van paddingje, vagy egy maximális szélességű konténerben van, ki kell számolnunk a tényleges megjelenített szélességet – néha szükség van a calc() használatára a sizes attribútumban.

Szélességleírók vs. pixelsűrűség

Használj w leírókat (pl. 400w) és sizes-t a rugalmas képeknél, amelyek megjelenési mérete az elrendezéssel változik. A sűrűségleírók (1x, 2x) csak fix méretű képeknél alkalmasak, mint amilyenek a logók vagy ikonok, ahol ismerjük a pontos fizikai méreteket. Tartalmi képeknél mindig w-t használj – ez adja meg a böngészőnek a valódi rugalmasságot, hogy a nézőtér szélessége és az eszköz pixelsűrűsége alapján kiválassza a legjobb jelöltet.

Amikor a <picture>-t használjuk formátumválasztásra, minden <source>-nak saját srcset-tel és opcionális sizes-szal kell rendelkeznie. Ha az elrendezés azonos, megoszthatjuk ugyanazt a sizes-t a források között, de kerüljük a szükségtelen ismétlést.

Lusta betöltés: natív, Intersection Observer vagy mindkettő?

A natív lusta betöltés (loading="lazy") 2020 óta támogatott az összes nagyobb böngészőben. Nulla JavaScript, működik képekkel és iframe-ekkel, és ez a legegyszerűbb út. De vannak olyan furcsaságai, amelyek a gyakorlatban számítanak:

• A natív lusta betöltés addig halasztja a betöltést, amíg a böngésző úgy nem ítéli, hogy az elem közel van a viewporthoz. A küszöbérték böngészőfüggő – a Chrome bő margót használ a korai betöltéshez; a Firefox kisebb margót. Ez azt jelenti, hogy a képek később tölthetők be Firefoxban.
• Nem működik tökéletesen a srcset-tel néhány korai implementációban. A régi Safari verziókban (16.4 előtt) hibák voltak. 2026-ban ezek ritkák, de még mindig érdemes tesztelni.
• A <picture> elemeknél a loading="lazy"-t az <img> tagon kell elhelyezni, nem a <source> tageken.

Mi hibrid megoldást használunk: a natív lusta betöltést alapértelmezettként, plusz egy könnyű Intersection Observer (IO) polyfill-t a régebbi böngészőkhöz (bár 2026-ra ez már niche eset). Az IO elindíthat fade-in animációkat vagy betölthet alacsony minőségű helyőrzőket. A mi implementációnk:

const lazyImages = document.querySelectorAll('img[loading="lazy"]');

if ('loading' in HTMLImageElement.prototype) {
  // Native lazy loading works – do nothing extra
} else {
  const observer = new IntersectionObserver((entries) => {
    entries.forEach(entry => {
      if (entry.isIntersecting) {
        const img = entry.target;
        img.src = img.dataset.src;
        observer.unobserve(img);
      }
    });
  });
  lazyImages.forEach(img => observer.observe(img));
}

Mindent összerakva: Gyakorlati munkafolyamat

A DigiForge-nál ezt a csővezetéket követjük minden projektnél, legyen az statikus oldal, CMS-alapú oldal vagy webalkalmazás:

1. Forrásképek: A tervezők nagy felbontású PNG vagy TIFF formátumban adják át. Az eredetiket egy _originals mappában tartjuk, hogy később újratömöríthessük, ha új formátumok jelennek meg.
2. Formátum generálás: Használj egy Node.js szkriptet sharp-pal vagy egy Makefile-t ImageMagick-kel, hogy AVIF, WebP és tartalék JPEG/PNG fájlokat állíts elő 3–5 szélességben (pl. 480, 800, 1200, 1920). Nagy projekteknél ezt párhuzamosan futtatjuk worker szálakkal a build felgyorsításához.
3. Minőség hangolás: Futtass CI ellenőrzéseket, amelyek összehasonlítják a fájlméretet egy perceptuális metrikával (SSIM vagy Butteraugli). Megakadályozzuk a pull requesteket, ha egy tipikus oldal teljes kép súlya meghalad egy ésszerű küszöbértéket a tartalom típusa alapján.
4. Markup: Generálj <picture>-t type sorrenddel (AVIF, WebP, tartalék) és <img>-t loading="lazy" attribútummal (kivéve az első hős képet). Reszponzív méretekhez generálj sizes-t a tényleges CSS alapján – ez gyakran egy design token fájlból származik, amelyet a design és a fejlesztés megoszt.
5. Kiszolgálás CDN-ről: Statikus oldalaknál előre kódolt eszközöket szolgálj ki egy CDN-ről hosszú cache fejlécekkel (pl. Cache-Control: public, max-age=31536000, immutable). Ha kép CDN-t használsz, mint a Cloudinary vagy az imgix, sok lépés automatizálható URL transzformációkkal, de a kritikus képeket még mindig előre kódoljuk, hogy elkerüljük a cold-start költségeket.

Az olyan oldalak, mint az Unsplash [3] és a Pixabay [1], nagy felbontású képeket biztosítanak, amelyek gyakran több megabájtot nyomnak nyersen. A mi csővezetékünk drámaian csökkenti ezeket észrevehetetlen veszteséggel. Hasonlóképpen, az olyan eszközökkel, mint a ChatGPT Images [4] generált AI-képek gyakran optimalizálatlan, nagy felbontásban érkeznek, így elengedhetetlen ugyanazon tömörítési munkafolyamaton átfuttatni őket. A stock képek a Shutterstock [5] vagy a Bing Images [2] oldalról hasonló jellemzőkkel bírnak – nagy fájlok, amelyek optimalizálatlanul ronthatják a teljesítményt.

Gyakori buktatók, amiket látunk (és javítunk)

• A sizes teljes hiánya: A böngésző a srcset legnagyobb képét tölti le, mert 100vw-t feltételez. Mindig adj meg sizes-t – még egy egyszerű 100vw is jobb, mint a semmi.
• Mindenhez JPEG használata: Sok csapat továbbra is csak JPEG formátumban szolgálja ki a képeket. 2026-ra nincs mentség – a WebP és AVIF érett technológiák, és a hozzáadásuk minimális erőfeszítést igényel.
• Túlzott lusta betöltés: Minden loading="lazy" jelölésű kép késlelteti az első értelmes megjelenítést. Használj loading="eager"-t a kritikus képeknél, és fontold meg a hőskép előtöltését <link rel="preload" as="image" href="..."> segítségével a maximális LCP-sebesség érdekében.
• Animált formátumok tartalékának hiánya: Ha animált AVIF-et használsz (amelynek gyenge a támogatottsága), adj meg WebP vagy GIF tartalékot a <picture> elemmel.
• Képek menet közbeni kódolása szerver nélküli függvényekben: Az AVIF-kódolás CPU-igényes. A kérések hirtelen megugrása időtúllépéshez vagy költségnövekedéshez vezethet. Mindig előre generáld le az eszközöket a build során, kivéve a felhasználók által feltöltött képeket, amelyeket nem lehet előre elkészíteni.

Azt is láttuk, hogy csapatok egyetlen képforrásra támaszkodnak verziókezelés nélkül. Amikor egy tervező frissít egy hősképet, a régi fájl felülíródik, ami megtöri a CDN-gyorsítótárat. Használj tartalomhash-eket a fájlnevekben (pl. hero-a1b2c3.avif), hogy az új verziók új URL-t kapjanak, a régiek pedig korlátlanul gyorsítótárazhatók legyenek.

Eszközajánlások

A CLI-t kedvelő fejlesztőknek a cwebp (a libwebp része) és az avifenc (a libavif része) szilárd és szkriptelhető megoldások. Node.js folyamatokhoz a sharp verhetetlen – gyors, minden formátumot kezel, és képes AVIF-et is előállítani (ehhez a libvips-nek AVIF-támogatással kell készülnie). Az alkalmi összehasonlításokhoz a Squoosh-t vagy olyan compare eszközöket használunk, mint az icdif (Image Compare Diff).

Nagy méretű projektek esetén érdemes megfontolni egy képekhez készült CDN-t, mint a Cloudinary, az imgix vagy a Fastly Image Optimizer. Ezek URL-paraméterek segítségével automatizálják az átméretezést és a formátum-egyeztetést, és gyakran a saját gyorsítótár-rétegükön kezelik az AVIF kódolást, így nem az eredeti szerver CPU-ját terhelik. Ugyanakkor figyelni kell a bezártságra és a költségekre – sok képet tartalmazó oldal esetén a havi számla jelentős lehet. Gyakran javasoljuk a hibrid megközelítést: előre generáljuk a leggyakoribb méreteket és formátumokat, a CDN-re pedig a ritka töréspontokat vagy a felhasználói feltöltéseket bízzuk.

Ha CMS-t vagy statikus oldalgenerátort használsz, a legtöbb keretrendszerhez léteznek bővítmények (pl. @next/image Next.js-hez, gatsby-plugin-sharp Gatsby-hez, eleventy-img Eleventy-hez). Ezek automatikusan kezelik a generálást és a jelölést, de javasoljuk, hogy ellenőrizd az alapértelmezett minőségi beállításokat – ezek általában konzervatívak (veszteségmentes vagy majdnem veszteségmentes) a panaszok elkerülése érdekében, ami felesleges bájtokat eredményezhet.

A lényeg

A képoptimalizálás 2026-ban a kompromisszumokról szól: az AVIF a legtöbb bájtot spórolja meg, de CPU-igényes; a WebP a megbízható középút. A reszponzív méreteknek pontosnak kell lenniük, nem közelítőnek. A lusta betöltés szinte automatikus, de átgondolt alkalmazást igényel, hogy ne rontsa az LCP-t. Egy jól hangolt képcsővezeték drámaian csökkentheti az oldal súlyát – ez közvetlen nyereség a felhasználói élmény, a Core Web Vitals és a konverziós arányok terén.

Olyan oldalakhoz építettünk csővezetékeket, amelyek havonta több tízmillió optimalizált képet szolgálnak ki. Az elvek mérettől függetlenül ugyanazok: kódolás build időben, biztonsági visszaesés, reszponzív méretezés, valamint lusta, de nem mohó betöltés. Ha szeretnéd felülvizsgálni a jelenlegi képstratégiádat, vagy segítségre van szükséged egy csővezeték megvalósításához, vedd fel a kapcsolatot a DigiForge-dzsal – általában már az első körben jelentősen csökkenteni tudjuk az oldal súlyát.