Che cosa ti fa davvero risparmiare WebP lossless rispetto a PNG

La versione breve

WebP lossless è spesso più piccolo di PNG a parità di pixel. Questo è il motivo pratico per cui le persone lo usano.

Ma la parola "spesso" conta. WebP lossless non è un sostituto magico per ogni PNG. Tende a far risparmiare di più sulle immagini con trasparenza, screenshot, acquisizioni UI e contenuti misti grafica/foto. Può far risparmiare poco, o occasionalmente perdere, su asset molto piccoli, PNG a palette fortemente ottimizzati e icone semplici.

Se stai ottimizzando un sito reale, la domanda giusta non è "WebP è migliore di PNG?" È: "Quali dei miei PNG diventano significativamente più piccoli come WebP lossless, senza creare problemi di compatibilità o di workflow?"

È una domanda più ristretta, e molto più facile da rispondere.

Che cosa significa "lossless" qui

Lossless significa che i pixel decodificati corrispondono esattamente ai pixel sorgente. Se un PNG viene convertito in WebP lossless e poi decodificato di nuovo, i pixel dell’immagine dovrebbero essere identici.

Non significa che il file sia lo stesso. Metadati, gestione dei profili colore, chunk PNG accessori, informazioni gamma, timestamp e chunk specifici degli strumenti possono essere modificati, rimossi o rappresentati diversamente a seconda della tua pipeline di conversione.

Questa distinzione conta se hai a che fare con immagini d’archivio, workflow di stampa, immagini scientifiche, prove legali o qualsiasi situazione in cui il contenitore del file trasporta informazioni non-pixel importanti. Per la normale distribuzione web, la maggior parte dei team si preoccupa soprattutto di pixel visivi, trasparenza, dimensioni e coerenza del colore.

Se pubblichi immagini fornite dagli utenti, anche i metadati sono una questione di privacy. Abbiamo trattato questo tema più ampio in come rimuovere i metadati EXIF prima di condividere foto online, ma lo stesso principio vale qui: l’ottimizzazione delle immagini dovrebbe essere esplicita su ciò che conserva e ciò che rimuove.

Perché PNG comprime bene, e dove si ferma

PNG è un ottimo formato. È diventato uno standard del web per buone ragioni:

• È lossless.
• Supporta la trasparenza alpha.
• È ampiamente supportato.
• È prevedibile e semplice da gestire.
• È eccellente per grafiche piatte, screenshot, loghi e asset UI.

La compressione PNG funziona filtrando le righe dell’immagine e poi applicando la compressione DEFLATE. Questa combinazione è efficace, soprattutto quando i pixel vicini sono simili.

Il problema non è che PNG sia cattivo. Il problema è che PNG è vecchio. Il suo modello di compressione ha meno trucchi disponibili rispetto ai formati più recenti. Una volta ottimizzato un PNG con un buon encoder, potresti comunque lasciare byte sul tavolo perché il formato stesso non può rappresentare alcuni pattern con la stessa efficienza di WebP lossless.

È qui che entra in gioco WebP lossless.

Che cosa fa diversamente WebP lossless

WebP lossless usa un sistema di compressione progettato specificamente per le immagini, invece di un livello di compressione generico applicato a righe filtrate. Sotto il cofano, può usare tecniche come codifica predittiva, trasformazioni del colore, palette, riferimenti all’indietro e codifica entropica per rappresentare in modo compatto pattern di pixel ripetuti o prevedibili.

Non devi memorizzare i dettagli dell’implementazione. Il modello mentale utile è questo:

PNG comprime bene le righe. WebP lossless ha più modi per descrivere la struttura dell’immagine.

Questa flessibilità extra è il motivo per cui WebP lossless può spesso produrre file più piccoli a partire dalla stessa immagine sorgente.

Google ha storicamente descritto le immagini WebP lossless come circa il 26% più piccole di PNG in media nei propri studi. Consideralo un benchmark orientativo, non una promessa. Le tue immagini non sono una media. Il tuo design system, gli screenshot, le foto prodotto, le illustrazioni, gli asset esportati e gli upload del CMS avranno un comportamento proprio.

Dove WebP lossless di solito fa risparmiare di più

Immagini trasparenti

PNG viene comunemente usato per via della trasparenza alpha. Anche WebP lossless supporta l’alpha, e spesso lo comprime in modo efficiente.

Questo è utile per:

• Scontorni di prodotto
• Sticker e badge
• Overlay di interfaccia
• Diagrammi con sfondi trasparenti
• Loghi esportati più grandi del necessario

Il risparmio può essere evidente quando il canale alpha contiene grandi regioni prevedibili, bordi morbidi o forme ripetute. Se hai un catalogo pieno di immagini prodotto trasparenti, vale la pena testare presto WebP lossless.

Screenshot e acquisizioni UI

Gli screenshot spesso contengono grandi aree piatte, componenti di interfaccia ripetuti, testo, icone, ombre e alcune regioni fotografiche. Questa combinazione può essere scomoda per PNG, soprattutto a grandi dimensioni.

WebP lossless spesso gestisce bene queste immagini. Uno screenshot UI a pagina intera che pesa 900 KB come PNG ottimizzato potrebbe diventare 500–700 KB come WebP lossless. A volte il risparmio è maggiore. A volte è minore. Ma la categoria è promettente.

Se quegli screenshot compaiono in documentazione, pagine marketing, flussi di onboarding o case study, l’effetto complessivo può essere reale.

Contenuti misti illustrazione e immagine

Molte grafiche web moderne non sono né illustrazioni pure né foto pure. Pensa a una hero image che contiene UI di prodotto, gradienti, piccole icone, etichette di testo e foto incorporate.

PNG può preservarla perfettamente ma produrre un file grande. WebP o AVIF lossy possono creare artefatti attorno a testo e bordi se spinti troppo. WebP lossless può essere una via di mezzo sensata quando i bordi esatti contano.

Per un albero decisionale più ampio sui formati immagine, inclusi AVIF e WebP lossy, vedi Formati immagine nel 2026: quando AVIF batte WebP e quando no.

Dove PNG può essere ancora migliore

Icone minuscole e asset semplici

Per file molto piccoli, l’overhead del formato conta. Un’icona PNG da 650 byte non è una candidata ovvia alla conversione. WebP potrebbe far risparmiare 80 byte, oppure potrebbe diventare più grande.

A quella scala, la complessità operativa può superare il beneficio. Se il file è già minuscolo, non blocca il rendering ed è memorizzato in cache a lungo, probabilmente hai cose migliori da sistemare.

PNG a palette attentamente ottimizzati

Alcuni PNG sono molto più piccoli di quanto ci si aspetti perché usano una palette limitata. Un buon PNG a colori indicizzati può essere difficile da battere per grafiche semplici.

Questo è particolarmente vero per:

• Loghi piccoli
• Pixel art
• Icone piatte
• Diagrammi semplici
• Grafiche con pochi colori

Fai attenzione quando confronti WebP con esportazioni PNG approssimative. Se il PNG arriva direttamente da uno strumento di design con metadati inutili e impostazioni di compressione scadenti, WebP può sembrare drasticamente migliore. Questo non significa che WebP batta un PNG ben ottimizzato con lo stesso margine.

Un test corretto confronta WebP lossless con PNG ottimizzato, non con qualunque file sia stato caricato.

Immagini che dovrebbero essere lossy invece

Questo è l’errore silenzioso: i team convertono PNG in WebP lossless quando l’immagine non avrebbe dovuto essere PNG fin dall’inizio.

Le fotografie sono il caso tipico. Una fotografia a colori pieni salvata come PNG può essere enorme. Convertirla in WebP lossless può ridurre il file, ma di solito resterà comunque molto più grande di un WebP lossy o AVIF di alta qualità.

Se l’utente non riesce a percepire la differenza, lossless è spesso l’obiettivo sbagliato. Fotografia di prodotto, immagini editoriali, sfondi e ritratti di solito appartengono a un formato lossy con impostazioni di qualità sensate.

Lossless dovrebbe essere riservato ai casi in cui i pixel esatti contano: screenshot UI, diagrammi, grafiche ricche di testo, trasparenza, grafici generati e asset che degradano visibilmente con la compressione lossy.

Che cosa fa risparmiare oltre ai byte

Il risparmio ovvio è la dimensione di trasferimento. File immagine più piccoli di solito significano meno banda, download più rapidi e comportamento migliore su connessioni lente.

Ma ci sono benefici secondari:

• Meno dati usati dai visitatori con piani a consumo
• Popolamento più rapido della cache immagini
• Riduzione della banda CDN
• Minori volumi di storage e backup su larga scala
• Meno pressione sui budget di performance

Questi risparmi non sono distribuiti uniformemente. Un singolo PNG da 2 MB convertito in un WebP da 900 KB conta più di cinquanta icone ridotte di 100 byte ciascuna.

Per questo l’ottimizzazione delle immagini dovrebbe essere prioritizzata in base all’impatto sulla pagina, non all’ideologia del formato. Se Lighthouse segnala la distribuzione delle immagini, leggilo come un indizio, non come una sentenza. La nostra guida su come leggere un report Lighthouse senza andare nel panico spiega come separare i problemi di performance significativi dalla diagnostica rumorosa.

Il compromesso sul costo di decodifica

File più piccoli non sono l’unica variabile di performance. I browser devono anche decodificare le immagini prima di disegnarle.

La decodifica PNG è matura e di solito veloce. Anche la decodifica WebP è ampiamente supportata ed efficiente, ma in alcuni casi può costare più CPU. Sui dispositivi moderni raramente è un blocco, ma su telefoni di fascia bassa, pagine ricche di immagini o grandi asset above-the-fold, vale la pena misurare.

La regola pratica: se WebP lossless riduce un grande PNG del 30–50%, il risparmio di rete di solito domina. Se riduce un piccolo PNG del 3%, probabilmente il compromesso non merita attenzione.

Il lavoro sulle performance è pieno di decisioni di soglia come queste. Non ottimizzare ogni byte con la stessa intensità.

Un metodo di test semplice

Usa un batch rappresentativo, non una sola immagine.

Crea una cartella con esempi dal tuo sito reale:

• Loghi e icone
• Screenshot
• Scontorni di prodotto
• Diagrammi
• PNG caricati nel CMS
• Immagini di anteprima social
• Grandi grafiche hero

Poi confronta tre cose:

1. Il PNG originale come caricato
2. Un PNG ottimizzato
3. Una versione WebP lossless

Per i workflow da riga di comando, i team usano spesso strumenti come oxipng, pngcrush, zopflipng o cwebp -lossless. Lo strumento esatto conta meno della disciplina di confrontare elementi comparabili.

Tieni traccia di:

• Dimensione del file
• Uguaglianza dei pixel dopo la decodifica
• Rendering visivo nei browser target
• Correttezza della trasparenza
• Aspetto del colore
• Tempo di build
• Attriti nel workflow CMS o di design

Un semplice foglio di calcolo è sufficiente. Aggiungi la dimensione del file originale, la dimensione del PNG ottimizzato, la dimensione del WebP lossless, la percentuale risparmiata e la pagina in cui appare l’immagine.

Poi ordina per byte totali risparmiati. Quell’ordinamento di solito ti dirà che cosa fare.

Distribuzione: non rompere i client più vecchi con leggerezza

Il supporto WebP è ormai ampio nei browser moderni. Per la maggior parte dei siti pubblici, è sicuro usarlo. Tuttavia, se nel mix hai webview incorporate, client email, browser enterprise legacy, app native o crawler insoliti, fai test prima di sostituire direttamente PNG.

Il pattern conservativo è mantenere PNG come fallback e servire WebP dove supportato:

<picture>
  <source srcset="diagram.webp" type="image/webp">
  <img src="diagram.png" alt="Diagram showing the checkout flow">
</picture>

Questo approccio è noioso, e noioso è bene. Gli utenti con supporto WebP ricevono il file più piccolo. Tutti gli altri ricevono il PNG.

Se il tuo sistema di build applica fingerprint agli asset e la tua CDN li mette in cache correttamente, non è difficile da mantenere. Se il tuo CMS rende dolorosi i formati alternativi, inizia dalle immagini più grandi e più ripetute invece di provare a convertire tutta la libreria media in uno sprint.

Privacy ed elaborazione locale

La conversione delle immagini spesso avviene in pipeline di build o servizi media server-side. Per molti team va bene. Ma se gestisci screenshot sensibili, upload dei clienti o documenti interni, presta attenzione a dove vengono elaborati i file.

Gli strumenti immagine lato browser sono diventati abbastanza buoni per molte conversioni semplici, anteprime e controlli dei metadati. Ci sono limiti, ma l’elaborazione locale può ridurre upload non necessari di immagini private. Abbiamo trattato i compromessi in perché elaborare le immagini nel browser è un vantaggio per la privacy.

Per gli asset interni, il punto principale è la chiarezza delle policy. Devi sapere se le immagini lasciano il dispositivo, dove vengono archiviate le versioni trasformate e se i metadati vengono preservati.

Una regola pratica

Usa WebP lossless quando tutte e tre queste condizioni sono vere:

• La sorgente è attualmente PNG.
• I pixel esatti o una trasparenza pulita contano.
• WebP lossless fa risparmiare una quantità significativa dopo il confronto con un PNG ottimizzato.

Mantieni PNG quando:

• Il file è minuscolo.
• Il PNG è già ottimizzato a palette e competitivo.
• I vincoli di compatibilità sono insoliti.
• La complessità operativa non vale i byte risparmiati.

Usa WebP o AVIF lossy quando:

• L’immagine è fotografica.
• I pixel esatti non contano.
• Un’impostazione di qualità può ridurre drasticamente la dimensione senza danni visibili.

La migliore strategia per le immagini raramente è un solo formato ovunque. È un piccolo insieme di regole applicate con coerenza.

<!-- tool-cta:start -->

💡 Prova questo: Esegui lo stesso PNG con Image Converter per produrre una versione WebP senza perdita e confronta direttamente le dimensioni dei file.

<!-- tool-cta:end -->

Quindi, che cosa fa davvero risparmiare WebP lossless?

Fa risparmiare byte dove PNG ha esaurito i trucchi di compressione. A volte significa un modesto 10%. A volte significa quasi dimezzare una grande immagine trasparente. Su un sito reale, i risparmi sono di solito concentrati in una minoranza di asset.

Questa è la parte importante. WebP lossless non è un miglioramento morale rispetto a PNG. È un’opzione pratica per un compito specifico: immagini web lossless più piccole, con trasparenza e ampio supporto nei browser moderni.

Usalo dove i numeri lo giustificano. Lascia stare PNG dove non lo fanno.