Ce este WebP și cum alegi formatul și mărimea imaginilor de pe site

WebP este un format de imagine pentru web care comprimă fotografiile și grafica în fișiere mai mici decât JPEG și PNG, la o calitate vizuală asemănătoare. Dacă te întrebi ce este WebP și dacă merită pe site-ul firmei, răspunsul scurt este da, pentru majoritatea imaginilor. Formatul rezolvă însă doar o parte din problemă. Cealaltă parte este lățimea la care trimiți imaginea și momentul în care începe să se încarce. Mai jos ai criteriile de alegere între WebP, AVIF, JPEG și PNG, felul în care servești mai multe variante și o metodă simplă de măsurat înainte și după.

Informațiile vin din documentația oficială Google, web.dev și MDN, citită la 10 noiembrie 2026. Browserele și uneltele se schimbă, deci verifică din nou paginile din lista de surse înainte de o decizie mare.

Ce este WebP și de ce iese mai mic decât JPEG

WebP este un format de fișier pentru imagini, documentat de Google pe pagina proiectului, care acceptă două feluri de compresie. Compresia cu pierderi renunță la detalii pe care ochiul le observă greu și dă fișiere mici. Compresia fără pierderi păstrează fiecare pixel exact, ca un PNG, dar ocupă mai puțin spațiu.

Câștigul vine din felul în care e codată imaginea. Varianta cu pierderi se uită la blocurile vecine de pixeli, ghicește cum arată blocul următor și salvează doar diferența dintre ghicit și realitate. Varianta fără pierderi refolosește fragmente de imagine deja întâlnite în fișier.

Pagina oficială a formatului dă cifre concrete. Imaginile WebP fără pierderi sunt cu 26% mai mici decât PNG-urile. Cele cu pierderi ies cu 25-34% mai mici decât un JPEG comparabil, la calitate echivalentă. Transparența costă puțin: în varianta fără pierderi, canalul de transparență adaugă doar 22% octeți în plus.

Ghidul MDN al formatelor de imagine dă un interval ușor diferit pentru varianta cu pierderi, de 25–35% față de JPEG. Sursele diferă deci puțin la capătul intervalului, dar spun același lucru: la fotografii, câștigul e consistent. Graficul de mai jos pune alături cifrele din ghidul MDN, inclusiv pe cele pentru AVIF.

Sursa: Image file type and format guide, MDN Web Docs

Cifrele sunt medii pe seturi de imagini, nu promisiuni pentru fiecare fișier. O fotografie cu mult zgomot sau cu detalii fine poate câștiga mai puțin. O grafică simplă, cu suprafețe de culoare uniformă, poate câștiga mai mult. De aceea compari întotdeauna fișierul tău, nu media din documentație.

Merită AVIF sau rămâi la WebP

AVIF merită pentru fotografii, cu condiția să oferi și o rezervă. După ghidul MDN, imaginile AVIF cu pierderi sunt cu circa 50% mai mici decât JPEG-urile. Ambele formate au transparență și animație, deci la funcții nu pierzi nimic.

Diferența apare la afișare. AVIF nu are afișare progresivă: fișierul se descarcă integral înainte să apară pe ecran. La fișierele mici asta contează puțin, fiindcă se descarcă repede oricum. La o imagine mare, pe o conexiune mobilă slabă, vizitatorul vede mai mult timp un spațiu gol.

Al doilea criteriu este sprijinul din browsere. Ghidul MDN listează AVIF în Chrome 85, Edge 121, Opera 71, Firefox 93 și Safari 16.1, ca primele versiuni care îl afișează. Pentru WebP pe macOS, același ghid notează că ai nevoie de Safari 14 sau mai nou și de macOS Big Sur (11). Un vizitator cu un dispozitiv vechi poate rămâne deci fără imagine dacă nu există rezervă.

Sursa: Image file type and format guide, MDN Web Docs

Concluzia practică este o ordine, nu o alegere exclusivă. Pui AVIF primul, WebP al doilea și un JPEG sau PNG la final. Browserul modern ia fișierul cel mai mic pe care îl înțelege, iar cel vechi ajunge la rezervă. Dacă nu vrei să întreții trei variante, WebP plus JPEG acoperă bine majoritatea situațiilor.

Ce format alegi: exemple pentru fotografie, logo și captură de ecran

Tipul imaginii decide formatul mai mult decât preferința. Ghidul MDN face o distincție clară: fotografiile suportă bine compresia cu pierderi, fiindcă detaliile pierdute se văd greu. Capturile de ecran, schemele, logourile și desenele cu linii cer compresie fără pierderi, pentru că neclaritatea și marginile colorate din jurul textului sar imediat în ochi.

Tabelul de mai jos rezumă alegerea pe tipuri de imagine, după recomandările MDN.

Tip de imagine	Format preferat	Rezervă	De ce
Fotografie de produs sau de echipă	AVIF sau WebP cu pierderi	JPEG	Detaliile eliminate de compresie se observă greu
Captură de ecran, tabel, schemă cu text	WebP fără pierderi	PNG	Literele și marginile rămân clare
Logo, pictograme, diagrame simple	SVG	WebP sau PNG	Desenul vectorial rămâne precis la orice mărime
Imagine cu fundal transparent	WebP cu transparență	PNG	JPEG nu are canal de transparență
Animație scurtă	WebP animat sau AVIF	GIF	Formatele noi comprimă animația mai bine

Un exemplu ipotetic: o firmă de instalații are pe pagina de servicii o fotografie a echipei, logoul și o schemă cu etapele unei lucrări. Fotografia merge în WebP sau AVIF cu pierderi. Logoul merge în SVG. Schema cu text merge în WebP fără pierderi sau în PNG. Trei imagini, trei formate diferite, fiecare ales după conținut.

Pierde calitate o imagine salvată în WebP

Depinde de varianta pe care o alegi la conversie. WebP fără pierderi reproduce originalul exact, deci nu pierzi nimic. WebP cu pierderi renunță la o parte din informație, iar cât de mult renunță decizi tu.

Ghidul web.dev despre WebP spune că, la conversie, singura setare care contează pentru majoritatea oamenilor este calitatea. O alegi pe o scară de la 0, calitatea minimă, la 100, calitatea maximă. Nu există un nivel corect pentru toate imaginile. Încerci câteva valori și te oprești la valoarea minimă la care nu observi diferența.

Câteva reguli de bun-simț, din practica obișnuită:

• convertești pornind de la fișierul original, de calitate mare, nu de la un JPEG deja comprimat de mai multe ori;
• verifici rezultatul la mărimea reală de afișare, pe un telefon, nu doar mărit pe monitor;
• te uiți atent la zonele cu text, la fețe și la degradeuri de culoare, unde defectele apar primele;
• păstrezi originalele separat, ca să poți reface conversia cu alte setări.

De ce lățimea servită contează mai mult decât formatul

O fotografie de mărimea unui ecran de desktop, trimisă unui telefon, risipește date chiar dacă e salvată într-un format modern. Documentația Google despre imagini în căutare observă că imaginile sunt adesea principala sursă de greutate a unei pagini, ceea ce o face lentă și scumpă la încărcare. Ghidul web.dev despre dimensiuni pornește de la o greșeală banală: cineva uită să micșoreze imaginea înainte să o pună în pagină.

Exemplul din ghidul MDN despre imagini responsive arată cât cântărește lățimea. Aceeași fotografie are un fișier de 39 KB la 320 de pixeli lățime și de 93 KB la 640 de pixeli. Graficul pune cele două valori alături.

Sursa: Using responsive images in HTML, MDN Web Docs

Comparația spune ceva simplu: formatul taie un procent din fișier, dar lățimea greșită poate înmulți fișierul. Un JPEG la lățimea corectă poate ieși mai ușor decât un WebP de mărimea unui afiș. De aceea ordinea corectă este întâi lățimea, apoi formatul.

Cum afli lățimea la care se afișează imaginea

Deschizi pagina în Chrome, faci clic dreapta pe imagine și alegi inspectarea elementului. În panoul instrumentelor pentru dezvoltatori vezi lățimea la care e desenată imaginea și lățimea reală a fișierului. Dacă fișierul e mult mai lat decât locul lui, ai găsit o problemă.

Pentru un inventar pe toată pagina folosești Lighthouse, integrat în Chrome. Ghidul web.dev recomandă auditul de performanță și rezultatul numit „Properly size images”, care listează imaginile ce trebuie redimensionate.

Lățimi pentru telefon și pentru desktop

Ecranele de telefon au de obicei densitate mare de pixeli. După ghidul MDN, un dispozitiv cu doi pixeli fizici pentru fiecare pixel CSS primește varianta mai mare a imaginii, ca să rămână clară. Practic, pentru fiecare imagine pregătești o variantă la lățimea afișată pe ecranele mici și una pentru ecranele mari, plus versiunile mai late pentru ecranele dense.

Mai pui pe fiecare imagine atributele width și height. Ghidul web.dev despre dimensiuni explică motivul: browserul rezervă spațiul încă de la început, iar textul nu mai sare când imaginea se încarcă.

Cum servești aceeași imagine în mai multe lățimi

Atributele srcset și sizes ale elementului img îi dau browserului o listă de variante și îi spun cât loc ocupă imaginea în pagină. Browserul alege apoi singur fișierul. După ghidul MDN, aceste atribute și elementul picture funcționează în browserele moderne de pe desktop și de pe telefon.

Pașii, în ordine:

1. Măsori lățimea la care apare imaginea în pagină, pe telefon și pe desktop, cu instrumentele pentru dezvoltatori.
2. Exporți din original câteva variante de lățimi diferite și pui lățimea în numele fișierului, ca să le recunoști ușor.
3. Le treci în srcset, fiecare cu lățimea ei reală în unitatea w. Ghidul web.dev dă un exemplu de forma srcset="flower-320w.jpg 320w, flower-640w.jpg 640w, flower-960w.jpg 960w".
4. Scrii în sizes cât de lată e imaginea în pagină în fiecare situație. În exemplul MDN, sizes="(width <= 600px) 480px, 800px" înseamnă că pe ecranele înguste imaginea ocupă un loc mai mic decât pe cele late.
5. Păstrezi un src simplu, pentru browserele care nu înțeleg atributele noi.
6. Verifici în fila de rețea a browserului ce fișier s-a descărcat efectiv, la mai multe lățimi de fereastră.

Regula de alegere a browserului merită știută. Ghidul MDN spune că, dacă nu există o variantă exact cât locul calculat, browserul o ia pe prima mai mare și o micșorează. Pentru o fereastră de 480 de pixeli, exemplul MDN alege locul de 480 de pixeli. O listă cu prea puține variante duce deci la fișiere mai mari decât e nevoie.

O greșeală frecventă este un sizes lăsat pe valoarea implicită, adică lățimea întregului ecran. Pentru o imagine care ocupă o coloană îngustă, browserul descarcă atunci o variantă mult prea mare.

Cum oferi mai multe formate cu elementul picture

Elementul picture grupează mai multe surse ale aceleiași imagini și lasă browserul să o aleagă pe prima pe care o înțelege. Ghidul web.dev despre WebP descrie ordinea: sursa în formatul preferat stă prima, iar elementul img stă mereu ultimul. Schema de mai jos arată cum citește browserul lista.

Sursa: Use WebP images, web.dev

Fiecare source primește atributul type, cu tipul fișierului, de exemplu image/webp sau image/avif. Browserul sare peste sursele cu tipuri necunoscute fără să le descarce. Elementul img de la final poartă textul alternativ, lățimea și înălțimea și fișierul de rezervă într-un format universal, cum e JPEG.

Ghidul MDN observă că poți pune oricâte surse, dar de obicei două sau trei sunt suficiente. Fiecare sursă poate avea propriul srcset, deci combini formatele cu lățimile.

Există și o variantă fără marcaj suplimentar. Serverul citește antetul HTTP Accept, prin care browserul anunță ce formate acceptă, și trimite WebP doar celor care îl cer. Ghidul web.dev arată această metodă pentru Apache și amintește că ai nevoie și de antetul Vary, ca memoria cache să nu încurce variantele. E o soluție bună când ai multe imagini, dar cere acces la configurarea serverului, de obicei la cel care se ocupă de găzduirea și mentenanța site-ului.

Pentru căutare nu pierzi nimic. Documentația Google Search Central, actualizată la 2026-03-02, enumeră formatele acceptate: BMP, GIF, JPEG, PNG, WebP, SVG și AVIF. Aceeași pagină recomandă nume de fișiere descriptive și text alternativ util, lucruri care contează mai mult decât formatul pentru optimizarea SEO a paginilor.

Cum nu întârzii imaginea principală a paginii

Imaginea principală, cea mare din partea de sus a paginii, este de obicei elementul după care se măsoară încărcarea. Indicatorul se numește LCP (Largest Contentful Paint, momentul în care apare cel mai mare element vizibil). Ghidul web.dev recomandă ca site-urile să aibă un LCP de 2.5 secunde sau mai puțin pentru cel puțin 75% din vizite. Definițiile complete ale indicatorilor sunt în articolul despre viteza site-ului și Core Web Vitals.

Ghidul web.dev împarte timpul LCP în patru părți și arată cum ar trebui să arate împărțirea pe o pagină bine făcută. Cele două părți care conțin cuvântul „întârziere” ar trebui să fie aproape de zero.

Sursa: Optimize Largest Contentful Paint, web.dev

Graficul explică de ce un format nou nu rezolvă singur o pagină lentă. Formatul scurtează doar durata descărcării. Ghidul web.dev spune chiar că, după cercetările lor, durata descărcării nu este de obicei blocajul principal pentru majoritatea site-urilor. Mai des, imaginea începe să se descarce prea târziu sau așteaptă după un script.

Ce faci concret pentru imaginea principală:

• nu îi pui loading="lazy"; ghidul web.dev spune explicit să nu încarci leneș imaginea LCP, fiindcă o întârzie mereu;
• o pui direct în HTML, nu doar ca fundal în CSS sau prin JavaScript, ca browserul s-o descopere devreme;
• îi pui fetchpriority="high", dar doar ei; prioritatea mare pe mai mult de una-două imagini își pierde efectul, după același ghid;
• nu o ascunzi până termină de rulat un script, pentru că timpul câștigat la descărcare se mută doar în întârzierea afișării.

Încărcarea leneșă rămâne utilă pentru imaginile de mai jos în pagină, pe care vizitatorul nu le vede la deschidere. Greșeala obișnuită este aplicarea ei peste tot, inclusiv pe prima imagine.

Pașii de măsurare înainte și după, pe aceeași pagină

O schimbare de imagini se judecă după măsurători comparabile, nu după impresie. Ghidul web.dev despre LCP recomandă verificarea priorității resurselor în instrumentele pentru dezvoltatori și testarea schimbărilor atât în laborator, cât și cu date de la vizitatori reali. Metoda de mai jos se poate urma fără cunoștințe de programare.

1. Alegi câteva pagini reale și reprezentative: prima pagină, o pagină de serviciu sau de produs și un articol cu multe imagini.
2. Rulezi PageSpeed Insights sau Lighthouse pe fiecare, în modul pentru telefon, și notezi LCP, greutatea totală a imaginilor și auditurile despre imagini.
3. Repeți măsurătoarea de câteva ori, fiindcă rezultatele de laborator variază de la o rulare la alta, și notezi valorile tipice.
4. Schimbi doar imaginile: lățimi, format, prioritatea imaginii principale. Nu schimbi în aceeași zi tema, scripturile sau serverul.
5. Rulezi aceeași unealtă, în același mod, pe aceleași adrese, și compari cu notițele de la pasul 2.
6. După câteva săptămâni, te uiți la datele de teren din Google Search Console, care arată experiența vizitatorilor reali.

Lighthouse îți arată și ce a rămas de făcut. Ghidul web.dev spune că auditul „Serve images in next-gen formats” listează imaginile care nu sunt servite în WebP. Dacă lista e goală și LCP nu s-a mișcat, problema e în altă parte: serverul, scripturile sau ordinea de încărcare.

Trebuie să schimbi toate imaginile vechi

Nu dintr-odată și nu în orb. Câștigul vine din câteva imagini mari, nu din sutele de miniaturi. Începi cu imaginea principală a paginilor vizitate des, apoi cu galeriile de produse și abia la final cu arhiva de articole vechi.

Un exemplu ipotetic: un magazin mic are o pagină de categorie cu fotografii de produs exportate direct din aparat. Redimensionarea lor la lățimea afișată și conversia în WebP schimbă mult mai mult decât conversia logourilor sau a pictogramelor. Pentru un magazin online, fotografiile de produs sunt de obicei primul loc unde merită lucrat.

Două precauții țin de adrese. Documentația Google recomandă ca o imagine folosită pe mai multe pagini să aibă mereu aceeași adresă, ca motorul să o poată refolosi. Când schimbi extensia fișierului, adresa se schimbă, deci păstrezi și fișierele vechi o vreme, ca linkurile existente să nu ducă la erori.

Greșeli frecvente

• Convertești în WebP, dar păstrezi lățimea originală de la aparatul foto.
• Pui toate imaginile pe încărcare leneșă, inclusiv imaginea principală.
• Folosești compresie cu pierderi pe capturi de ecran cu text, care devin neclare.
• Scrii un picture fără img la final, iar unele browsere nu afișează nimic.
• Lași width și height deoparte, iar pagina sare în timpul încărcării.
• Măsori o singură dată, cu unelte diferite înainte și după, și tragi concluzii din zgomot.

Listă de control pentru fiecare imagine importantă

• Formatul se potrivește conținutului: fotografie, grafică cu text sau logo.
• Există o rezervă în JPEG sau PNG pentru browserele vechi.
• Fișierul are lățimea locului în care se afișează, cu o variantă pentru ecranele dense.
• srcset și sizes descriu corect variantele și locul ocupat.
• Imaginea are width, height și un text alternativ care descrie ce se vede.
• Imaginea principală nu e leneșă, apare direct în HTML și are prioritate mare.
• Numele fișierului descrie conținutul, nu o serie de cifre de la aparat.

Ce faci mai departe

Începe cu o singură pagină importantă, de obicei prima pagină. Măsori LCP și greutatea imaginilor, corectezi lățimile, treci fotografiile în WebP sau AVIF cu rezervă în JPEG și scoți încărcarea leneșă de pe imaginea principală. Apoi măsori din nou, cu aceeași unealtă, și extinzi doar ce a funcționat.

Dacă site-ul se construiește de la zero, e mai simplu ca formatul, lățimile și marcajul picture să fie gândite din proiectare, ca parte dintr-un site de prezentare rapid pe telefon. Pentru un site existent, verifică întâi ce permite sistemul de administrare a conținutului și serverul, apoi decide dacă faci conversia manual, automat la încărcare sau prin configurarea serverului.