AVIF: teljes útmutató

Az AVIF az AV1 videokodekre épülő képformátum, amely azonos vizuális minőség mellett jellemzően kisebb fájlt ad, mint a JPEG vagy a WebP. Weboldalon úgy érdemes használni, hogy a <picture> elemben AVIF forrást kínálsz, mellé WebP vagy JPEG tartalékot teszel, a minőséget szemre és mérőszámokkal hangolod, majd az LCP és a letöltött bájtok alapján ellenőrzöd az eredményt.

Alapfogalmak

Az AVIF (AV1 Image File Format) az Alliance for Open Media által fejlesztett, jogdíjmentes képformátum. A képadatot az AV1 videokodek intra-frame tömörítésével kódolja, a tárolásra pedig a HEIF konténerstruktúrát használja. Ez a gyakorlatban annyit jelent, hogy egy AVIF kép lényegében egyetlen, nagyon hatékonyan tömörített videókocka, a szükséges metaadatokkal együtt.

Mielőtt bármit beállítasz, érdemes tisztán látni néhány fogalmat, mert a legtöbb rossz döntés abból fakad, hogy valaki a "kisebb fájl" ígéretét összekeveri a "jobb kép" ígéretével. Az AVIF nem varázsol jobb minőséget a forrásból, csak ugyanazt a látványt próbálja kevesebb bájtból előállítani.

Veszteséges és veszteségmentes tömörítés

Az AVIF mindkét módot ismeri. Fotóknál szinte mindig a veszteséges módot használod, mert itt jön ki az előnye. Veszteségmentes módban a fájlméret gyakran nem lesz látványosan kisebb, mint egy jól optimalizált PNG vagy veszteségmentes WebP, sőt bizonyos grafikáknál nagyobb is lehet. Ezért a "mindent AVIF-be" szabály ikonoknál és képernyőképeknél nem automatikusan jó döntés.

Bitmélység, színtér és HDR

Az AVIF támogatja a 8, 10 és 12 bites színmélységet, a széles színteret és a HDR tartalmat. Egy átlagos webshop termékfotójánál ez ritkán számít, de gradienseknél (égbolt, stúdióháttér) a magasabb bitmélység csökkentheti a sávosodást. A krómaalmintavételezés (4:4:4, 4:2:0) szintén fontos: a 4:2:0 kisebb fájlt ad, de éles, színes szövegnél vagy vékony vonalaknál elmosódott széleket okozhat.

Átlátszóság és animáció

Az AVIF kezel alfa csatornát, így átlátszó hátterű termékképekhez is használható, és képes animált tartalmat is tárolni. Animált GIF helyett azonban sokszor egy rövid, néma videó a praktikusabb megoldás, mert jobban kontrollálható a lejátszás és a betöltés.

Formátumok összevetése

Szempont	JPEG	WebP	AVIF
Tömörítési hatékonyság fotón	Alap	Jobb	Jellemzően a legjobb
Átlátszóság	Nincs	Van	Van
HDR, magas bitmélység	Nincs	Nincs	Van
Kódolási sebesség	Gyors	Gyors	Lassabb
Böngészőtámogatás	Univerzális	Szinte univerzális	Modern böngészőkben széles

A táblázat irányt mutat, nem abszolút sorrendet. Vannak képek (például erős zajjal teli fotók vagy nagyon kicsi bélyegképek), ahol a WebP és az AVIF közti különbség elhanyagolható, és van, ahol a JPEG egy modern kódolóval (például MozJPEG) meglepően közel kerül. Az AVIF tehát a Kép SEO: teljes útmutató teljesítményoldali eszköztárának egyik eleme, nem önálló cél.

Gyakori tévhit: az AVIF rangsorolási tényező

A képformátum önmagában nem rangsorolási jel. Az AVIF közvetetten hat: kisebb képpel gyorsabb lehet az oldal, javulhat a Largest Contentful Paint, ami a felhasználói élményt és az oldalélmény-jeleket érinti. Ha a képeid már most is kicsik és gyorsan töltenek, az AVIF-re váltás SEO-hatása minimális lehet.

Hogyan működik?

Az AVIF működését két szinten érdemes megérteni: mit csinál a kódoló a képpel, és hogyan jut el a megfelelő formátum a látogató böngészőjébe. Az első a minőségi döntéseidet, a második a technikai bevezetést határozza meg.

A kódolás lépései egyszerűsítve

Blokkokra bontás: a kódoló a képet változó méretű blokkokra osztja. Sima felületeken nagy blokkokat használ, részletgazdag területeken kicsiket.
Predikció: minden blokkra megbecsüli a tartalmat a szomszédos, már kódolt pixelekből (sokféle irányú és mintázatú predikciós móddal).
Maradék kódolása: csak a becslés és a valóság közti különbséget tárolja, transzformáció és kvantálás után.
Szűrés: a dekódolás utáni szűrők csökkentik a blokkosodást és a gyűrűsödést, ezért az AVIF erős tömörítésnél inkább "elkenődik", mint kockásodik.
Entrópiakódolás: a végső adatfolyam tömörítése.

Ebből következik egy fontos gyakorlati tulajdonság: az AVIF hibái máshogy néznek ki, mint a JPEG-é. Túltömörített AVIF-nél a finom textúrák (bőr pórusai, szövet, fű) simává, műanyagszerűvé válnak. Ezt könnyű elnézni, ha csak kicsinyítve nézed a képet, ezért a minőség ellenőrzését mindig 100 százalékos nagyításon is végezd el.

Miért lassú a kódolás?

A kódoló rengeteg lehetőséget próbál ki blokkméretre és predikcióra. A legtöbb eszközben van egy sebesség (speed vagy effort) paraméter: a lassabb beállítás jobb tömörítést ad, de többszörös időbe kerülhet. Statikus, előre generált képeknél ez nem gond, igény szerinti (on-the-fly) konverziónál viszont szerverterhelést és első kérésnél késleltetést okozhat. Ilyenkor a gyorsítótárazás nem opcionális.

Hogyan kapja meg a böngésző az AVIF-et?

Két fő mechanizmus létezik:

A <picture> elem: több <source> elemet adsz meg type="image/avif" és type="image/webp" attribútummal, az <img> pedig a JPEG tartalékot tartalmazza. A böngésző az első általa támogatott forrást választja.
Tartalomegyeztetés (content negotiation): a böngésző az Accept fejlécben jelzi, hogy elfogadja az image/avif típust, a szerver vagy a CDN pedig ugyanazon az URL-en AVIF-et küld vissza. Ilyenkor a válaszba kell a Vary: Accept fejléc, különben a gyorsítótár rossz formátumot adhat ki egy régebbi kliensnek.

A <picture> logikája egy példán

Egy termékoldali főképnél a forrássorrend: először AVIF, utána WebP, végül az <img> JPEG-gel, a width és height attribútumokkal, valamint az alt szöveggel. Az alt szöveg az <img> elemre kerül, nem a <source> elemekre, és formátumtól függetlenül ugyanaz marad. Ennek megírásáról az Alt text: teljes útmutató szól részletesen.

Hogyan látja a Google?

A Google Search dokumentációja a képkereséshez támogatott formátumok között az AVIF-et is felsorolja. A <picture> használatánál a Googlebot a modern böngészőhöz hasonlóan értelmezi a forrásokat, de a biztonság kedvéért az <img> src attribútumában mindig legyen egy indexelhető, működő tartalékkép. Ha a képeket image sitemapben is jelzed, ott a ténylegesen kiszolgált, elérhető URL-t add meg.

Fő módszerek

Az AVIF bevezetésére nincs egyetlen helyes út. A választás attól függ, hány képed van, milyen gyakran változnak, milyen a tárhelyed, és van-e CDN-ed. Az alábbiakban a négy leggyakoribb megközelítést veszem sorra, utána egy döntési szabályt és egy kidolgozott workflow-t.

1. Kézi vagy szkriptelt konverzió build közben

Statikus oldalaknál és kisebb képkészleteknél a legtisztább módszer: a forrásképekből egy build lépés generálja az AVIF, WebP és JPEG változatokat, több szélességben. Elterjedt eszközök erre a libavif parancssori kódolója (avifenc), a sharp Node.js-könyvtár és a Squoosh, amely egyedi képek kézi hangolására is alkalmas. Előnye a teljes kontroll, hátránya, hogy a build idő nő.

2. CMS-bővítmény vagy beépített funkció

Sok tartalomkezelő rendszerhez létezik bővítmény, amely feltöltéskor vagy háttérfolyamatban AVIF-változatot készít. Itt a legfontosabb ellenőrizni, hogy a bővítmény valóban <picture> elemet vagy tartalomegyeztetést használ-e, és mi történik, ha a szerver nem tud AVIF-et kódolni (egyes tárhelyeken a szükséges könyvtár hiányzik).

3. Képkiszolgáló CDN

A képoptimalizáló CDN-ek az eredeti képből igény szerint állítják elő a böngészőnek megfelelő formátumot és méretet. Nagy, gyakran változó katalógusnál ez a legkevesebb munka. Figyelj a gyorsítótár-kulcsra (a Vary fejlécre), a kanonikus kép URL-ekre, és arra, hogy a szolgáltató milyen alapértelmezett minőséggel kódol.

4. Szerveroldali tartalomegyeztetés saját infrastruktúrán

Ha a webszerver az Accept fejléc alapján dönt, előre generált AVIF fájlok mellett is működhet ugyanazzal az URL-lel. Ez rugalmas, de konfigurációs hibákra érzékeny, ezért csak akkor válaszd, ha van, aki karbantartja.

Döntési szabály

Helyzet	Javasolt módszer
Néhány száz kép, statikus vagy ritkán frissülő oldal	Build közbeni konverzió, <picture>
Szerkesztők töltenek fel naponta, CMS-alapú oldal	Megbízható bővítmény, háttérkonverzió
Több ezer termékkép, sok méretváltozat	Képkiszolgáló CDN
Saját szerver, DevOps-kapacitás, egységes URL-ek kellenek	Tartalomegyeztetés, Vary: Accept

Kidolgozott workflow egy termékfotóhoz

Indulj a legjobb elérhető forrásból (nem egy már tömörített JPEG-ből), mert a többszörös veszteséges tömörítés hibái összeadódnak.
Határozd meg a megjelenítési szélességeket a sablon alapján, például mobilon 400, tableten 800, asztalin 1200 pixel.
Kódolj AVIF-et két vagy három minőségi szinten, és nézd meg mindegyiket 100 százalékon, különösen a textúrás részeken.
Válaszd a legalacsonyabb minőséget, ahol még nem látsz zavaró simítást, majd ugyanezt csináld WebP-vel.
Rögzítsd a választott beállítást képtípusonként (fotó, átlátszó hátterű termék, grafika), hogy a következő képnél ne kelljen elölről kezdeni.

Szemléltető példa: tegyük fel, hogy egy 1200 pixel széles termékfotó JPEG-ben 240 kB, WebP-ben 170 kB, AVIF-ben 110 kB, és a három kép szemre azonos. Ha az oldalon ez az LCP elem, a megtakarított bájtok lassú mobilhálózaton érzékelhetően gyorsíthatják a megjelenést. A konkrét arányok képenként és kódolónként erősen eltérnek, ezért a saját képeiden mérj.

Mikor ne válts AVIF-re?

Ha egy kis ikonkészlet SVG-ben is megoldható, az szinte mindig jobb. Ha a képet a felhasználók letöltik és más programban nyitják meg (például nyomdai anyag, sajtókép), adj mellé JPEG vagy PNG letöltési lehetőséget, mert nem minden asztali szoftver kezeli az AVIF-et.

Gyakori hibák

Az AVIF bevezetése ritkán bukik el magán a formátumon. Sokkal gyakoribb, hogy egy apró konfigurációs vagy minőségi hiba elviszi a nyereséget, vagy rosszabb esetben láthatatlan képeket okoz egy látogatói csoportnál. Az alábbi hibák mindegyike előfordul éles oldalakon.

Hiányzó vagy rossz tartalékkép

Ha csak AVIF van, és nincs <picture> tartalék, a régebbi böngészőkben és egyes beágyazott nézetekben (bizonyos e-mail kliensek, alkalmazáson belüli böngészők, közösségi előnézetek) a kép nem jelenik meg. A közösségi megosztásnál használt og:image képhez különösen ajánlott JPEG vagy PNG formátumot használni, mert nem minden platform dolgozza fel megbízhatóan az AVIF-et.

Rossz MIME-típus a szerveren

Ha a szerver az .avif fájlt application/octet-stream típussal küldi, egyes böngészők nem jelenítik meg, vagy letöltésként kezelik. A helyes Content-Type: image/avif. Ezt a böngésző fejlesztői eszközeinek Network fülén egy kattintással ellenőrizheted.

Vary fejléc nélküli tartalomegyeztetés

Tartalomegyeztetésnél, ha a CDN vagy egy köztes proxy nem tudja, hogy a válasz az Accept fejlécen múlik, előfordulhat, hogy az első látogatónak kiszolgált AVIF kerül gyorsítótárba, és azt kapja egy olyan kliens is, amely nem tudja megjeleníteni. Ellenpéldaként a fordított helyzet is hiba: ha mindig a JPEG ragad be, egyszerűen elveszíted az AVIF előnyét, és ezt senki nem veszi észre.

Túltömörítés

A "minél kisebb, annál jobb" hozzáállás termékfotóknál kifejezetten káros. Ha a vásárló nem látja a szövet szerkezetét vagy a felület textúráját, az a konverziót ronthatja, és ezt semmilyen PageSpeed-pontszám nem kompenzálja. A minőséget képtípusonként válaszd meg, ne egyetlen globális értékkel.

A méretezés kihagyása

Egy 3000 pixel széles AVIF, amelyet 400 pixeles helyen jelenítesz meg, még mindig pazarlás. A formátumváltás nem helyettesíti a srcset és sizes attribútumokkal megoldott reszponzív méretezést. Sokszor a helyes méretezés nagyobb megtakarítást hoz, mint maga a formátum.

LCP kép lusta betöltése

Gyakori, hogy az optimalizálás közben minden képre bekerül a loading="lazy". A hajtás feletti főképnél ez késlelteti a betöltést, és rontja az LCP-t, akármilyen kicsi az AVIF. A főképnél inkább a fetchpriority="high" attribútum jöhet szóba.

Elveszett metaadatok és színprofil

Konverziókor a színprofil elhagyása miatt a színek fakóbbnak vagy túltelítettnek tűnhetnek. Ha a márkaszínek fontosak, ellenőrizd a kimenetet kalibrált kijelzőn és mobilon is. A személyes adatokat tartalmazó EXIF mezők (például GPS-koordináták) eltávolítása viszont kifejezetten hasznos.

Ellenőrzőlista bevezetés előtt

Minden <picture> elemben van JPEG vagy PNG tartalék az <img> src-ben.
Az .avif fájlok Content-Type fejléce image/avif.
Tartalomegyeztetésnél a válaszban szerepel a Vary: Accept.
Az <img> elemen van width, height és értelmes alt szöveg.
Az LCP kép nincs lusta betöltésre állítva.
A minőséget 100 százalékos nagyításon is ellenőrizted.
Az og:image továbbra is széles körben támogatott formátumú.
Az image sitemapben szereplő URL-ek valóban elérhetők és 200-as választ adnak.

Mérés

AVIF-bevezetés után két kérdésre kell választ kapnod: valóban kisebbek lettek-e a letöltött képek, és ez megjelent-e a felhasználói élményt mérő számokban. A kettő nem ugyanaz. Előfordul, hogy a képek mérete felére csökken, az LCP mégsem mozdul, mert a szűk keresztmetszet a szerver válaszideje vagy egy renderelést blokkoló szkript volt.

Mit mérj?

Mérőszám	Mit mutat	Hol nézed
Letöltött képbájtok oldalanként	A közvetlen megtakarítást	Böngésző fejlesztői eszközei, Network fül, típus szerinti szűrés
Kiszolgált formátum aránya	Hogy a látogatók mekkora része kap ténylegesen AVIF-et	CDN- vagy szervernaplók
LCP (laborban)	A főkép megjelenésének idejét kontrollált körülmények közt	Lighthouse, PageSpeed Insights
LCP (terepen)	Valós felhasználók tapasztalatát	Search Console Core Web Vitals jelentés, CrUX, saját RUM
Képkeresési forgalom	Hogy a változás nem rontotta-e a képek láthatóságát	Search Console, keresési típus: Kép

Labor és terepi adatok különbsége

A Lighthouse azonnal mutatja a hatást, de egyetlen szimulált eszközön és hálózaton. A terepi adatok a valós látogatókat tükrözik, viszont késleltetve frissülnek: a CrUX alapú értékek egy gördülő időablakot átlagolnak, így a változás hetek alatt jelenik meg teljes súllyal. Ne vonj le következtetést az első napok terepi adataiból.

Mérési eljárás lépésről lépésre

Válassz ki 5 és 10 közötti reprezentatív oldalt (főoldal, kategória, termék, blogcikk), ahol a fő elem kép.
Rögzítsd a kiinduló állapotot: képbájtok, LCP elem, labor LCP több futtatás mediánjaként.
Vezesd be az AVIF-et először ezeken a sablonokon.
Ismételd meg a labormérést azonos beállításokkal, és nézd meg a Network fülön, hogy tényleg AVIF töltődik-e (a Type oszlopban avif szerepel).
Ellenőrizd régebbi böngészővel vagy a fejlesztői eszközökben módosított Accept fejléccel, hogy a tartalék is működik.
Négy és hat hét elteltével hasonlítsd össze a terepi LCP-t és a képkeresési kattintásokat a kiinduló időszakkal.

Az eredmények értelmezése

Ha a képbájtok csökkentek, de az LCP nem javult, nézd meg a Lighthouse LCP bontását: a betöltési késleltetés (amikor a böngésző még nem fedezte fel a képet) gyakran nagyobb, mint maga a letöltési idő. Ilyenkor a kép felfedezhetőségén kell javítani (például ne CSS háttérképként vagy szkriptből töltsön), nem a formátumon.

Ha a dekódolási idő gyanús, gondolj arra, hogy nagy felbontású AVIF dekódolása gyengébb mobilokon több processzoridőt igényelhet. Ez ritkán döntő, de nagyon nagy hero képeknél érdemes tesztelni olcsóbb Android-eszközön is.

Mikor számít sikeresnek a bevezetés?

Gyakorlati döntési szabály: akkor tartsd meg a beállítást, ha a képbájtok érdemben csökkentek, a vizuális minőség szemrevételezéskor elfogadható, a terepi LCP nem romlott, és a képkeresési forgalom stabil maradt. Ha ezek közül bármelyik nem teljesül, a formátum helyett előbb a konfigurációt vizsgáld meg.

Kapcsolódó részletes útmutatók

Az AVIF a képoptimalizálás egyik rétege. Ahhoz, hogy a gyorsabb betöltés keresési láthatóságot is hozzon, a képek kontextusa, leírása és felfedezhetősége ugyanúgy számít. Az alábbi útmutatók ezeket a területeket dolgozzák fel részletesen, a formátumválasztáson túl.

Merre tovább?

Ha most kezded a képoptimalizálást, a teljes kép SEO folyamattal érdemes indulni, mert ott látod, hol helyezkedik el a formátumválasztás a fájlnevek, a méretezés és a környező szöveg mellett. Ha a technikai alapok rendben vannak, az alt szövegek és az image sitemap a következő logikus lépés, mert ezek segítenek abban, hogy a keresők megértsék és megtalálják a képeidet.

Kép és videó SEO: a teljes témakör áttekintése képekre és videókra.
Kép SEO: teljes útmutató: fájlnevek, méretezés, kontextus és teljesítmény egy folyamatban.
Alt text: teljes útmutató: hogyan írj hozzáférhető és kereső számára is értelmes alternatív szöveget.
Image sitemap: teljes útmutató: hogyan segítsd a képek felfedezését sitemapen keresztül.

Rövid összefoglaló ellenőrzőlista

Az AVIF-et <picture> elemmel vagy helyesen beállított tartalomegyeztetéssel szolgálod ki.
Minden képnek van széles körben támogatott tartaléka.
A minőséget képtípusonként hangoltad, nem globális értékkel.
A méretezés és a lusta betöltés helyesen van beállítva.
A hatást labor- és terepi adatokkal is mérted, elegendő idő elteltével.

WebP: teljes útmutató