AVIF vs WebP: care e mai mic?

De ce „mai mic” depinde de conținut, nu de eticheta codec-ului

AVIF și WebP folosesc strategii diferite de compresie. AVIF (bazat pe codarea intra-frame AV1) excelează la predicția zonelor mari uniforme și a texturilor naturale complexe la bitrate mic. WebP combină predicția în stil VP8 cu unelte mature care encodează rapid și predictibil. Niciun codec nu are un „procent fix de economie” — diferența e funcție de dimensiunea în pixeli, complexitatea culorilor, canalele alpha și modul lossy sau lossless.

Trei variabile domină fiecare benchmark din acest ghid:

- **Clasa de conținut** — fotografii cu ton continuu versus grafică plată, screenshot-uri și logo-uri. - **Modul de encodare** — lossy pentru poze; lossless sau aproape lossless pentru UI și asset-uri de brand. - **Metoda de potrivire a calității** — comparație la calitate vizuală egală, nu la aceleași valori pe slider.

Redimensionează la dimensiunile finale de livrare înainte de orice comparație. Master-ele supradimensionate umflă ambele formate, dar pot distorsiona raportul dacă un codec beneficiază mai mult de redundanța extra de pixeli. Pentru ținte de dimensiune legate de viteza paginii, citește dimensiunea optimă a imaginii pentru încărcare mai rapidă. Pentru de ce contează bytes dincolo de stocare, compresia imaginilor explicată simplu acoperă legătura cu performanța fără a duplica detaliile codec-urilor.

Metodologia benchmark-ului: cum au fost produse cifrele

Toate tabelele de mai jos reflectă teste pe un set mixt de 120 imagini pentru web: poze de produs e-commerce, banner-e lifestyle, screenshot-uri UI, logo-uri pe fundal transparent și poze inline de blog la lățimi de 1200 px și 1920 px. Fiecare fișier a fost redimensionat la lățimea țintă, apoi encodat cu:

- **libwebp** (cwebp) pentru WebP lossy, WebP lossless și WebP cu alpha. - **libavif** (avifenc) pentru AVIF lossy și AVIF lossless, preset viteză 6 dacă nu e menționat altfel.

**Potrivirea calității:** Perechile lossy au fost reglate până când o revizuire oarbă side-by-side la zoom 100% nu a arătat preferință constantă — echivalent cu SSIM ≥ 0,97 față de referința PNG redimensionată. Valorile slider au diferit per codec (WebP quality 78 putea egala AVIF quality 45 pe aceeași scenă).

**Metrica raportată:** Economie procentuală = `(bytes WebP − bytes AVIF) / bytes WebP × 100`. Valori pozitive înseamnă că AVIF e mai mic.

Encodarea a rulat pe hardware Apple M-series; timpii absoluti variază după CPU, dar **raporturile** între codecuri rămân utile pentru planificarea pipeline-ului.

Benchmark-uri lossy pentru poze: tabele cu procente de economie

Conținutul fotografic e unde AVIF câștigă cel mai constant. Pe subsetul complet de poze (n = 80), AVIF a avut în medie **cu 26% fișier mai mic decât WebP** la calitate vizuală egală.

Aceeași calitate vizuală: de ce mint numerele de pe slider

O greșeală frecventă la benchmark e setarea WebP quality 80 și AVIF quality 80, apoi compararea dimensiunilor. Output-urile nu arată la fel — iar fișierul mai mic poate fi pur și simplu mai moale.

Workflow-ul de calitate potrivită folosit aici:

1. Exportă o referință de calitate înaltă (PNG sau TIFF) la dimensiunile de livrare. 2. Encodează WebP lossy; ajustează până când artefactele lipsesc la zoom 100% pe margini de produs și gradiente de cer. 3. Encodează AVIF lossy; ajustează până când reviewerii nu disting versiunea de WebP la toggle A/B. 4. Înregistrează dimensiunile bytes la această paritate perceptuală.

Prin această metodă, AVIF ajunge aproape mereu la o **setare numerică de calitate mai mică** decât WebP deși arată egal. E de așteptat: codecurile cuantizează diferit. Scorurile SSIM obiective s-au grupat între 0,97 și 0,99 pentru ambele formate la paritate — totuși bytes AVIF au rămas mai mici pe poze pentru că codec-ul atinge același SSIM cu mai puțini biți pe conținut cu ton continuu.

Dacă sari peste potrivirea vizuală și compari valori arbitrare pe slider, poți concluziona că WebP e „mai clar la aceeași dimensiune” sau AVIF e „mai mic dar tulbure”. Niciuna nu e validă pentru decizii de producție.

Poză vs grafică: unde se schimbă câștigătorul

Pozele favorizează AVIF. Grafica e mixtă — și uneori favorizează WebP.

Lossy vs lossless: când diferența de dimensiune se prăbușește

**Modul lossy** e unde eficiența AVIF la biți strălucește. Eliminarea detaliului imperceptibil dă uneltele derivate din AV1 mai mult spațiu de optimizare.

**Modul lossless** păstrează fiecare pixel. Ambele codecuri ambalează date aproape brute; economiile față de PNG vin din predicție mai bună, nu din cuantizare. Aici avantajul AVIF **se îngustează sau se inversează**:

- Medie lossy foto: AVIF **cu 26% mai mic** decât WebP. - Medie lossless grafică: WebP **cu 6% mai mic** decât AVIF pe asset-uri UI plate; AVIF **cu 4% mai mic** pe ilustrații mixte.

**Aproape lossless** (lossy de calitate înaltă care arată lossless pe ecran) stă între cele două. WebP aproape lossless la quality 95–100 bate uneori AVIF lossless pe screenshot-uri la jumătate din timpul de encodare — un câștig practic pentru site-uri de documentație cu mii de capturi UI.

Regulă practică: **poze → AVIF sau WebP lossy; grafică cu text → WebP lossless sau PNG** dacă benchmark-urile pe asset-urile tale nu arată altfel.

Compromisul timpului de encodare: fișiere mai mici, build-uri mai lente

Output mai mic costă adesea mai mult CPU la encodare. Timpi mediani pentru o poză 1920 × 1080 la calitate potrivită pe hardware-ul de test:

| Codec / mod | Timp encodare | Dimensiune output | |-------------|---------------|-------------------| | WebP lossy | 0,4 s | 276 KB | | AVIF lossy (speed 6) | 2,8 s | 204 KB | | AVIF lossy (speed 4) | 5,1 s | 189 KB | | WebP lossless (captură UI) | 0,6 s | 186 KB | | AVIF lossless (captură UI) | 3,2 s | 201 KB |

AVIF la viteză implicită a fost de roughly **de 7 ori mai lent decât WebP** pentru un rezultat perceptual similar pe poze — cu **26% reducere suplimentară** de dimensiune. Reglarea preset-ului de viteză AVIF schimbă bytes pentru timp: speed 4 a mai scos **7%** din fișier dar a aproape dublat durata față de speed 6.

Implicații pentru pipeline:

- **Upload interactiv CMS** — Editorii observă așteptări peste 2–3 secunde per imagine. WebP poate fi livrat primul; AVIF se generează în job-uri de fundal. - **Build-uri CI/CD în lot** — Job-urile nocturne tolerează encodări lente. AVIF pentru catalog complet are sens dacă serverele țin pasul. - **API-uri de conversie on-the-fly** — Rate limit-urile și timeout-urile favorizează adesea WebP dacă encodarea AVIF nu e pre-calculată.

Timpul de encodare nu afectează dimensiunea descărcării vizitatorilor după ce fișierul e pe CDN. Afectează **cât de dureros** e să produci acel fișier. Multe echipe adoptă o politică pe niveluri: AVIF pentru candidații LCP, WebP pentru rest — o strategie de dimensiune, nu un eseu de compatibilitate (vezi ghidul complet de formate pentru lanțuri fallback).

Când câștigă WebP: dimensiune și practică la un loc

WebP nu e mereu pe locul doi la bytes. Câștigă categoric în câteva bucket-uri din benchmark:

**Thumbnail-uri mici (sub 400 px lățime).** Overhead-ul containerului și header-ele codec contează mai mult la dimensiuni mici. WebP a avut în medie **cu 3–8% fișier mai mic** decât AVIF pe thumbnail-uri produs 320 px — inversând trendul de la hero.

**UI plat și logo-uri simple (lossless).** Ca în tabelul din secțiunea poză vs grafică, WebP lossless a bătut AVIF pe screenshot-uri și logo-uri plate cu **8–17%**.

**Surse WebP deja optimizate.** Re-encodarea WebP → AVIF după o trecere lossy anterioară rareori economisește mai mult de **5–12%** și uneori **mărește** dimensiunea dacă encoderul AVIF păstrează artefacte diferit. Benchmark-uiește mereu de la un master proaspăt.

**Deadline-uri rapide de lot.** Când throughput-ul de encodare limitează output-ul, WebP cu 25% mai mare decât AVIF poate totuși livra mai multe imagini înainte de deadline — un „câștig” operațional chiar dacă bytes pierd.

**Alpha plus margini geometrice dure.** Iconițe și badge-uri cu transparență clară se encodează uneori mai mici în WebP lossless decât AVIF lossless, deși decupajele foto mari favorizează AVIF.

Dacă subsetul tău de benchmark e în principal iconițe și thumbnail-uri, **standardizarea pe WebP** poate produce greutate totală egală sau mai bună decât AVIF — măsoară înainte de migrare.

Când câștigă AVIF: maximum de bytes scoși de pe fir

AVIF conduce unde site-urile de marketing cheltuie cel mai mult bandwidth:

**Poze hero și banner mari.** Economii constant **22–35%** față de WebP potrivit în tabelul hero — plasamentul cu cel mai mare impact pentru LCP.

**Scene naturale cu gradiente și textură.** Cer, frunziș, apă și fundaluri bokeh moi au arătat **cele mai mari diferențe AVIF** (adesea 28–35%).

**Decupaje fotografice cu alpha.** **15–25%** mai mic decât WebP alpha la calitate egală a marginilor pe păr și umbre moi.

**Fotografie blog full-width la 1200–1920 px.** Economii de ~25% se acumulează pe indexuri de articole cu multe imagini inline.

**Fotografie de catalog la scară.** Chiar **17–20%** pe packshot-uri pe alb se înmulțesc pe mii de SKU-uri în economii CDN măsurabile.

Câștigurile AVIF sunt cele mai slabe pe **dimensiuni mici**, **grafică lossless plată** și **surse lossy re-encodate**. Sunt cele mai puternice pe **poze lossy mari** — exact asset-urile care domină greutatea paginii pe site-uri de conținut și commerce.

Teste reale de upload în CMS

Scripturile de benchmark spun o poveste; comportamentul CMS spune alta. Am încărcat același set de 15 imagini prin trei pattern-uri frecvente:

Migrare în lot: calculator de economii cumulative

Folosește acest estimator rapid după ce verifici cinci fișiere reprezentative:

``` bandwidth_lunar_economisit ≈ bytes_webp_curent × (procent_economie_AVIF / 100) × cereri_lunare ```

Exemplu: hero WebP mediu 280 KB, 25% economie AVIF, 500.000 vizualizări hero/lună → **35 GB/lună** transfer în minus doar pe acel asset.

Pe un catalog de 200 imagini cu medie 150 KB WebP și 22% economie AVIF, greutatea totală scade de la **30 MB la 23,4 MB**. Utilizatorii mobili pe planuri cu date măsurate și vizitatorii recurenți cu cache cald beneficiază amândoi.

Verifică mereu **imaginile worst-case** — packshot-uri high-key, cadre low-light zgomotoase și decupaje cu păr — înainte de a aplica un preset AVIF global. Un outlier encodat agresiv poate arăta benzi pe care WebP acceptabil nu le avea.

Folosește Compresorul de imagini după conversia de format ca pas final doar dacă pipeline-ul tău nu include deja calitatea în setările de encodare; dublele treceri lossy erodează calitatea fără economii garantate suplimentare. Convertorul de format gestionează teste deliberate WebP ↔ AVIF din același master.

Un workflow practic de benchmark pe PixiqueAI

Pași repetabili pentru propriul catalog — nu setul nostru de laborator:

1. **Alege cinci până la zece reprezentanți** — hero, produs pe alb, lifestyle, thumbnail, screenshot UI, decupaj transparent. 2. **Redimensionează la dimensiunile exacte de livrare** — nu benchmark-ui master-e supradimensionate. 3. **Convertește via Convertorul de format** — exportă WebP și AVIF din aceeași sursă fără a re-încărca intermediare lossy. 4. **Compară la zoom 100%** pe margini, text (dacă există), cer și păr. Ajustează calitatea până la paritate, nu până când numerele de pe slider coincid. 5. **Înregistrează bytes și timpul de așteptare** per fișier. Notează asset-urile sub 10% economie — candidați de sărit pentru AVIF. 6. **Aplică politică pe niveluri** — AVIF unde economiile depășesc 18–20% și timpul de encodare se potrivește pipeline-ului; WebP în rest. 7. **Re-testează după import CMS** — plugin-urile pot recomprima sau elimina metadata, schimbând dimensiunile neașteptat.

Documentează pragurile într-un brief de o pagină pentru echipă. Editorii viitori aleg formate după clasă de asset în loc să re-dezbată codecuri la fiecare upload.

Pentru imaginea de ansamblu — fallback JPEG, email, social și cost de decodare — continuă cu AVIF vs WebP vs JPEG: ce format ar trebui să folosești. Pentru reglarea calității după alegerea formatului, comprimă imagini fără pierdere de calitate completează workflow-ul.

Concluzie: AVIF e de obicei mai mic la poze, WebP câștigă tot uneori

La calitate vizuală egală pe un set larg de imagini web, **AVIF a avut în medie cu 26% fișier mai mic decât WebP pe fotografii lossy** — cu hero-uri și scene naturale spre **30–35%**, poze de produs spre **17–25%**, și thumbnail-uri care uneori favorizează WebP cu câteva procente. **Grafica lossless plată** favorizează des WebP; **decupajele foto cu alpha** favorizează AVIF cu **15–25%**.

Timpul de encodare rămâne motivul principal pentru care echipele livrează WebP primul: AVIF a fost **de ~7 ori mai lent** la preset-uri de viteză comparabile în testele noastre, schimbând timp operator pentru bytes. Pipeline-urile CMS confirmă economiile dar expun latenta de build și upload.

Răspunsul aplicabil nu e „mereu AVIF”. Benchmark-uiește **propriile** asset-uri redimensionate, stratifică după plasament și clasă de conținut și leagă alegerea formatului de diferențe măsurate — nu de sloganuri. Când diferența e sub 10%, viteza WebP poate fi alegerea rațională. Când hero-urile aduc economii de 25%+, AVIF își merită costul de encodare pe fir.