WebP vs AVIF vs JPEG: le-am măsurat pe toate trei pe 12 imagini web

Orice articol despre WebP vs AVIF spune că AVIF e mai mic. Și al nostru spune asta, de cele mai multe ori. Am codat 12 imagini tipice de pe site-uri, de la scene fotorealiste la randări 3D și capturi de pagini, ca JPEG, WebP și AVIF, le-am adus la aceeași calitate vizuală și am măsurat octeții, timpul de codare și timpul de decodare în Chrome. AVIF a ieșit în mediană cu 20% mai mic decât WebP, iar JPEG a avut nevoie în mediană de cu 37% mai mulți octeți decât WebP. Dar pe cele trei imagini cu cea mai multă granulație AVIF a avut nevoie de mai mulți octeți decât WebP, cu setările folosite de majoritatea uneltelor s-a codat de 7,6 ori mai lent, iar pe serverul nostru costul ăsta e motivul pentru care site-ul acesta servește tot WebP.

Mărimea fiecărei imagini la calitatea WebP q85

Fiecare imagine are 1.600 px lățime, codată cu sharp 0.35.5 (mozjpeg, libwebp 1.6.0, libaom 3.15.1) pe 10 octombrie 2026. JPEG și AVIF au fost interpolate la scorul SSIM atins de WebP la calitatea 85, deci fiecare rând compară fișiere care arată la fel de bine după această măsură; q din paranteză e setarea care ajunge acolo. „Neatins”: JPEG a rămas sub această calitate chiar și la q95.

Trei formate într-un paragraf

JPEG e formatul pe care îl citesc de decenii toate browserele și toate uneltele. WebP e formatul Google, construit pe codecul video VP8. AVIF e formatul de imagine al AV1, codecul video al Alliance for Open Media. Toate trei comprimă fotografiile cu pierderi; WebP și AVIF pot face și imagini fără pierderi, transparență și animație. Întrebarea pentru un site e care dintre ele dă cel mai mic fișier la calitatea pe care ai publica-o, cât costă să-l produci și dacă îl poate vedea orice vizitator.

Cum am măsurat

Am ales 12 imagini de felul celor care ajung pe site-urile firmelor: două scene fotorealiste, un site de clinică cu o fotografie portret, șase randări 3D din ilustrațiile propriilor noastre articole și trei capturi de ecran ale unor pagini de pe site-ul acesta. Fiecare sursă a fost un PNG fără pierderi, redimensionat la 1.600 px lățime. Le-am codat cu sharp, biblioteca de imagini din spatele Next.js și al multor altor unelte, ca JPEG (mozjpeg) la opt setări de calitate între 50 și 95, ca WebP la aceleași opt și ca AVIF la unsprezece între 30 și 80, restul setărilor fiind cele implicite din sharp.

Ca să comparăm la aceeași calitate am măsurat SSIM, un scor standard de similaritate, între fiecare fișier și sursa lui, iar pentru fiecare imagine am luat scorul atins de WebP la calitatea 85, setarea pe care o folosește site-ul acesta. Apoi am citit de câți octeți au avut nevoie JPEG și AVIF ca să ajungă la același scor. Timpii de codare sunt timpi reali pe un Intel Core i7-6700K. Timpii de decodare au fost măsurați în Chrome 142 cu createImageBitmap, 12 runde pe fișier, în ordine rotită, după o rundă de încălzire. Niciuna dintre surse nu e o fotografie luată direct din aparat; scenele fotorealiste sunt randări, de aceea raportăm tipurile de imagini separat.

Mărimea fișierului la aceeași calitate

La calitatea pe care o servim, AVIF a fost în mediană cu 20% mai mic decât WebP, iar JPEG a fost în mediană cu 37% mai mare decât WebP. Avantajul AVIF a fost cel mai mare la capturile de ecran (30% în mediană) și la randarea simplă și curată a unei figurine într-un pat de spital, care a ieșit la jumătate din mărime. La scenele fotorealiste a fost între 19 și 33%. JPEG a fost cel mai mare fișier oriunde a reușit să atingă calitatea WebP; la capturile de ecran și la randările cu granulație n-a reușit, nici la calitatea 95.

La o calitate mai mică diferența crește. Raportat la WebP la calitatea 75, valoarea implicită din Next.js, AVIF a fost în mediană cu 27% mai mic, iar JPEG cu 56% mai mare. Față de sursele PNG fără pierderi, fișierele WebP au avut cam a douăsprezecea parte din mărime: 2,2 MB față de 26 MB pentru toate cele 12 imagini la un loc.

Unde pierde AVIF: granulație și zgomot fin

Pe trei imagini AVIF a avut nevoie de mai mulți octeți decât WebP, nu de mai puțini: cu 17% mai mulți la două dintre ele și cu 22% la a treia. Toate trei sunt randări cu granulație vizibilă, de tip film, și sunt cele mai „zgomotoase” trei imagini din set după o măsură simplă a detaliului de la pixel la pixel, între 24 și 28, față de 2 până la 16 la celelalte nouă. AVIF tinde să netezească genul ăsta de zgomot fin, iar păstrarea lui costă biți. Pentru că aceste trei sunt și printre cele mai mari fișiere, cele 12 fișiere AVIF la un loc au ieșit cu 1% mai mari decât cele 12 WebP; fără ele, AVIF a economisit 24% în total.

Așa că, dacă imaginile tale sunt fotografii cu granulație sau randări cu textură intenționată, testează-le înainte să schimbi formatul. Dacă sunt fotografii de produs curate, ilustrații sau capturi de ecran, AVIF va fi aproape sigur mai mic.

Codarea: unde se plătește costul AVIF

Cu setările implicite din sharp, AVIF s-a codat în mediană de 7,6 ori mai lent decât WebP: cam o secundă pe imagine aici, față de 0,15 secunde pentru WebP și 0,13 pentru JPEG. Raportul a variat între de 3 și de 15 ori, iar cele mai lente au fost imaginile mari și detaliate. Next.js codează AVIF cu un nivel de efort mai mic, effort 3 în loc de 4, implicit în sharp; la effort 3, AVIF a durat de 1,8 ori mai mult decât WebP, iar fișierele au fost în mediană cu 4% mai mari la aceeași setare de calitate.

Costul AVIF se plătește în momentul codării, așa că dacă contează depinde de unde se întâmplă asta. Într-un pas de build sau într-un CDN care codează fiecare imagine o singură dată și o păstrează în cache, o secundă pe imagine nu e nimic. Pe un server care codează la prima cerere, primul vizitator o așteaptă. Am măsurat asta pe propriul nostru hosting înainte să decidem: o imagine de portofoliu de 24 de megapixeli a durat 40,07 secunde ca AVIF, față de 2,57 secunde ca WebP, prin același optimizator Next.js, ca să economisească 17% din octeți, și a ținut un procesor ocupat tot timpul ăsta. Site-ul acesta servește WebP din acest motiv.

Decodarea în browser: practic la egalitate

Decodarea a durat cam la fel pentru AVIF și WebP: AVIF a fost în mediană cu 3% mai lent, în jur de 14 milisecunde pentru o imagine de 1.600 de pixeli pe un desktop, iar JPEG a fost cu 20% mai rapid decât WebP. Încetinirea procesorului de patru ori în Chrome n-a schimbat aproape nimic, pentru că Chrome decodează imaginile în afara firului principal. Descărcarea e cea care contează: la 1,6 Mbps, viteza cu care Lighthouse simulează o conexiune mobilă, fișierul AVIF median a ajuns cu 69 de milisecunde mai devreme decât varianta lui WebP, iar scena fotorealistă mai mică cu 128 de milisecunde. Asta e diferența care se vede în Largest Contentful Paint când imaginea e cel mai mare element din pagină.

Suportul în browsere în 2026

Ambele formate sunt sigure pentru aproape orice vizitator. Can I Use pune suportul global la 96,74% pentru WebP și 95,35% pentru AVIF. AVIF funcționează în Chrome de la versiunea 85, în Firefox de la 93, în Safari pe iPhone de la iOS 16 și în Edge de la 121; Safari pe Mac îl listează ca parțial, pentru că are nevoie de macOS Ventura sau mai nou și nu suportă sinteza de zgomot din AVIF. Puținele browsere rămase fără niciunul dintre ele sunt motivul pentru care o variantă de rezervă încă are sens: un element picture care oferă întâi AVIF, apoi WebP, apoi JPEG, sau un serviciu de imagini care alege formatul după ce spune browserul că acceptă.

Ce format să folosești

Folosește AVIF acolo unde imaginile se codează o singură dată, din timp, și WebP acolo unde un server le codează la cerere. Un site static, un pipeline de build sau un CDN de imagini își permit timpul de codare al AVIF și primesc pentru el fișiere cu o cincime mai mici, cu WebP ca variantă de rezervă. Un optimizator găzduit pe un hardware modest, ca al nostru, o duce mai bine cu WebP, care e deja cam cu un sfert mai mic decât JPEG. Păstrează JPEG doar ca ultimă variantă de rezervă. Orice ai alege, contează mai puțin decât să servești imaginile la mărimea potrivită: o imagine de 1.600 de pixeli acolo unde ar ajunge 800 costă mai mult decât economisește orice schimbare de format.

Pentru setările de calitate, echivalențele din testul nostru au fost WebP 85 ≈ AVIF 67 ≈ JPEG 87 și WebP 75 ≈ AVIF 50 ≈ JPEG 77. Next.js transformă setarea de calitate în calitate AVIF înmulțind-o cu 0,625, deci 85 devine 53; după măsura noastră, asta e vizibil sub WebP-ul lui la 85, așa că o parte din economia pe care o vezi vine din calitate mai mică. Imaginile și fonturile web sunt cele două părți din greutatea unei pagini pe care un designer le decide cel mai direct. Dacă vrei pe cineva care să treacă împreună cu tine prin imagini și prin restul greutății paginii, asta face pachetul nostru Optimizare viteză.

Surse și metodă

Mărimile fișierelor, scorurile de calitate și timpii de codare și decodare sunt măsurătorile noastre din 10 octombrie 2026, descrise în secțiunea despre metodă de mai sus. Suportul în browsere și setările codorilor vin din paginile de mai jos.

• Can I use — AVIF image format ↗

  Suport global 95,35% (citit pe 10 octombrie 2026); Chrome 85, Firefox 93, iOS Safari 16, Edge 121; Safari pe macOS parțial (Ventura sau mai nou, fără sinteză de zgomot).

• Can I use — WebP image format ↗

  Suport global 96,74% (citit pe 10 octombrie 2026).

• Next.js — Image component: formats ↗

  Formate implicite: doar WebP; AVIF se activează separat. Next.js codează AVIF cu effort 3 și 0,625 din calitatea cerută (codul sursă Next.js 16.3).

• sharp — Output options ↗

  Setările implicite folosite aici: WebP calitate 80, effort 4; AVIF calitate 50, effort 4, crominanță 4:4:4.

• Alliance for Open Media — AV1 Image File Format (AVIF) ↗

  Specificația AVIF.

• Google for Developers — WebP ↗

  WebP se bazează pe codecul video VP8.

• Lighthouse — Network throttling ↗

  Simularea mobilă: latență 150 ms, descărcare 1,6 Mbps.

• Wang, Bovik, Sheikh și Simoncelli — Image quality assessment: from error visibility to structural similarity ↗

  Măsura SSIM. Am calculat-o pe luminozitate, în ferestre de 8×8 la fiecare 4 pixeli.