Este WebP de fapt mai mic decât JPG pentru imaginile de pe site-uri?
Am comparat JPG, WebP și AVIF pe aceeași fotografie de 538.6 KB la aceeași poziție a slider-ului, iar JPG a câștigat. Iată de ce se întâmplă asta și ce arată comparația corectă.
Fiecare ghid îți spune că WebP este cu aproximativ 30% mai mic decât JPG la aceeași calitate. Studiul propriu al Google este sursa acestei cifre. Am realizat comparația pe propriul nostru compresor cu o fotografie de 3840x2160, texture.jpg la 538.6 KB, iar la aceeași poziție a slider-ului JPEG a câștigat: 286.1 KB față de 290.3 KB pentru WebP. AVIF, formatul care ar trebui să le depășească pe ambele, a ajuns la 312.7 KB.
Nimic nu a fost stricat. Cele trei formate citesc acel slider diferit, iar unul dintre ele o face intenționat. Odată ce știi care este acela, rezultatul se întoarce la așa cum te-ai aștepta, și obții un obicei care merită să fie păstrat în orice instrument folosești deja.
De ce a ieșit WebP mai mare decât JPG la aceeași poziție a slider-ului?
Compresorul nostru are o particularitate pe care multe instrumente o împărtășesc și aproape niciunul nu o menționează. Când formatul de ieșire este JPEG și intrarea era deja un JPEG, citește tabelele de cuantizare din fișierul sursă, estimează calitatea la care fișierul a fost salvat, apoi înmulțește slider-ul tău cu acea estimare. O sursă cu un scor de 60 cu slider-ul la 80 este codificată la 48. WebP și AVIF nu beneficiază de un astfel de tratament, așa că 80 înseamnă 80 și encoderul face ceea ce i se spune. Acea rulare de la început a fost JPEG la un efectiv de 48 față de WebP la un 80 literal. Un fișier comprimat mai puternic este mai mic.
Rescalarea își câștigă locul. Re-codificarea unui JPEG deja pierdut la 80 când a fost scris la 60 adaugă bytes fără a adăuga detalii înapoi, așa că tratăm slider-ul ca o fracție din ceea ce a rămas în fișier. Problema mai profundă aparține JPEG-ului în sine: specificația stochează tabelele de cuantizare brute și nu stochează niciodată un număr de calitate, așa că 75 în Photoshop, 75 în MozJPEG și 75 într-un script PHP sunt trei fișiere diferite. Potrivirea numărului pe două slider-e și numirea acestuia ca un test corect nu funcționează.
Cum arată dimensiunile când le compari corect?
| Codificare | Slider | Ieșire |
|---|---|---|
| fișier sursă texture.jpg | 538.6 KB | |
| JPEG (MozJPEG) | 80, rescalat la 48 | 286.1 KB |
| WebP | 80, luat literal | 290.3 KB |
| AVIF | 80, luat literal | 312.7 KB |
| WebP | 63 | 200.6 KB |
| AVIF | 63 | 186.9 KB |
La 63, WebP scrie 200.6 KB din acel fișier sursă de 538.6 KB. AVIF la aceeași setare ajunge la 186.9 KB, iar 63 este ceea ce modul nostru inteligent a ales pentru AVIF oricum, deci nu este un număr pe care l-am ales pentru a flata formatul. Potrivește dimensiunile de ieșire mai întâi, apoi deschide ambele fișiere la dimensiune completă și decide care dintre ele poți accepta. Aceasta este comparația care merită.
Ar trebui să folosesc doar AVIF atunci?
Pe bytes, AVIF câștigă. Pe răbdare, pierde. Codificarea acelui cadru de 3840x2160 în AVIF a durat aproximativ 10 până la 11 secunde în browser, în timp ce JPEG și WebP au revenit instantaneu. Totul acesta este WebAssembly rulând pe propria ta mașină, așa că acesta este laptopul tău care face codificarea AV1 intra, iar costul crește odată cu numărul de pixeli. Există o a doua capcană de știut: dacă encoderul WASM eșuează, revenim la encoderul canvas al browser-ului, iar canvas poate scrie JPEG, PNG și WebP, dar nu are deloc un drum AVIF. Pentru un lot mare, Google recomandă instrumentul nativ avifenc în locul construcțiilor WebAssembly, iar ceea ce costă zece codificări AVIF într-o filă este măsurat și el.
Ce pierd când transform un JPG într-un WebP?
Trei lucruri concrete. Metadatele merg primele: comprimarea sau conversia decodează imaginea în pixeli brut și o re-codifică, așa că EXIF, coordonatele GPS, profilul ICC și miniatura încorporată sunt toate eliminate din ieșire. Orientarea supraviețuiește, deoarece browserul o aplică în timpul decodării. Dacă ai nevoie de data capturii, păstrează fișierul original. Și un JPG pierdut re-codificat ca WebP pierdut este o a doua generație de pierdere adăugată la prima, așa că fă-o o singură dată din cea mai bună sursă pe care o ai.
Chroma este a doua pierdere. WebP pierdut este blocat la sub-eșantionare 4:2:0, fără opțiunea 4:4:4 în niciun loc în format, așa că un screenshot cu cod evidențiat sintactic sau un logo pe un roșu saturat poate arăta mai rău în WebP decât într-un JPEG de aceeași greutate. Fotografii nu îi pasă. Redarea este a treia: un JPEG progresiv pictează un cadru complet brut devreme și se ascuțește pe măsură ce bytes sosesc, iar WebP nu are mod progresiv, așa că un fișier mare nu arată nimic până când nu ajunge suficient din el. Pe o imagine principală peste o conexiune slabă, asta schimbă cât de repede se simte pagina, chiar și atunci când fișierul este mai mic.
Câștigă WebP în continuare dacă imaginea are transparență?
JPEG nu poate face transparență. Nu există canal alfa în niciun mod JPEG, așa că pentru un logo sau un contur, adevărata competiție este PNG împotriva WebP, iar cazul pentru fiecare dintre cele două formate este măsurat pe aceste fișiere. Numerele noastre PNG stabilesc standardul pe care trebuie să-l depășești: alpha.png la 900x606 și 942.4 KB a scăzut la 383.9 KB prin oxipng fără pierderi la nivelul 3, și la 98.3 KB odată ce imagequant l-a redus la o paletă, ceea ce este 90% reducere cu transparența intactă. WebP își stochează alfa fără pierderi chiar și în interiorul unui fișier pierdut, așa că marginile conturului rămân curate în ambele cazuri. Dacă faci conturul în primul rând, instrumentul nostru de eliminare a fundalului scrie întotdeauna PNG cu alfa, iar acel PNG poate merge direct în compresor ulterior.
Pe care ar trebui să-l pun efectiv pe site?
Folosește WebP pentru fotografii. Fiecare browser actual îl decodează, inclusiv Safari, iar economiile sunt reale odată ce încetezi să compari numerele slider-ului. Păstrează JPG acolo unde fișierul trebuie să se deschidă în software vechi sau unde un mare hero beneficiază mai mult de redarea progresivă decât de 30 KB. Ghidul de formate de imagine MDN este referința de verificat înainte de a angaja o întreagă bibliotecă într-un singur format.
Verifică pixeli mai întâi. O fotografie de 3840px este de patru ori mai lată decât o coloană de conținut de 960px va afișa vreodată, iar niciun codec nu îți oferă înapoi ceea ce o redimensionare îți oferă gratuit, așa că redimensionatorul cu presetările sale 25/50/75 este un singur clic și de obicei depășește argumentul formatului. Scara calității contează mai mult decât formatul. Același texture.jpg a ajuns la 212.4 KB la 60 și 131 KB la 30, iar modul inteligent s-a stabilit pe 286.1 KB, 47% reducere, fără a te întreba nimic.
Cum pot rula acest test pe propria mea imagine?
Deschide compresorul, adaugă fotografia ta și comută pe manual. Alege JPG, notează dimensiunea. Schimbă dropdown-ul de format în WebP la aceeași poziție a slider-ului și notează acea dimensiune. Apoi trage slider-ul WebP în jos până când cele două fișiere sunt la câteva KB distanță unul de celălalt și privește-le unul lângă altul la dimensiune completă, pentru că aceasta este singura comparație care îți spune ceva. Loturile sunt limitate la 10 fișiere și 50 MB. Dacă preferi să sari complet peste slider, JPG în WebP codifică la o calitate fixă de 80 fără redimensionare, WebP în JPG se întoarce în cealaltă direcție cu transparența mată pe alb, iar ghidul PDF acoperă o singură conversie care face fișierele mai mari.