Come comprimere immagini per un sito web senza rovinare la qualità

La risposta pratica

Per comprimere le immagini di un sito senza rovinare la qualità, non partire trascinando il cursore della qualità sul numero più basso che ancora ti convince. Parti dal ruolo reale dell’immagine nella pagina. Un hero, una foto prodotto da zoomare, un’illustrazione da blog, un avatar, uno screenshot e una texture di sfondo hanno bisogno di dimensioni, formati e qualità diverse.

La regola utile è: ridimensiona prima alla dimensione più grande in cui l’immagine viene effettivamente mostrata, poi comprimi quanto basta perché resti identica nel layout. Se un’immagine di blog viene visualizzata a 760 pixel CSS di larghezza, una sorgente di 1500–1600 px è di solito sufficiente per gli schermi ad alta densità. Un originale da fotocamera di 5000 px è dato sprecato. Un export a 760 px può apparire morbido sui display retina. Il file giusto sta tra questi due estremi.

Anche «senza perdere qualità» ha bisogno di una definizione semplice. Nel lavoro web di solito significa nessuna perdita visibile alla dimensione in cui i visitatori vedono davvero l’immagine, non perfezione matematica pixel per pixel. Un WebP compresso non è identico all’originale, ma nella pagina può risultare visivamente indistinguibile.

Prima capisci di che tipo di immagine si tratta

Prima di scegliere WebP, AVIF, JPEG, PNG o un valore di qualità, classifica il file:

Questa tabella è volutamente tranchant. Gran parte delle compressioni web fatte male nasce dal trattare tutti i file allo stesso modo. Un hero di homepage può incidere sul Largest Contentful Paint. Un’immagine di dettaglio prodotto può incidere su fiducia e conversione. Uno sfondo decorativo può essere molto più leggero, perché nessuno lo studia.

Prima ridimensionare: le dimensioni fanno il grosso del lavoro

La compressione riduce il numero di byte usati per memorizzare una griglia di pixel fissa. Il ridimensionamento cambia la griglia stessa. Se la sorgente ha molti più pixel di quelli che la pagina può mostrare, ridimensionare è la vittoria più pulita.

Formula semplice per il dimensionamento:

larghezza sorgente obiettivo = massima larghezza CSS mostrata × device pixel ratio

Per esempio:

• Un’immagine card mostrata a 320 CSS px dovrebbe avere una sorgente di 640 px per schermi 2x.
• Un’immagine di blog mostrata a 760 CSS px dovrebbe avere una sorgente di 1500–1600 px.
• Un hero a piena larghezza attorno ai 1200 CSS px può richiedere una sorgente di 2000–2400 px, in base al taglio e ai dispositivi del pubblico.

Non usare ciecamente il 3x per ogni immagine. web.dev ricorda che DPR e layout contano insieme, e che in molti casi gli utenti non percepiscono il beneficio di sorgenti a DPR molto alto. Un hero da 2400 px può avere senso. Un hero da 5000 px «tanto più pixel è più sicuro» in genere brucia solo banda.

PhotoTools separa questi due compiti. Usa Resize quando ti servono pixel esatti o un lato lungo più piccolo. Poi con Compress scegli JPEG, WebP o AVIF e regoli la qualità.

Scegli il formato prima di toccare la qualità

Il formato decide che tipo di dettaglio si può togliere in modo pulito.

• Usa WebP per la maggior parte delle foto web. Ha ampio supporto nei browser moderni ed è di solito più piccolo di JPEG a parità di qualità percepita. La documentazione WebP di Google riporta risparmi del 25–34 % rispetto a JPEG equivalenti.
• Usa AVIF dove ogni byte conta. AVIF può battere WebP su file fotografici grandi, ma è più lento in codifica e aggiunge complessità alla pipeline. Servilo con dei fallback, non come unico file.
• Usa JPEG come fallback di compatibilità. Rimane utile per e-mail, flussi CMS datati, download e come sorgente di fallback in <img>.
• Usa PNG o WebP lossless per screenshot e testo. JPEG/WebP lossy possono sfrangiare i piccoli testi di UI e generare rumore di colore attorno ai bordi netti.
• Usa SVG per loghi e icone. Un logo raster in WebP può essere più leggero del PNG, ma un SVG pulito è di solito più nitido e più leggero.

Se usi <picture>, metti prima il formato più efficiente e mantieni un fallback compatibile nell’img annidato:

<picture>
  <source
    type="image/avif"
    srcset="/images/hero-1200.avif 1200w, /images/hero-2000.avif 2000w"
    sizes="100vw"
  />
  <source
    type="image/webp"
    srcset="/images/hero-1200.webp 1200w, /images/hero-2000.webp 2000w"
    sizes="100vw"
  />
  <img
    src="/images/hero-1200.jpg"
    width="1200"
    height="800"
    alt="Cucina ristrutturata con mobili in noce e luce naturale"
  />
</picture>

L’elemento img continua a essere importante. Porta con sé la sorgente di fallback, alt, width e height. Non nascondere informazioni di accessibilità o di layout dentro gli elementi source.

Impostazioni di qualità utili nella pratica

I numeri di qualità non sono standardizzati. La qualità JPEG 80 di un encoder non corrisponde per forza alla qualità 80 di un altro. Anche WebP 80, JPEG 80 e AVIF 50 non sono equivalenti. Considera la qualità un punto di partenza, poi ispeziona il file esportato.

Una trappola comune è esportare tutto a qualità 95 o 100 perché «così stai più tranquillo». Nella maggior parte delle foto web, i byte in più si vedono nel waterfall di rete, non nella pagina. Un’altra trappola è forzare la qualità sotto 50 pur di rispettare un target arbitrario. Se la qualità deve scendere così tanto, meglio ridimensionare o cambiare formato prima di degradarla ancora.

Obiettivi di peso per ruolo di pagina

Non sono regole di Google né soglie magiche di ranking. Sono obiettivi pratici di revisione che aiutano a intercettare le immagini palesemente troppo pesanti.

Se un’immagine di blog da 760 px pesa 900 KB, probabilmente va ricontrollata. Se un’immagine portfolio a piena larghezza pesa 410 KB ed è splendida, ridurla a 90 KB potrebbe essere l’obiettivo sbagliato.

Comprimere immagini hero e LCP

L’immagine per cui vale di più ottimizzare è spesso la più grande above-the-fold. Nel linguaggio dei Core Web Vitals è di frequente l’immagine del Largest Contentful Paint. Comprimerla aiuta, ma solo se viene anche scoperta e caricata presto.

Per un hero:

1. Ritaglialo al rapporto reale usato nella pagina.
2. Esporta larghezze responsive, per esempio 1200 px e 2000 px.
3. Usa AVIF per primo e WebP/JPEG come fallback, se lo stack lo consente.
4. Non applicare lazy-load all’hero né a un altro candidato LCP above-the-fold.
5. Aggiungi width e height così il browser può riservare lo spazio.
6. Usa fetchpriority="high" solo sull’unica immagine che sarà con più probabilità l’elemento LCP.

Esempio di img di fallback:

<img
  src="/images/hero-1200.jpg"
  srcset="/images/hero-1200.jpg 1200w, /images/hero-2000.jpg 2000w"
  sizes="100vw"
  width="1200"
  height="800"
  fetchpriority="high"
  alt="Cucina ristrutturata con mobili in noce e luce naturale"
/>

Non mettere fetchpriority="high" su un’intera gallery. Gli hint di priorità sono strumenti affilati: usane uno per l’immagine che deve davvero arrivare per prima.

Come confrontare i risultati della compressione

Il confronto giusto non è file originale contro file compresso al 100 % di zoom. È così che ci si autoconvince a pubblicare immagini sovradimensionate. Confronta alla dimensione e nel contesto in cui i visitatori vedono l’immagine.

Fai questo passaggio di revisione:

1. Metti l’immagine compressa nella pagina reale o in un layout di test della stessa larghezza.
2. Osservala a larghezza desktop e mobile.
3. Guarda le zone a rischio: volti, pelle, cielo, sfumature, tessuti, etichette di prodotto, piccoli testi e bordi ad alto contrasto.
4. Alterna originale e compressa alla dimensione renderizzata.
5. Zoom breve al 100 % solo per intercettare artefatti evidenti, non per pretendere una perfezione che nessuno vedrà.

Gli artefatti di compressione hanno una loro personalità. JPEG mostra spesso bordi a blocchi, ringing o rumore di colore. Un WebP troppo compresso può impastare le texture. AVIF, spinto troppo, può produrre banding o un aspetto plasticoso. Gli screenshot in PNG di solito falliscono nella direzione opposta: sembrano perfetti ma pesano molto più del necessario.

Un flusso PhotoTools per le immagini del sito

PhotoTools è utile prima che l’immagine arrivi al tuo CMS, al tuo CDN o al repository. Non sostituisce una pipeline di build completa, ma offre un flusso manuale pulito per piccoli siti, articoli di blog, preview per il cliente e file una tantum.

1. Lascia intatto il file sorgente originale.
2. Decidi il ruolo dell’immagine: hero, immagine di contenuto, foto prodotto, screenshot, miniatura o sfondo.
3. Usa Resize per prima cosa quando l’originale è molto più grande della dimensione di visualizzazione.
4. Apri Compress, scegli JPEG, WebP o AVIF e parti da qualità 80 per WebP/JPEG.
5. Clicca «Compress all» e leggi per ogni card la dimensione originale, la dimensione in uscita e la percentuale risparmiata.
6. Scarica il risultato e ispezionalo nel contesto della pagina.
7. Se non convince a vista, torna all’originale o alla copia ridimensionata ed esporta di nuovo a qualità più alta.
8. Se è ancora troppo pesante, riduci prima le dimensioni, poi eventualmente abbassa la qualità nel territorio degli artefatti.

Non ricomprimere in continuazione il download già compresso — accumuli artefatti lossy. Torna al master o all’intermedio ridimensionato pulito.

Metadati e privacy

I file da fotocamera contengono spesso metadati EXIF: coordinate GPS, data di scatto, modello di fotocamera, ottica, software di editing. Questi metadati non aiutano il visitatore a vedere l’immagine. Possono anche esporre informazioni private.

PhotoTools comprime le immagini decodificando il file, disegnando i pixel su un canvas del browser e riesportando un nuovo file. MDN documenta che OffscreenCanvas.convertToBlob() può indicare tipo di immagine e qualità per i formati che supportano la compressione con perdita. Poiché l’output è generato dai pixel del canvas, i metadati della fotocamera di solito non vengono copiati nel nuovo file.

Per foto sensibili, verifica il download finale con un lettore di metadati prima di pubblicarlo. La privacy non è solo peso del file.

Errori comuni che fanno apparire brutte le immagini

• Comprimere prima di ridimensionare: stai cercando di risparmiare byte su pixel che il layout non mostrerà mai.
• Usare PNG per foto: con immagini da fotocamera il PNG è di solito enorme.
• Usare JPEG per screenshot con testo: il file può essere più piccolo, ma il testo si sfoca.
• Giudicare alla dimensione sbagliata: lo zoom alla risoluzione piena fa sembrare drammatici artefatti innocui.
• Un unico hero enorme per tutti i dispositivi: i visitatori mobile scaricano pixel desktop che non useranno.
• Lazy-load sull’hero: le immagini sotto la piega possono essere in lazy-load. Quella LCP no.
• Niente width né height: la pagina può saltare mentre le immagini caricano.
• Ricomprimere il file già pubblicato: parti dal sorgente quando possibile.

Una checklist di pubblicazione compatta

Prima di caricare un’immagine di sito, passa per questi punti:

1. È il formato giusto per il tipo di contenuto?
2. La larghezza sorgente è basata sulla vera larghezza di visualizzazione e su un DPR plausibile?
3. Serve un candidato mobile più piccolo se il taglio dell’hero cambia su mobile?
4. La qualità è abbastanza alta per volti, etichette, sfumature e dettaglio prodotto?
5. Il peso è ragionevole per il suo ruolo?
6. La pagina include width, height, un alt utile e srcset/sizes responsive dove serve?
7. L’immagine LCP è caricata in eager e prioritizzata, mentre quelle sotto la piega vanno in lazy-load?
8. Hai controllato l’immagine esportata nel layout reale?
9. Hai conservato il file sorgente?

Il miglior flusso di compressione è noioso nel modo giusto: scegli i pixel giusti, scegli il formato giusto, esporta a qualità sensata, ispeziona la pagina reale e fermati prima che l’immagine cominci a sembrare «lavorata».

Fonti tecniche consultate

Questo articolo è stato rivisto rispetto all’attuale implementazione di compressione e ridimensionamento di PhotoTools, alla guida di web.dev sulla performance delle immagini, all’insight «Improve image delivery» di Chrome, alla scheda «Properly size images» di Chrome, alla documentazione MDN su OffscreenCanvas.convertToBlob(), alla guida MDN sui tipi di file immagine e alla documentazione WebP di Google.