La bottega

Ciao e benvenuti alla stagione novantatré. Per i prossimi dieci episodi entriamo in una bottega. Non una bottega qualsiasi: quella di un mosaicista.

Avete presente come lavora chi fa mosaici? Non dipinge una superficie continua. Prende migliaia di piccole tessere, ognuna di un solo colore, e le avvicina abbastanza da far sparire i bordi. Da lontano vedete un volto, un paesaggio, una scritta. Da vicino vedete quadratini. Ecco, un'immagine digitale compressa funziona in modo molto simile, e WebP in particolare ragiona proprio per blocchi, per tessere.

In questa stagione apriamo la bottega, guardiamo gli attrezzi, i materiali, le tecniche. E alla fine capiremo quando ha senso usare WebP nel 2026, adesso che intorno a lui ci sono AVIF e JPEG XL.

Partiamo dalla domanda più semplice: perché qualcuno dovrebbe inventare un nuovo formato di immagine?

Nel 2010 il web aveva sostanzialmente tre formati. JPEG per le fotografie, nato all'inizio degli anni Novanta. PNG per la grafica con colori netti e per la trasparenza, nato a metà degli anni Novanta come risposta ai problemi di brevetto del GIF. E proprio GIF, che continuava a esistere per una sola ragione: le animazioni.

Ognuno faceva bene una cosa sola. Se avevate una fotografia di un prodotto con lo sfondo trasparente, il JPEG non poteva darvi la trasparenza e il PNG vi dava un file enorme, perché comprime senza perdita anche le sfumature di una foto. Se volevate un'animazione, il GIF vi costringeva a 256 colori per fotogramma.

E nel frattempo le immagini erano diventate la parte più pesante di una pagina web. Non il JavaScript, non il CSS: i byte delle immagini. Ridurli anche solo di un quarto significava pagine più veloci per tutti, e per un'azienda come Google, che vive di pagine che si caricano in fretta, significava molto.

Qui entra in gioco una storia che sembra non c'entrare nulla con le immagini. All'inizio del 2010 Google completa l'acquisizione di On2 Technologies, un'azienda che sviluppava codec video. Il gioiello di On2 si chiamava VP8. A maggio dello stesso anno Google rilascia VP8 come formato aperto, all'interno del progetto WebM, come alternativa libera ai codec video coperti da brevetti.

Ora, un codec video come VP8 distingue due tipi di fotogrammi. Ci sono i fotogrammi che descrivono solo le differenze rispetto ai precedenti, e ci sono i fotogrammi chiave, quelli che stanno in piedi da soli e contengono un'immagine completa. Un fotogramma chiave è, in pratica, una fotografia compressa.

L'idea di WebP, annunciato da Google il 30 settembre 2010, è questa: prendiamo la tecnica con cui VP8 comprime un fotogramma chiave, togliamo tutto ciò che riguarda il video, e mettiamo il risultato in un contenitore leggerissimo. Un mosaicista direbbe: ho trovato un fornitore di tessere eccellenti, le uso per i miei pannelli.

E così il primo WebP era solo questo: compressione con perdita, niente trasparenza, niente animazione. Una fotografia più piccola di un JPEG equivalente.

Un formato che sa fare solo foto non poteva sostituire PNG e GIF. Così negli anni successivi la bottega si è allargata.

Tra il 2011 e il 2012 arriva la compressione senza perdita, che non deriva da VP8 ma è un algoritmo progettato da zero da un gruppo di Google guidato da Jyrki Alakuijala, lo stesso ricercatore che poi lavorerà a Brotli e a JPEG XL. Arriva la trasparenza, anche abbinata alla compressione con perdita: ed è una combinazione che né JPEG né PNG potevano offrire. E arriva l'animazione, con fotogrammi che possono essere ognuno compresso con o senza perdita.

Per contenere tutto questo, il contenitore si è evoluto in una versione estesa, capace di dichiarare in anticipo quali funzioni usa il file: profilo colore, trasparenza, metadati, animazione. Ne parleremo per bene nel prossimo episodio, perché la cornice di un mosaico dice molto su come è stato costruito.

Un formato per il web vale quanto il supporto dei browser. E qui la storia di WebP è lunga e un po' tortuosa.

Chrome lo supporta già nei primi mesi del 2011, Opera poco dopo. Per anni però è rimasto un formato "di Google", con gli altri browser scettici. Microsoft Edge lo adotta nel 2018. Firefox arriva con la versione 65, a gennaio 2019. L'ultimo grande assente era Safari, che lo introduce con la versione 14 nel 2020.

Pensateci: dieci anni dall'annuncio al supporto universale. Per tutto quel decennio, chi voleva usare WebP doveva servire un formato alternativo ai browser che non lo capivano. È il motivo per cui ancora oggi trovate tanto codice con l'elemento picture e una fonte di riserva in JPEG. Ne parleremo nell'episodio otto, dedicato a come si espone il mosaico.

L'ultimo passaggio della storia è quello più burocratico, ma importante. Per anni la specifica di WebP è vissuta come documentazione pubblicata da Google insieme alla libreria di riferimento, libwebp. Funzionava, ma non era uno standard nel senso formale.

A novembre 2024 la IETF pubblica la RFC 9649, intitolata semplicemente "WebP Image Format". È una RFC informativa: descrive il contenitore, il formato senza perdita, e registra ufficialmente il media type image/webp. Per la parte con perdita rimanda alla RFC 6386, quella che descrive il bitstream di VP8.

È un po' come quando il mosaico di una bottega viene finalmente iscritto nel catasto: esisteva già, tutti lo vedevano, ma adesso c'è un documento di riferimento che chiunque può citare.

Prima di entrare in bottega sul serio, mettiamo in fila le promesse. Google ha sempre dichiarato due numeri: le immagini senza perdita sono circa il 26% più piccole dei PNG, quelle con perdita tra il 25 e il 34% più piccole dei JPEG con un indice di somiglianza strutturale equivalente.

Sono numeri da prendere con le pinze, come tutti i numeri dichiarati da chi ha creato il formato. Dipendono dall'immagine, dall'encoder JPEG con cui confrontate, dalla metrica. Nei prossimi episodi vedremo che un JPEG ben ottimizzato può avvicinarsi molto, e che ci sono immagini in cui WebP con perdita fa peggio. Ma l'ordine di grandezza regge: per la maggior parte delle immagini del web, WebP pesa sensibilmente meno.

Ci sono anche limiti precisi, che conviene conoscere subito. La versione con perdita lavora solo a otto bit per canale e solo con il colore sottocampionato, il famoso quattro-due-zero. Niente HDR, niente dieci bit. Le dimensioni massime sono 16383 pixel per lato. E la decodifica avviene sul processore, senza l'aiuto dei decodificatori hardware che invece abbiamo per i video.

Ecco il percorso. Nel secondo episodio guardiamo la cornice: il contenitore RIFF, byte per byte. Nel terzo il disegno a mano libera, cioè la compressione con perdita: blocchi, predizione, trasformata, quantizzazione. Nel quarto la tessera esatta, la compressione senza perdita. Nel quinto il vetro, la trasparenza. Nel sesto il mosaico che si muove, l'animazione.

Poi passiamo alla pratica. Nel settimo episodio gli attrezzi: cwebp e gli altri strumenti di libwebp, con i parametri che contano davvero. Nell'ottavo l'esposizione: come servire WebP sul web, tra HTML, intestazioni HTTP e cache. Nel nono WebP nel codice: Go, PHP, Laravel, Node.js, Python. E nel decimo la crepa nel mosaico, la vulnerabilità del 2023, e il confronto con AVIF e JPEG XL.

Quindi, ricapitolando: WebP nasce nel 2010 prendendo in prestito le tessere di un codec video, VP8. Cresce aggiungendo la compressione senza perdita, la trasparenza e l'animazione. Impiega dieci anni a essere supportato da tutti i browser e diventa una RFC nel 2024.

Nel prossimo episodio prendiamo in mano un file WebP e lo apriamo: dodici byte di intestazione, poi una sequenza di blocchi etichettati. La cornice del mosaico. Ci sentiamo lì.