Performance
AVIF e WebP: cosa cambia davvero rispetto a PNG
AVIF e WebP alleggeriscono le foto, non le illustrazioni piatte: qui 916 copertine PNG pesano 64 MB contro 1,9 MB in SVG.
In sintesi
- AVIF batte WebP sulle fotografie, il vettoriale batte entrambi sulle illustrazioni piatte.
- Le 916 copertine PNG del blog pesano 64.305.140 byte, le stesse in SVG 1.897.836 byte.
- Il markup corretto è un picture con AVIF, WebP e un img di fallback con width e height.
AVIF e WebP riducono il peso delle fotografie; su un'illustrazione piatta il vettoriale resta più leggero di entrambi. Le copertine di questo blog lo mostrano: 64 MB di PNG contro 1,9 MB di SVG sugli stessi 916 disegni.
Quattro formati, quattro lavori
| Formato | Compressione | Supporto | Caso d'uso |
|---|---|---|---|
| AVIF | con perdita, più efficiente | Chrome 85, Firefox 93, Safari 16.4 | foto e immagini hero |
| WebP | con o senza perdita | Chrome 32, Firefox 65, Safari 14 | foto con fallback ampio |
| PNG | senza perdita | tutti | screenshot e testo nitido |
| SVG | vettoriale | tutti | illustrazioni e copertine piatte |
La differenza tra AVIF e WebP si vede sulle fotografie, dove AVIF arriva allo stesso dettaglio con meno byte. Su un disegno a tinte piatte il vettoriale vince perché non contiene pixel: la copertina SVG qui è 33 volte più leggera del PNG.
Il comando
cwebp -q 70 -m 6 cover.png -o cover.webp
avifenc --min 20 --max 30 cover.png cover.avifcwebp converte in WebP con qualità 70 e metodo 6, il più lento e il più piccolo. avifenc imposta il quantizzatore tra 20 e 30: numeri bassi tengono più dettaglio e producono file più grandi.
Il markup che funziona
Il browser prende la prima sorgente che sa decodificare, quindi AVIF arriva dove è supportato e PNG resta il fallback. width e height sull'img riservano lo spazio e tengono fermo il CLS.
La limitazione
Qui le copertine escono solo in PNG e SVG: le varianti WebP e AVIF rispondono 404, quindi la misura descrive il costo del formato attuale, non un confronto generato. AVIF inoltre impiega secondi a codificare ogni immagine e costa più CPU in decodifica sui telefoni lenti.
Dove continuare
Nel catalogo EneUI: 111.985 componenti, 1.556 blocchi e il record image auto slider, un carosello che carica immagini e quindi paga ogni byte risparmiato. Le guide: immagini responsive con srcset e quando il lazy loading non serve; il confronto Brotli contro gzip copre la compressione del testo, che resta separata da quella delle immagini.
Domande frequenti
AVIF è sempre meglio di WebP?
No. AVIF vince sulle fotografie a parità di qualità percepita, ma WebP decodifica più in fretta e ha un supporto più ampio sui browser datati. Tieni entrambi nel picture e lascia scegliere al browser.
Posso convertire un SVG in WebP per risparmiare?
Di solito no. Il SVG descrive forme e resta piccolo finché l'illustrazione è semplice; convertirlo in raster aggiunge pixel e peso, come mostra la copertina da 2.114 byte contro 69.757.
Quanto tempo serve per codificare in AVIF?
Da uno a diversi secondi per immagine su una macchina normale, contro poche centinaia di millisecondi per WebP. Conviene convertirle in build o una volta sola, non a ogni richiesta.
WebP e AVIF tolgono il problema del CLS?
No. Il formato non dice al browser quanto spazio occupare: servono width e height sull'img o un aspect-ratio nel CSS, altrimenti il layout si sposta comunque.
Serve ancora il PNG?
Sì, come fallback per i browser che non leggono AVIF o WebP e per le immagini con testo o trasparenza netta, dove la compressione con perdita si vede.