Il mosaico che si muove

Bentornati in bottega. Immaginate una cosa che nessun mosaicista dell'antichità ha mai potuto fare: un mosaico che cambia. Non un pannello, ma una sequenza di pannelli, e su ognuno solo le tessere che cambiano rispetto al precedente, posate sopra quelle di prima.

È l'animazione. Sul web, per decenni, ha avuto un solo nome: GIF. Un formato del 1987, con un limite di duecentocinquantasei colori per fotogramma e una compressione pensata per disegni a colori piatti. Ogni meme, ogni piccola animazione dimostrativa, ogni spinner di caricamento.

WebP ha provato a prenderne il posto. Oggi vediamo come è costruita un'animazione WebP e se, nel 2026, ha ancora senso usarla.

Un'animazione WebP usa il formato esteso, quindi comincia con il chunk VP8X, con il flag di animazione acceso. Le dimensioni dichiarate in VP8X sono quelle della tela, cioè dell'area complessiva su cui si disegnano tutti i fotogrammi.

Subito dopo, eventualmente dopo il profilo colore, c'è il chunk ANIM con i parametri globali. Sono solo due. Il primo è il colore di sfondo, scritto curiosamente nell'ordine blu, verde, rosso, alfa. È un suggerimento: i visualizzatori possono ignorarlo, e i browser di solito lo fanno, mostrando la trasparenza della pagina. Il secondo è il numero di ripetizioni: zero significa all'infinito, qualunque altro numero indica quante volte riprodurre l'animazione.

Poi arrivano i fotogrammi, ognuno in un chunk ANMF. E qui c'è l'idea centrale: un fotogramma non deve per forza coprire tutta la tela. Può essere un rettangolo più piccolo, posato in un punto preciso.

L'intestazione di ANMF contiene la posizione del rettangolo, con le coordinate di sinistra e di sopra, le sue dimensioni e la durata. Un dettaglio curioso: le coordinate sono salvate divise per due, quindi un fotogramma può partire solo da coordinate pari. È un piccolo risparmio di bit, e si collega al sottocampionamento del colore della compressione con perdita, che lavora per coppie di pixel.

La durata è in millisecondi, su ventiquattro bit. Un consiglio pratico: non contate su durate molto brevi. I browser, per ragioni storiche ereditate dal GIF, tendono a trattare le durate molto piccole in modo particolare, e il risultato può essere un'animazione più lenta di quanto vi aspettate.

Due bit nell'intestazione di ogni fotogramma decidono come si comporta rispetto alla tela. Sono il cuore dell'animazione efficiente.

Il primo è il metodo di fusione. Se la fusione è attiva, i pixel trasparenti del nuovo fotogramma lasciano vedere quelli già presenti sulla tela, e quelli semitrasparenti si mescolano. Se è disattivata, il rettangolo del fotogramma sostituisce in blocco ciò che c'era sotto, trasparenza compresa.

Il secondo è il metodo di smaltimento, che dice cosa fare del rettangolo quando il fotogramma è finito e si passa al successivo. Si può lasciarlo com'è, oppure riportare quell'area al colore di sfondo.

Con questi due interruttori un encoder intelligente fa una cosa molto efficiente. Prende la sequenza originale, fotogramma per fotogramma a tela piena, e per ognuno calcola il più piccolo rettangolo che contiene le differenze rispetto al precedente. Dentro quel rettangolo, i pixel rimasti uguali possono addirittura diventare trasparenti, così la fusione li lascia passare e comprimono quasi a zero. È il mosaicista che rifà solo le tessere che cambiano.

Dentro ogni ANMF ci sono i dati del fotogramma, e qui c'è una libertà che il GIF non aveva: ogni fotogramma può essere compresso con perdita, eventualmente con il suo chunk ALPH per la trasparenza, oppure senza perdita con un VP8L.

E i due tipi possono convivere nella stessa animazione. Un fotogramma fotografico con perdita, uno con una scritta netta senza perdita. Lo strumento di conversione da GIF di libwebp ha proprio un'opzione che prova entrambe le compressioni per ogni fotogramma e tiene la migliore.

C'è però una sottigliezza. Con la compressione con perdita e la fusione attiva, gli errori di un fotogramma restano sulla tela e il successivo ci si posa sopra. Su animazioni lunghe le imprecisioni si possono accumulare. Gli encoder seri lo sanno e ogni tanto inseriscono un fotogramma completo che riparte da capo. Ci tornano in mente i fotogrammi chiave di VP8, da cui è partito tutto.

libwebp offre due strumenti per creare animazioni. Il primo, gif2webp, converte un GIF esistente. Di default produce un'animazione senza perdita, quindi fedele all'originale: e già così spesso pesa meno del GIF, grazie a una compressione molto più moderna. Con l'opzione lossy usa la compressione con perdita, con mixed sceglie fotogramma per fotogramma, e con min_size cerca la combinazione più piccola a scapito del tempo.

Il secondo, img2webp, costruisce un'animazione partendo da una serie di immagini singole, con durata e tipo di compressione per ogni fotogramma.

E poi c'è webpmux, il coltellino svizzero del contenitore: estrae un singolo fotogramma, ne aggiunge uno, cambia la durata o il numero di ripetizioni senza ricomprimere nulla. Ne parleremo nel prossimo episodio, insieme agli altri attrezzi.

Contro il GIF, WebP vince praticamente su tutto. Milioni di colori invece di duecentocinquantasei. Trasparenza a più livelli invece che pieno o vuoto. Compressione con perdita quando serve. File in genere molto più piccoli, spesso meno della metà.

Il GIF ha ancora un vantaggio: va ovunque. Ogni programma di posta, ogni chat, ogni editor di documenti lo apre. Il WebP animato, fuori dai browser, ha ancora un supporto più irregolare.

Ma il confronto più onesto, nel 2026, non è con il GIF. È con il video.

Se la vostra "animazione" è in realtà un pezzo di video, un clip di qualche secondo preso da una registrazione, un codec video moderno in un elemento video muto e in loop fa di solito molto meglio. Un codec video sfrutta la predizione tra fotogrammi con il movimento, cosa che WebP animato non fa: ogni fotogramma è indipendente, al massimo si posa sopra il precedente. E il video ha spesso la decodifica hardware, mentre WebP animato si decodifica tutto sul processore, fotogramma per fotogramma. Su un telefono economico, una pagina con molte animazioni WebP grandi si sente.

Dove WebP animato ha ancora senso? Animazioni brevi e piccole, sticker, icone animate, interfacce, contenuti con trasparenza. In questi casi l'elemento img è più semplice da usare di un video, si comporta come un'immagine e la trasparenza è garantita.

Ricapitolando: un'animazione WebP è un formato esteso con il flag di animazione, un chunk ANIM con sfondo e ripetizioni, e una serie di chunk ANMF, ognuno con posizione, dimensioni, durata, fusione e smaltimento, e i suoi dati con o senza perdita. È molto meglio del GIF, ma per i clip veri il video resta la scelta migliore.

Con questo episodio abbiamo finito il giro dei laboratori della bottega. Dal prossimo si passa alla pratica: apriamo la cassetta degli attrezzi di libwebp e vediamo i parametri di cwebp che contano davvero. Ci sentiamo lì.