Convertire WebP in AVIF

Questo sito tiene tre scene campione e le codifica con la stessa pipeline usata da questa pagina, quindi i numeri sono quello che produce davvero questo convertitore, non un dato letto altrove. Alla qualità predefinita: la grafica piatta pesa meno in AVIF, la scena tipo screenshot pesa quasi la metà, ma la fotografia risulta più pesante in AVIF che in WebP.

La fotografia è il caso che conta di più, perché una fotografia è ciò di cui è fatto quasi ogni budget di immagini di un sito. Lì l’AVIF ha perso. Questo non rende il formato cattivo — a qualità più basse e su immagini più grandi l’ordine spesso si ribalta — ma rende «l’AVIF pesa un terzo in meno del WebP» un’affermazione da verificare sui propri file prima di riconvertire un’intera libreria.

Il pattern in quei numeri non è casuale. La predizione intra di AV1 è particolarmente brava su grandi aree di colore quasi costante separate da bordi netti, e ha più modalità di predizione e partizionamento a disposizione per definire un bordo con esattezza rispetto alla codifica derivata da VP8 del WebP.

Questo descrive schermate di interfacce, diagrammi, grafici, illustrazioni, foto prodotto su sfondo neutro e tutto ciò che contiene testo — su un sito tipico una quota grande del numero di immagini anche quando pesa poco in byte. Sono quelle da convertire per prime; le immagini fotografiche di apertura vanno misurate una per una.

La conversione decodifica il WebP in pixel e codifica quei pixel come AVIF. Se il WebP era già lossy, i suoi artefatti — aree piatte lisciate, aloni lungo i bordi — fanno ormai parte dell’immagine, e il codificatore AVIF li riproduce fedelmente aggiungendo un secondo strato tutto suo.

Nella maggior parte dei casi non è drammatico ed è spesso evitabile: molti siti hanno ancora il PNG o il JPG originale in un archivio o in uno strumento di design, e codificare l’AVIF da lì produce un file più pulito e spesso più leggero. Questa pagina serve per il caso in cui il WebP è davvero l’unica copia rimasta — un asset convertito da un CDN, un sito ereditato, una cartella riordinata da qualcun altro.

Il WebP è supportato da ogni browser attuale. L’AVIF è supportato dai browser moderni, ed è un’affermazione diversa: un dispositivo datato, una macchina aziendale bloccata, un browser interno a un’app possono arrivare sulla pagina e non ottenere nulla, perché un’immagine che non si riesce a decodificare non è un’immagine degradata, è una casella vuota.

La soluzione è nota ed economica: un elemento picture con una sorgente AVIF e un ripiego WebP o JPG costa due righe di markup e azzera il rischio. Questo però significa mantenere entrambi i file, cosa da tenere a mente se lo scopo della migrazione era ridurre lo spazio occupato piuttosto che il traffico.

AV1 compra la sua compressione con l’analisi, e il codificatore qui è libavif compilato in WebAssembly. Convertire un WebP in AVIF è nettamente più lento di qualunque altra coppia di questa famiglia: la decodifica è rapida, la codifica no, e su un’immagine grande si tratta di secondi, non di millisecondi.

Il costo cade dove deve: una volta sola, sulla tua macchina, quando decidi tu, non ad ogni visita. Cambia però come si porta avanti una migrazione: una cartella di centinaia di asset è un lavoro da avviare e lasciare andare, non da guardare, e conviene convertire prima le immagini piatte, quelle che ci guadagnano davvero.

La trasparenza sopravvive senza problemi: entrambi i formati portano un canale alfa a 8 bit completo, e l’AVIF è efficiente su questo, tanto che i ritagli di prodotto e i loghi sono tra gli asset dove vince più spesso. I bordi morbidi restano morbidi, senza aloni.

Non succede invece nessun guadagno in profondità o gamma colore. L’AVIF può arrivare a dodici bit per canale e a colori wide-gamut, ma questa pipeline decodifica tutto in RGB a 8 bit, e il WebP di partenza era già a 8 bit: non c’è nulla da promuovere. Chi vuole spostare una libreria verso HDR deve partire dagli scatti originali, non da asset web già a 8 bit.

Il controllo va da 1 a 100 e parte da 82, e lo stesso numero non significa la stessa cosa per due codec diversi. Poiché la sorgente è già un WebP lossy, ha senso impostarlo un po’ più alto del solito: il codificatore sta cercando di riprodurre un’immagine che ha già una struttura che non ha messo lui.

Il metodo pratico è convertire tre immagini rappresentative a qualità diverse e confrontare sia i byte sia l’aspetto alla dimensione a cui la pagina le mostra davvero. Richiede dieci minuti e risolve la questione per l’intera libreria molto meglio di una regola generica. Sulle immagini con testo conviene restare alti: è la prima cosa che qualunque codec lossy degrada e la prima che un visitatore nota.

Se gli asset sono già in WebP e la pagina rispetta il suo budget di prestazioni, il consiglio onesto è non fare nulla. Il passaggio da JPG o PNG a WebP è quello che ha prodotto il grande risparmio; il passaggio da WebP ad AVIF è un guadagno di secondo ordine che a volte è negativo, costa tempo di codifica e aggiunge un ripiego da mantenere.

I casi che lo giustificano chiaramente sono le immagini grandi e piatte, le pagine ricche di immagini dove il risparmio aggregato si misura, e i siti pieni di schermate o diagrammi. Quelli che non lo giustificano sono le icone piccole, le immagini già sotto pochi kilobyte, e gli asset fotografici dove la misura mostra l’AVIF più pesante.

Entrambi i codec girano nella scheda come WebAssembly e vengono scaricati solo quando arriva un file di quel tipo, quindi un gruppo di cento immagini scarica il codificatore una sola volta. Niente di quei file attraversa la rete, cosa che conta quando gli asset appartengono a un cliente o a un sito non ancora pubblicato.

Il limite gratuito è 100 MB per file, ben oltre qualunque asset web. Un WebP animato nella cartella viene rifiutato invece di essere appiattito in silenzio — il decodificatore qui legge solo immagini fisse — quindi una cartella mista produrrà qualche errore e completerà il resto, il comportamento giusto quando l’alternativa sarebbe un set di fermi immagine non richiesti.