# AVIF and WebP: what really changes against PNG

AVIF and WebP lighten photos, not flat illustrations: here 916 PNG covers weigh 64 MB against 1.9 MB in SVG for the same drawings.

> Page: https://ui.eneawork.it/blog/image-formats-avif-webp
> Markdown: https://ui.eneawork.it/blog/image-formats-avif-webp.md

*2026-11-01*

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.

Il 1 novembre 2026 public/blog-covers contiene 916 file PNG per 64.305.140 byte e 916 file SVG per 1.897.836 byte. La copertina /blog-covers/en/cosa-sono-i-core-web-vitals.png pesa 69.757 byte, la stessa in SVG 2.114 byte: 33 volte meno. Le varianti .webp e .avif dello stesso percorso rispondono 404, quindi non esistono. Byte misurati da disco e dal Content-Length con curl -sS. Il catalogo EneUI misura 111.985 componenti, 1.556 blocchi e 12.808 icone da 1.472 librerie, letti da /api/stats il 1 novembre 2026. Formati: MDN, licenza CC BY-SA 2.5; cwebp e avifenc sono strumenti con licenza BSD.

## Quattro formati, quattro lavori

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.avif

cwebp 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.

## FAQ

### 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.