WebP: teljes útmutató

A WebP a Google által fejlesztett képformátum, amely veszteséges és veszteségmentes tömörítést, átlátszóságot és animációt is támogat egyetlen fájltípusban. A legtöbb weboldalon JPEG és PNG helyett használva kisebb fájlméretet ad hasonló minőség mellett, így gyorsabb lesz a betöltés. A modern böngészők támogatják, a régiekhez a picture elemmel adhatsz tartalék formátumot.

Alapfogalmak

Mielőtt bármit konvertálnál, érdemes tisztán látni, mit is tud ez a formátum, és miben különbözik azoktól, amelyeket eddig használtál. A WebP nem csodaszer: egy eszköz, amely bizonyos képtípusoknál látványos megtakarítást hoz, másoknál alig számít. A döntéseidet csak akkor hozhatod meg jól, ha érted a fogalmakat. A képoptimalizálás tágabb összefüggéseit a Kép SEO: teljes útmutató foglalja össze, itt kifejezetten a formátumra koncentrálunk.

Mi az a WebP?

A WebP egy raszteres képformátum, amelyet a Google mutatott be, és a VP8 videokodek képkocka-tömörítési technikájára épül. A fájl egy RIFF nevű konténerbe kerül, ezért egyetlen fájlban több adattípust is tárolhat: magát a képet, átlátszósági csatornát, színprofilt, metaadatot vagy animációs képkockákat. A kiterjesztése .webp, a MIME-típusa image/webp. Ez utóbbi fontos, mert a szervernek ezzel a típussal kell kiszolgálnia a fájlt, különben egyes böngészők vagy proxyk hibásan kezelhetik.

Veszteséges és veszteségmentes mód

A formátum két, egymástól lényegesen eltérő kódolást kínál. A veszteséges mód a JPEG-hez hasonlóan eldob olyan képinformációt, amelyet a szem kevésbé érzékel, cserébe jóval kisebb fájlt ad. A veszteségmentes mód a PNG-hez hasonlóan minden pixelt pontosan megőriz. A kettő között létezik egy köztes megoldás is, a közel veszteségmentes (near-lossless) beállítás, amely apró pixelérték-módosításokkal segíti a jobb tömöríthetőséget, de vizuálisan szinte érintetlen marad.

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

A WebP támogatja az alfa-csatornát, vagyis az átlátszó hátteret, méghozzá veszteséges módban is. Ez lényeges különbség a JPEG-hez képest, amely egyáltalán nem tud átlátszóságot. Animált WebP is készíthető, amely sok esetben a GIF kiváltására alkalmas, mert 24 bites színt és átlátszóságot is kezel, míg a GIF csak 256 színnel dolgozik.

Összehasonlító táblázat

Tulajdonság	JPEG	PNG	GIF	WebP
Veszteséges tömörítés	Igen	Nem	Nem	Igen
Veszteségmentes tömörítés	Nem	Igen	Igen (256 szín)	Igen
Átlátszóság	Nem	Igen	Csak teljes vagy semmi	Igen, fokozatos is
Animáció	Nem	Csak APNG változatban	Igen	Igen
Böngészőtámogatás	Univerzális	Univerzális	Univerzális	Modern böngészők

Gyakori tévhit: a WebP mindig jobb

Sokan úgy gondolják, hogy a WebP minden helyzetben kisebb fájlt ad. Ez nem igaz. Egy már erősen tömörített, kis felbontású JPEG-et WebP-be alakítva előfordulhat, hogy a méret alig csökken, vagy akár nő, miközben a minőség romlik, mert kétszer tömörítetted a képet. A formátum előnye akkor jön ki igazán, ha jó minőségű forrásból dolgozol. Az is tévhit, hogy a WebP önmagában javítja a rangsorolást: a keresőmotor nem a formátumot jutalmazza, hanem a gyorsabb oldalt és a jobb felhasználói élményt, amelyhez a kisebb kép hozzájárulhat.

Hogyan működik?

A működés megértése segít abban, hogy ne vakon állítsd a minőségi csúszkát. Ha tudod, mit csinál a kódoló, előre megsejtheted, melyik képnél érdemes erősebben tömöríteni, és melyiknél kell óvatosnak lenned. Nem kell kodekmérnöknek lenned, de a főbb lépéseket érdemes ismerni.

A veszteséges kódolás lépései

A veszteséges WebP prediktív kódolást használ, ami a VP8 videotömörítésből ered. A folyamat leegyszerűsítve így néz ki:

A kódoló a képet makroblokkokra bontja, ezek kis négyzet alakú pixelcsoportok.
Minden blokknál megpróbálja megjósolni a tartalmat a már kódolt szomszédos pixelek alapján (függőleges, vízszintes, átlagoló és egyéb előrejelzési módokkal).
Csak a jóslat és a valós érték közötti különbséget, a maradékot tárolja.
Ezt a maradékot frekvenciatartományba alakítja, majd kvantálja, vagyis a kevésbé fontos részleteket durvábban kerekíti. Itt keletkezik a veszteség.
Végül entrópiakódolással tömöríti a kapott adatot.

Ebből következik egy gyakorlati szabály: a nagy, egyszínű vagy lágyan átmenő felületek nagyon jól jósolhatók, ezért kevés adatot igényelnek. A sok apró részletet, zajt, éles textúrát tartalmazó fotók nehezebben tömöríthetők, ott a minőségi beállítás csökkentése hamarabb látható hibákat okoz.

A veszteségmentes kódolás

A veszteségmentes mód más technikákat alkalmaz. Ezek között szerepel a pixelek előrejelzése a szomszédok alapján, színtér-transzformáció, a már előfordult pixelminták visszahivatkozása, valamint színpaletta használata, ha a kép kevés színből áll. Emiatt képernyőképeknél, logóknál, ikonoknál és diagramoknál a veszteségmentes WebP gyakran jobban teljesít, mint a veszteséges, hiszen az éles éleket a veszteséges kódolás hajlamos elmosni.

Az alfa-csatorna kezelése

Az átlátszóság külön adatfolyamként tárolódik. Ennek az a következménye, hogy egy terméket átlátszó háttérrel bemutató fotónál a színes részt veszteségesen tömörítheted, az átlátszósági maszkot pedig veszteségmentesen. Ez az egyik legnagyobb gyakorlati előny a PNG-vel szemben: egy átlátszó hátterű termékfotó PNG-ként gyakran nagy fájl, WebP-ként pedig jellemzően jóval kisebb lehet.

Hogyan kerül a böngészőhöz?

A böngésző a kérésben egy Accept fejlécet küld, amelyben jelzi, milyen képformátumokat fogad el. Erre két módon reagálhat a weboldal:

Kliensoldali választás: a HTML-ben a picture elem több forrást kínál, és a böngésző maga választja ki az elsőt, amelyet támogat.
Szerveroldali tartalomegyeztetés: a szerver vagy a CDN az Accept fejléc alapján ugyanazon az URL-en WebP-t vagy JPEG-et küld. Ilyenkor a Vary: Accept fejléc beállítása szükséges, hogy a gyorsítótárak ne keverjék össze a változatokat.

Határeset: nagyon nagy képek

A WebP-nek van méretkorlátja: egy kép mindkét dimenzióban legfeljebb 16383 pixel lehet. Webes megjelenítésnél ez szinte sosem okoz gondot, de ha panorámaképeket, nagy felbontású térképeket vagy nyomdai forrásokat konvertálsz automatikusan, a folyamat ezeknél hibára futhat. Érdemes a konvertáló szkriptbe egy előzetes méretellenőrzést tenni, és az ilyen képeket előbb lekicsinyíteni, ami webes célra amúgy is indokolt.

Fő módszerek

A WebP bevezetésére több út létezik, és a választás leginkább attól függ, milyen rendszeren fut az oldalad, mennyi képed van, és mennyire szeretnéd automatizálni a folyamatot. Az alábbiakban a gyakorlatban elterjedt módszereket nézzük végig, majd egy döntési szabályt és egy kidolgozott példát is kapsz.

1. Kézi konvertálás grafikus eszközzel

Kis oldalnál, néhány tucat képnél a kézi konvertálás teljesen elfogadható. A Google által indított Squoosh webes felületen egymás mellett láthatod az eredeti és a tömörített képet, és azonnal látod a méretkülönbséget. Képszerkesztő programok közül több is tud WebP-be exportálni. Ennek előnye, hogy minden képnél tudatosan döntesz, hátránya, hogy nem skálázható, és könnyű elfelejteni egy-egy új feltöltésnél.

2. Parancssoros konvertálás

A Google libwebp csomagjában található cwebp parancs a legközvetlenebb eszköz. Egy fotó konvertálása például így nézhet ki: cwebp -q 80 eredeti.jpg -o kimenet.webp. A -q kapcsolóval a minőséget állítod 0 és 100 között, a -lossless kapcsolóval veszteségmentes kódolást kérsz. Ugyanígy használható az ImageMagick is, illetve Node.js környezetben a Sharp könyvtár. Ezekkel egyetlen szkript akár több ezer képet is feldolgoz.

3. CMS-bővítmény vagy beépített támogatás

A legtöbb tartalomkezelő rendszerhez létezik képoptimalizáló bővítmény, amely feltöltéskor automatikusan elkészíti a WebP változatot, és gondoskodik a kiszolgálásról. A WordPress újabb verziói maguk is kezelik a WebP feltöltést. Ennél a módszernél ellenőrizd, hogy a bővítmény hogyan szolgálja ki a képeket: picture elemmel, szerveroldali átírással, vagy egyszerűen lecseréli a fájlt. Mindháromnak más következménye van a gyorsítótárazásra és a régi böngészőkre.

4. CDN vagy képszolgáltatás

Képekre szakosodott CDN-ek és képátalakító szolgáltatások menet közben, az Accept fejléc alapján állítják elő a megfelelő formátumot és méretet. Ez a legkényelmesebb megoldás nagy oldalaknál, mert a forrásképeket érintetlenül hagyhatod. Cserébe függsz a szolgáltatótól, és érdemes ellenőrizni, hogy a képek URL-je stabil marad-e, mert a képkeresőben való megjelenéshez az is számít.

A picture elem helyes használata

Ha a kliensoldali megoldást választod, a szerkezet egyszerű: a picture elemen belül egy source elem image/webp típussal és a WebP fájllal, utána egy img elem a JPEG vagy PNG tartalékkal. Az alt szöveget, a width és height attribútumot, valamint a loading beállítást az img elemre teszed, mert ez a ténylegesen megjelenő elem. Az alt szöveg megfogalmazásáról részletesen az Alt text: teljes útmutató ír.

Döntési szabály: melyik képhez milyen beállítás?

Képtípus	Javasolt mód	Kiinduló beállítás
Fotó, termékkép, hero kép	Veszteséges	Minőség 75 és 85 között, vizuális ellenőrzéssel
Átlátszó hátterű termékfotó	Veszteséges, alfa-csatornával	Minőség 80 körül
Logó, ikon, kevés színű grafika	Veszteségmentes	Lossless, vagy SVG, ha vektoros a forrás
Képernyőkép szöveggel	Veszteségmentes vagy közel veszteségmentes	Near-lossless kipróbálása
Rövid animáció	Animált WebP	GIF helyett, hosszabbnál videó jobb

A számok kiindulópontok, nem szabályok. Mindig nézd meg az eredményt valós megjelenítési méretben, ne nagyítva és ne csak a fájlméretet.

Kidolgozott példa egy webshop kategóriaoldalára

Vegyünk egy szemléltető esetet: egy kategóriaoldalon 24 termékkép jelenik meg, mindegyik 800 pixel széles JPEG, a teljes képsúly nagyjából 3 MB. A munkafolyamat:

Visszakeresed az eredeti, tömörítetlen vagy jó minőségű forrásképeket, nem a már feltöltött JPEG-eket konvertálod.
Kiválasztasz három jellemző képet: egy világos, egy sötét és egy részletgazdag terméket.
Mindhármat elkészíted 70, 80 és 90 minőséggel, és valós méretben összehasonlítod.
A legalacsonyabb olyan értéket választod, amelynél egyik képen sem látsz zavaró hibát.
Ezzel a beállítással kötegelten konvertálod mind a 24 képet, és a kiszolgálást picture elemmel vagy a CMS-sel oldod meg.
Utána méréssel ellenőrzöd a képsúlyt és a betöltési mutatókat.

Ha a szemléltető példában a képsúly 3 MB-ról mondjuk 1,8 MB-ra csökken, az mobilneten érezhető különbség, de a pontos arány minden oldalon más lesz, ezért mindig a saját mérésedre hagyatkozz.

Gyakori hibák

A WebP bevezetése egyszerűnek tűnik, mégis rengeteg oldalon látni olyan megoldást, amely rosszabb eredményt ad, mint ha maradtak volna a régi formátumnál. A legtöbb hiba nem a formátumból, hanem a folyamatból fakad. Az alábbi lista a leggyakoribb buktatókat gyűjti össze, mindegyiknél azzal, hogyan javíthatod.

Már tömörített képek újratömörítése

Ez a leggyakoribb hiba. Ha egy 60 százalékos minőséggel mentett JPEG-et alakítasz WebP-vé, a kódoló a JPEG hibáit is megpróbálja hűen leképezni, ráadásul hozzáteszi a saját veszteségét. Az eredmény kockás, mosott kép, gyakran alig kisebb fájlmérettel. Mindig a legjobb elérhető forrásból dolgozz. Ha nincs eredeti, legalább a lehető legnagyobb felbontású változatot használd, és a minőséget ne vidd túl alacsonyra.

A méretezés kihagyása

A formátumváltás nem helyettesíti a helyes képméretet. Egy 4000 pixel széles WebP, amely 400 pixeles dobozban jelenik meg, sokkal nagyobb, mint egy jól méretezett JPEG. Előbb méretezz, aztán tömöríts. Reszponzív oldalon készíts több szélességet, és a srcset attribútummal kínáld fel őket, hogy a telefon ne töltse le az asztali változatot.

Hiányzó tartalék formátum

A modern böngészők szinte mind támogatják a WebP-t, de ha a közönséged egy része régi eszközről, régi beágyazott böngészőből vagy speciális szoftverből érkezik, tartalék nélkül ők üres képet látnak. A picture elemmel vagy szerveroldali egyeztetéssel ez könnyen elkerülhető. Gondolj azokra a helyekre is, ahol a képed nem böngészőben jelenik meg: egyes e-mail kliensek, megosztási előnézetek vagy külső platformok nem feltétlenül kezelik a WebP-t. Az Open Graph megosztási képnél ezért sokan biztonsági okból JPEG-et használnak.

Vary fejléc nélküli szerveroldali kiszolgálás

Ha ugyanazon az URL-en a böngészőtől függően más formátumot küldesz, de nem állítod be a Vary: Accept fejlécet, egy köztes gyorsítótár eltárolhatja a WebP változatot, és azt adhatja egy olyan kliensnek is, amely nem tudja megjeleníteni. Ez nehezen reprodukálható, időszakos hibákat okoz. Ellenőrizd a válaszfejléceket, és nézd meg a CDN dokumentációját is.

Hibás MIME-típus

Régebbi szerverkonfigurációk nem ismerik a .webp kiterjesztést, és általános bináris típusként szolgálják ki. Ilyenkor egyes böngészők nem jelenítik meg a képet, vagy letöltésre kínálják. A javítás a szerver beállításaiban egy sor, de ha nem tudsz róla, sokáig keresheted a hiba okát.

Egyetlen minőségi érték mindenre

Ha minden képet ugyanazzal a beállítással konvertálsz, a logók elmosódnak, a fotók pedig feleslegesen nagyok maradhatnak. A képtípus szerinti szétválasztás, amelyet a Fő módszerek fejezet táblázata mutat, kis plusz munkával sokkal jobb eredményt ad.

Az SEO-elemek elvesztése a cserénél

Bővítmények és szkriptek néha lecserélik a fájlneveket, eltávolítják az alt szöveget, vagy új URL-re teszik a képeket átirányítás nélkül. A képkeresőből érkező forgalom ilyenkor visszaeshet, mert a keresőnek újra fel kell fedeznie és indexelnie a képeket. Tartsd meg a beszédes fájlneveket, az alt szövegeket és lehetőleg az URL-szerkezetet is.

Ellenpélda: amikor jobb kihagyni a WebP-t

Van, amikor a WebP nem a jó válasz. Vektoros logónál az SVG szinte mindig kisebb és élesebb. Hosszabb animációnál egy rövid, néma videó gyakran sokkal kisebb, mint egy animált WebP. Ha pedig nyomtatható, letölthető anyagot kínálsz, a felhasználónak valószínűleg egy univerzálisan megnyitható JPEG vagy PNG kényelmesebb.

Mérés

A konvertálás csak akkor sikeres, ha számokkal is igazolni tudod. A mérés két kérdésre ad választ: valóban csökkent-e a letöltött adatmennyiség, és ez javított-e a felhasználók által érzékelt sebességen. A második nem következik automatikusan az elsőből, ezért mindkettőt érdemes vizsgálni.

Mit mérj?

Képsúly oldalanként: a letöltött képek összmérete egy adott oldalon, a konvertálás előtt és után.
Largest Contentful Paint (LCP): ha az oldal legnagyobb eleme egy kép, a mérete közvetlenül befolyásolhatja ezt a Core Web Vitals mutatót.
Cumulative Layout Shift (CLS): a formátumcsere nem okozhat elcsúszást, de ha közben elvesznek a width és height attribútumok, romolhat.
Vizuális minőség: szemmel, valós megjelenítési méretben, több eszközön.
Képkeresési forgalom: a csere után néhány héttel érdemes megnézni, nem esett-e vissza.

Eszközök

A böngésző fejlesztői eszközeinek Hálózat lapján képtípusra szűrve látod, hogy a böngésző valóban WebP-t kapott-e, és mekkora fájlt. A Type oszlopban a webp jelzés, a válaszfejlécekben a content-type mező a beszédes. A Lighthouse és a PageSpeed Insights jelzi, ha a képek kiszolgálásán lehetne javítani, például modernebb formátummal vagy jobb méretezéssel. A Search Console Core Web Vitals jelentése valós felhasználói adatokra épül, ezért ott a változás lassabban, néhány hetes késéssel jelenik meg.

Mérési folyamat lépésről lépésre

Válassz ki három-öt reprezentatív oldaltípust (főoldal, kategória, termék vagy cikk).
Rögzítsd a kiinduló állapotot: képsúly, LCP laboradatban, valamint a terepi adatok, ha vannak.
Végezd el a konvertálást egy oldaltípuson, ne az egész oldalon egyszerre.
Ismételd meg a mérést ugyanazzal a beállítással, ugyanazon az eszközprofilon.
Ellenőrizd a Hálózat lapon, hogy a böngésző tényleg WebP-t kap, és régi böngészőben vagy annak szimulációjában a tartalék is működik.
Ha az eredmény jó, terjeszd ki a többi oldaltípusra, és néhány hét múlva nézd meg a terepi adatokat is.

Ellenőrzőlista a bevezetés után

A szerver image/webp típussal szolgálja ki a fájlokat.
Szerveroldali egyeztetésnél be van állítva a Vary: Accept fejléc.
Minden kép mérete megfelel a megjelenítési méretnek, a srcset több szélességet kínál.
Az img elemen megmaradt az alt, a width és a height attribútum.
A fájlnevek beszédesek, az URL-ek nem változtak, vagy átirányítással vannak kezelve.
A logók és képernyőképek nem mosódtak el.
A megosztási képek külső platformokon is megjelennek.
Az LCP-elemként szereplő kép nincs késleltetett betöltésre állítva.

Hogyan értelmezd az eredményt?

Ha a képsúly jelentősen csökkent, de az LCP alig javult, a szűk keresztmetszet máshol lehet: lassú szerverválasz, blokkoló szkriptek, későn felfedezett hero kép. Ilyenkor a formátumváltás jó lépés volt, csak nem elég. Ha viszont a képsúly alig változott, nézd meg, nem már tömörített forrásokból dolgoztál-e, illetve nem a méretezés hiányzik-e. A WebP egy elem a képoptimalizálásban, és akkor hoz igazi eredményt, ha a méretezéssel, a betöltési sorrenddel és a gyorsítótárazással együtt kezeled.

Kapcsolódó részletes útmutatók

A WebP csak egy darabja a képek és videók keresőoptimalizálásának. Ha a formátum után a teljes képkezelési folyamatot is rendbe tennéd, az alábbi útmutatók segítenek továbblépni: a tágabb témakör áttekintésétől a fájlnevek, méretezés és indexelés kérdésein át az alternatív szövegek megírásáig.

Érdemes a sorrendet is átgondolni. Először a képek technikai alapjait tedd rendbe (méret, formátum, betöltés), utána az értelmezhetőséget (alt szöveg, környező szöveg, fájlnév), végül a mérést és a képkeresési teljesítmény figyelését. Így minden lépés az előzőre épül, és nem kell ugyanazokat a képeket többször átnézned.

További olvasnivaló

Kép és videó SEO: a teljes témakör áttekintése, képektől a videókig.
Kép SEO: teljes útmutató: méretezés, fájlnevek, betöltés és képindexelés egy helyen.
Alt text: teljes útmutató: hogyan írj hasznos, akadálymentes és keresőbarát alternatív szöveget.