La grafica non è fotografia: dove vince il lossless

“Converti tutto in AVIF” è un buon consiglio per le fotografie e, silenziosamente, un cattivo consiglio per tutto il resto. Uno screenshot, un logo, un grafico, un mockup di interfaccia, un disegno al tratto: sono elementi grafici, non foto, e i codec lossy che rendono AVIF e JPEG così efficaci sulle foto sono lo strumento sbagliato per loro.

Perché i codec lossy falliscono sulla grafica

JPEG, WebP lossy e AVIF sono costruiti per le fotografie: gradienti morbidi, texture naturale, nessun bordo netto. Funzionano scartando il dettaglio ad alta frequenza che l’occhio non noterà in una foto. Puntali su un elemento grafico e la stessa macchina si rivolta contro di te:

• Aloni sui bordi netti. Il testo e le icone non sono altro che bordi netti. Le trasformazioni lossy sfumano un alone di “rumore a zanzara” attorno a ogni lettera: l’artefatto per cui JPEG è noto fin dagli anni ‘90, e che sopravvive nei codec moderni sui bordi netti.
• Banding sui colori piatti. Un riempimento pieno o un gradiente pulito è esattamente ciò che la quantizzazione a blocchi trasforma in gradini visibili.
• Paghi per sfumare, e poi paghi di nuovo. Per nascondere quegli artefatti alzi la qualità, e un codec lossy spinto quasi al senza perdita su un elemento grafico finisce spesso per essere più grande di un codec lossless pensato apposta per quello, pur restando comunque non esatto.

Un elemento grafico ha pochi colori e una struttura netta. La mossa giusta è mantenerlo esatto e comprimere la ridondanza, non buttare via il dettaglio.

I numeri, su grafica reale

Abbiamo passato il set di elementi grafici del nostro benchmark (213 elementi grafici reali: loghi, grafici, interfacce, arte a colori piatti) attraverso gli strumenti costruiti apposta per loro, misurando il risparmio rispetto al PNG originale:

Il WebP senza perdita riduce questi elementi grafici circa a metà e ogni pixel resta identico. oxipng riottimizza il PNG stesso senza cambiare formato: sicuro ovunque. pngquant va oltre riducendo la palette; su arte a colori piatti il risultato è visivamente indistinguibile, su una foto sarebbe un disastro. Il che è proprio il punto: lo strumento deve corrispondere al contenuto.

La regola: classificare prima, comprimere dopo

L’errore non è scegliere WebP o scegliere PNG. È scegliere un solo codec per tutto. Una pipeline che distribuisce bene le immagini web deve guardare ogni asset e decidere cosa è prima di decidere come comprimerlo:

• Fotografia → AVIF/WebP lossy, qualità mirata a un punteggio percettivo (vedi i nostri numeri su AVIF vs WebP vs JPEG).
• Elemento grafico con una regione fotografica (uno screenshot di una foto) → la via lossy può comunque vincere.
• Elemento grafico a colori piatti, logo, grafico, disegno al tratto → senza perdita, in un formato di cui l’elemento grafico ha davvero bisogno.

È ciò che fa Patu: classifica ogni immagine e la instrada di conseguenza. Un elemento grafico resta senza perdita: ricodificato in modo esatto, non sfumato in un formato lossy che è al contempo più grande e peggiore. Una foto riceve la ricerca lossy mirata alla qualità. Stesso endpoint, trattamento opposto, perché sono problemi opposti.

Il consiglio di partenza resta valido con una parola in più: converti le tue foto in AVIF. Converti i tuoi elementi grafici nella forma senza perdita più piccola. Mandare entrambi nella stessa pipeline è come finisci con loghi sfocati e file più pesanti insieme.

Metodo e dati: l’harness di benchmark di Patu sulla categoria elementi grafici (213 elementi grafici reali); i risparmi sono la riduzione mediana rispetto al PNG originale, per strumento. oxipng e il WebP senza perdita sono esatti byte per byte; pngquant è una riduzione di palette lossy, quasi esatta su contenuti a colori piatti.