Pozele de pe site: format, mărime și compresie

Regula scurtă: fotografiile merg în JPEG sau WebP, logoul și iconițele în SVG, capturile de ecran în PNG. Fiecare poză se urcă la mărimea la care apare pe ecran, nu la mărimea din aparat, și se comprimă înainte să ajungă pe site. Dacă faci doar atât, ai rezolvat cea mai mare parte din problemele de viteză care vin de la imagini.

Ce format pentru ce poză

Formatul se alege după ce e în poză, nu după obișnuință.

Ghidul de formate de la MDN spune același lucru: compresia fără pierderi pentru capturi, diagrame și logouri, pentru că la ele se văd imediat marginile încețoșate, și SVG pentru tot ce trebuie desenat exact la mai multe mărimi.

Greșeala pe care o vedem des e invers: o fotografie de pe terasă salvată în PNG. Arată la fel, dar fișierul iese mult mai mare.

WebP și AVIF: ce poți folosi acum

WebP e formatul pe care îl recomandăm pentru fotografii în 2022. Documentația Google de pe web.dev spune că fișierele WebP ies de obicei cu 25–35% mai mici decât echivalentul JPEG. Îl afișează toate browserele mari. Singura excepție ține de Mac: Safari îl afișează doar de la versiunea 14, pe macOS Big Sur sau mai nou. De aceea punem WebP cu o variantă JPEG de rezervă, iar browserul o alege singur pe cea pe care o poate afișa.

AVIF comprimă și mai bine. MDN îl dă la aproximativ jumătate din mărimea unui JPEG. Chrome îl afișează de la versiunea 85, Firefox de la 93, dar Safari încă nu. Deci AVIF merge doar cu rezervă în spate, niciodată singur.

Cât de mare urci poza

Un telefon face poze de câteva mii de pixeli lățime. Pe site, aceeași poză apare poate într-o casetă de 800 de pixeli. Dacă urci originalul, browserul îl descarcă întreg și apoi îl micșorează. Vizitatorul plătește cu timp și cu date mobile pentru pixeli pe care nu îi vede.

Soluția corectă e să pregătești două sau trei lățimi pentru pozele mari și să le spui browserelor care e care, cu atributele srcset și sizes. Browserul alege singur varianta potrivită pentru ecran. În exemplul din documentația MDN, varianta de 480 px are 63 KB, iar cea de 800 px are 128 KB; pe un telefon îngust se descarcă doar prima și se economisesc cam 65 KB la o singură poză. Pe o pagină de galerie, economia se adună repede.

Ecranele de telefon au mai mulți pixeli fizici decât pixeli „de layout”. O poză care ocupă 320 de pixeli pe ecran arată clar pe un telefon bun abia la 640 de pixeli reali. Tot srcset rezolvă asta.

Compresia, fără să se vadă

Orice program de editare are la export un reglaj de calitate. Nu există un număr magic: îl scazi pas cu pas și compari poza la mărime reală, pe ecran, cu originalul. Când nu mai vezi diferența, te oprești. La fotografiile cu cer sau cu fundaluri netede apare primul defectul, sub formă de trepte în culoare, așa că acolo te oprești mai devreme.

Încă două lucruri la export:

• scoate datele EXIF (aparat, locație GPS), care nu ajută pe site și uneori spun mai mult decât vrei;
• numește fișierul cu cuvinte, de exemplu terasa-restaurant-seara.webp, nu IMG_4532.jpg.

Încărcarea: ce apare primul și ce așteaptă

Atributul loading="lazy" amână descărcarea pozelor de mai jos în pagină până când vizitatorul ajunge aproape de ele. Merge fără niciun script. Ghidul web.dev spune însă clar să nu-l pui pe pozele care se văd din prima, mai ales pe poza mare de sus. Pe aceea vrei să o vezi cât mai repede.

Pune mereu width și height pe imagini. Așa browserul păstrează locul pozei înainte să o descarce și textul nu mai sare când apare imaginea. Săritura asta se măsoară în Core Web Vitals ca CLS, iar un scor bun e de cel mult 0,1. Am explicat cum se citesc aceste măsurători în articolul despre Core Web Vitals pe înțelesul tuturor.

Dacă vrei să vezi cum stă site-ul tău la capitolul imagini, ne uităm împreună. Detalii despre ce facem găsești pe pagina de servicii web.