WebP

WebP è un formato immagine sviluppato da Google nel 2010 e standardizzato nel 2018. Supporta compressione lossy e lossless nello stesso formato, alpha completo (trasparenza) e animazione. Comprime il 25-35% in meno di JPG a qualità visiva equivalente.

Supporto browser nel 2026: ~97% globalmente. Safari è stato l’ultimo grande holdout, aggiungendo WebP nella versione 14 (settembre 2020). Il restante 3% sono vecchie versioni Android, residui IE11 e browser incorporati.

La modalità lossy di WebP è basata su VP8 (il codec video open di Google, usato dal video WebM). Usa block-prediction-and-transform simile a H.264, applicato a un singolo frame. Il risultato: una compressione significativamente migliore rispetto al DCT dell’era 1992 di JPG.

Uso pratico:

• Per nuovi contenuti web: WebP prima, fallback JPG tramite <picture>.
• Per sostituire JPG esistenti: facile riduzione del 25-35% delle dimensioni, senza regressione di qualità.
• Per sostituire PNG con alpha: WebP lossless + alpha è notevolmente più piccolo di PNG (spesso il 30-50% delle dimensioni).
• vs AVIF: AVIF è ancora più piccolo (~20% più piccolo di WebP a qualità equivalente) ma codifica 10-100× più lentamente e ha un supporto browser più ristretto (~93% nel 2026). WebP è il default più sicuro.

Converti qualsiasi immagine in WebP nel tuo browser tramite i nostri convertitori di immagini.

La storia dell’acquisizione di On2 — perché esiste WebP: Google ha acquisito On2 Technologies nel febbraio 2010 specificamente per il codec video VP8, poi ha rilasciato VP8 come open-source sotto una licenza permissiva in stile BSD. WebP è stato annunciato otto mesi dopo come formato di immagine fissa derivato da un singolo keyframe VP8. Il prezzo di acquisizione era di $124,6 milioni — pagato in parte per fornire un’alternativa priva di brevetti a HEIF/HEIC, il cui pool di licenze era incompatibile con il deployment esteso nei browser. La stessa logica strategica ha prodotto VP9, AV1 e alla fine AVIF.

L’asimmetria del cursore di qualità: il cursore di qualità lossy di WebP va da 0 a 100 come quello di JPG, ma le curve sono diverse — qualità 80 in WebP è visivamente equivalente a circa qualità 90 in JPG con una dimensione di file notevolmente inferiore. Il codificatore WebP lossless ignora completamente il flag di qualità; invece, un parametro -m method (0-6) scambia il tempo di codifica con una compressione più efficiente. Strumenti come cwebp (il codificatore di riferimento), sharp (Node.js) e squoosh (browser) espongono tutti queste impostazioni. Per le pipeline di build automatizzate, qualità 75-80 lossy è il punto ideale tipico; per icone e grafiche dove l’alpha è importante, lossless con method 6 è il punto ideale. Correlato: AVIF, lossless, lossy. Riferimento: Google — WebP, A new image format for the Web.

Esempio pratico

Prendi una foto hero 1920×1080, originalmente un JPG da 480 KB a qualità 85. Converti in WebP a qualità 80 con cwebp: cwebp -q 80 hero.jpg -o hero.webp → ~320 KB, una riduzione del 33% a qualità visivamente indistinguibile. Converti la stessa sorgente in PNG lossless: ~3,2 MB. Ora immagina che la stessa sorgente necessiti di un ritaglio con canale alpha per un render di prodotto. Salva come PNG-24 con alpha: ~1,8 MB. Salva come WebP lossless: ~650 KB (una riduzione del 64%). Su una tipica pagina e-commerce con 30 immagini di prodotti, sostituire le sorgenti JPG/PNG con WebP può ridurre il payload delle immagini da ~6 MB a ~3 MB — migliorando direttamente l’LCP (Largest Contentful Paint) di 1-2 secondi su una connessione 3G, il che si traduce direttamente in Core Web Vitals e posizionamento SEO.

Quando e perché è importante

Il payload delle immagini è tipicamente il maggiore singolo contributore al peso delle pagine mobile, e i Core Web Vitals (in particolare LCP) sono un fattore di ranking documentato di Google. L’ottimizzazione delle performance più economica per qualsiasi sito con molte immagini è aggiungere un elemento <picture> con sorgenti WebP e AVIF accanto ai fallback JPG — il moderno Next.js (next/image), Astro, Eleventy e Nuxt lo fanno automaticamente. Le poche situazioni in cui WebP non è la risposta giusta: quando l’asset verrà modificato a valle (usare un master lossless), quando il pubblico target usa browser che non lo supportano (Android molto vecchi, certi webview incorporati — fornire fallback JPG/PNG), e quando l’immagine è una fotografia per la stampa (usare TIFF o il RAW originale). Per tutto il resto servito a un browser web moderno nel 2026, WebP-o-AVIF dovrebbe essere il default e JPG un fallback legacy. Riferimento: web.dev — Servire immagini in formato WebP.