Prova: WebP contro JPEG+PNG - da 540 a 120 MB, ma il web non è ancora pronto

Presentato al grande pubblico sul finire del 2010, WebP è un formato grafico alternativo ai più noti JPEG, PNG e GIF. Rispetto ai predecessori, però, supporta sempre trasparenza (canale alpha) ed animazioni, oltre ad impiegare algoritmi e tecnologie di compressione nettamente più efficienti. La mia prova ha confermato risultati sbalorditivi: tuttavia, è troppo presto per adottarlo su larga scala.

Saltiamo alle conclusioni

WebP funziona come promesso e la sua adozione potrebbe contribuire significativamente a ridurre i tempi di caricamento delle pagine web. Purtroppo, è ancora scarsamente supportato e senza segnali incoraggianti per l'imminente futuro. Di conseguenza, l'impiego su progetti concreti è ancora prematuro.

La prova

Per la mia prova ho preso in esame la cartella che conserva le immagini degli articoli di TurboLab.it. Si tratta di una collezione di 3.300 file in formato PNG e JPEG con dimensioni variabili fra 6.5 MB e 2 kB, fra i quali fotografie, screenshot e clipart assortite. Peso complessivo: 540 MB.

Ho convertito ogni singolo file in formato WebP tramite l'utilità cwebp, impostando la modalità lossy (WebP può funzionare in modalità lossless (senza perdita di qualità rispetto agli originali, ma con un risultato finale meno compresso) oppure lossy (perdita di qualità regolabile, ma dimensioni in uscita più ridotte) con indice di qualità 75 nella scala 0-100 e altri parametri per massimizzare l'efficienza a discapito dei tempi di elaborazione. Il comando finale è stato FOR /R "%dir_in%" %%F in (*.*) do ("%convert_exe%" %%F -q 75 -m 6 -mt -af -alpha_cleanup -o %dir_out%\%%~nF.webp). 

In totale, l'operazione ha richiesto 35 minuti e 15 secondi con un occupazione costante (osservata empiricamente) pari al 30-40% della CPU Intel Core i5 3570K @ 3.40 GHz. Sono stati correttamente restituiti tutti i 3.300 file forniti in input. Peso complessivo: 120 MB.

In questo caso, la riduzione complessiva è stata pari al 78% circa.

Dal punto di vista qualitativo, un confronto empirico fra una decina di immagini-campione selezionate a caso non ha rilevato alcun peggioramento apprezzabile ad occhio nudo.

La compatibilità

I risultati d'eccellenza emersi durante il test mi hanno portato a valutare la scelta di convertiretutte le immagini presenti negli articoli, riducendo così di parecchi kB il peso di ogni pagina e, quindi, i tempi di caricamento. Purtroppo, però, il contesto tecnologico di contorno non è ancora sufficientemente maturo.

A livello di sistemi operativi, la situazione è critica. Nessuno supporta WebP nativamente e, di conseguenza, Windows, OS X, Linux e tutti gli altri mostrano un'icona generica associata ai file .webp all'interno dei vari Esplora risorse, invece della consueta anteprima. Il visualizzatore immagini di Windows, inoltre, non è in grado di aprire direttamente i file: basta installare il pacchetto WebP Codec for Windows per risolvere entrambi i problemi, ma va da sé che si tratta di una complicazione in più.

Ma il problema di fondo riguarda i browser web: a febbraio 2015, solo Chrome e Opera supportano WebP. Internet Explorer, Firefox e Safari, al contrario, non gestiscono la specifica e si rifiutano di visualizzare qualsiasi immagine compressa con questa specifica.

Di più: in questo momento, il fondamentale contributo di Microsoft nello spingere la soluzione non è nemmeno nell'aria. Il supporto a WebP nelle prossime iterazioni di Internet Explorer è apertamente bollato come "non previsto". Allo stesso modo, Mozilla ha un bug aperto da parecchio tempo, ma non è chiaro se la Fondazione sia intenzionata a lavorarci.

WebP per tutti, con uno "shim"?

Stando così le cose, l'unica àncora di salvezza potrebbe essere uno shim, ovvero una libreria Javascript che i webmaster interessati devono inserire in ogni pagina per trasformare automaticamente le immagini WebP in qualcosa di comprensibile per il browser dell'utente.

Uno dei più raccomandati è WebPJS, progetto realizzato da un appassionato che distribuisce il tutto gratuitamente e rende WebP "digeribile" già a partire da Internet Explorer 6. Purtroppo, lo stesso WebPJS è interessato da alcune limitazioni: pur trascurando il fatto che lo sviluppo è fermo da oltre un anno, che permangono alcune difficoltà con le WebP trasparenti e che l'esito delle mie prove ha dato risultati altalenanti, la libreria impiega un'animazione Flash (.swf) per lavorare con Internet Explorer. Di conseguenza, è incompatibile con la declinazione "touch" e funziona a dovere solo in caso sia installato Flash Player.

Allo stesso modo, la dipendenza da uno shim fa sì che le immagini non siano visualizzabili se incorporate all'interno di pagine esterne e siano inutilizzabili una volta salvate in locale.

Certo, per i progetti più piccoli potrebbero essere considerazioni irrilevanti, ma in molti storceranno il naso.

La vera soluzione temporanea: differenziare

A chi non fosse disposto ad accettare l'uso dello shim rimane una sola strada: differenziare, servendo le più piccole e veloci immagini WebP ai browser che lo supportano e le più compatibili JPEG, PNG o GIF a tutti gli altri.

Tuttavia, questo approccio ha delle complessità intrinseche non immediatamente evidenti. Sebbene la gestione in sé non sia difficile, permane per i webmaster l'onere di conservare sul server due copie per ogni file (una JPEG/GIF/PNG e una WebM).

In una web application come TurboLab.it, questa operazione sarebbe piuttosto gravosa: considerando che il nostro sito memorizza già oggi quattro copie di ogni file grafico (l'originale + quello ridimensionato per l'anteprima + quello inserito nel corpo dell'articolo + quello ingrandito che si apre cliccando sull'immagine), ci si ritroverebbe con ulteriori tre copie .webp per ogni grafica: non certo insostenibile, ma potenzialmente ulteriormente dispendioso da archiviare sul singolo SSD a nostra disposizione sul lungo periodo.