Come ridimensionare immagini per il web: Dimensioni, Retina e srcset

Ultimo aggiornamento: June 28, 2026

Ho ridimensionato la stessa foto ero quattro modi e ho misurato la differenza: un JPEG da fotocamera di 4.2MB, servito così com'è in uno slot di visualizzazione da 800px, è diventato un WebP da 94KB senza perdita visibile di qualità. Ridimensionare le immagini per il web è il singolo miglioramento di peso pagina più grande disponibile, e la maggior parte dipende da quattro decisioni: dimensione di visualizzazione, fattore retina, formato e compressione. Questo è il flusso di lavoro che eseguo su ogni sito che pubblico.

Risposta rapida: come dovresti ridimensionare le immagini per il web?

Ridimensiona ogni immagine a circa il doppio della larghezza con cui viene visualizzata (il fattore retina), esportala come WebP, comprimi a qualità 80 e pubblica una breve scala srcset in modo che telefoni e laptop ricevano rispettivamente un file adatto. Per un hero full-width che si visualizza a 1920px, è di solito sufficiente un singolo WebP da 1920 a 2560px a qualità 80. Saltare questo passaggio costringe ogni dispositivo a scaricare pixel con risoluzione desktop.

Quali dimensioni dovrebbe avere effettivamente un'immagine web?

La dimensione corretta è la dimensione di visualizzazione, non la dimensione sorgente. Apri DevTools, ispeziona l'immagine, leggi la larghezza massima della box CSS che occupa in tutti i breakpoint e poi esporta a quella larghezza moltiplicata per il tuo target di densità.

Per la maggior parte delle immagini di articoli e prodotti che si trovano in un intervallo prevedibile. Misuro ogni slot prima di esportare, perché indovinare è come una foto da 4000px finisce in una colonna da 600px.

Non lasciare che CSS faccia il downscaling. Un <img> stilizzato su width: 400px scarica comunque l'intero file — il browser scarta i pixel extra dopo che i byte sono già sul cavo. Ridimensiona la sorgente prima, poi fidati di CSS solo per il layout.

Passo dopo passo: il mio flusso di lavoro di ridimensionamento

Questa è l'esatta sequenza che eseguo. L'ho testata contro un audit delle immagini Lighthouse e supera costantemente il controllo "immagini correttamente dimensionate".

• Misura la larghezza renderizzata massima con DevTools.
• Moltiplica per 2 per il retina (3x solo per scatti hero di telefono densi).
• Ridimensiona con un filtro ad alta qualità (Lanczos).
• Esporta come WebP a qualità 80, scendi a 75 se il file è ancora pesante.
• Genera una scala srcset per gli slot responsive.
• Comprimi di nuovo se il file supera ancora i 200KB.

from PIL import Image

def resize_for_web(src, out, max_width=1440, quality=80):
    img = Image.open(src)
    if img.width > max_width:
        ratio = max_width / img.width
        img = img.resize((max_width, int(img.height * ratio)),
                         Image.LANCZOS)
    img.save(out, "WEBP", quality=quality)

Quando l'ho misurato, questo ha trasformato una foto da 4000x2667 (JPEG da 4.2MB) in un WebP da 1440x960 di 94KB — una riduzione del 98% senza perdita visibile di nitidezza su uno schermo standard. Le regole più approfondite per mantenere i dettagli durante il downscaling aggressivo sono in keep quality while resizing.

Retina e 2x: hai davvero bisogno del doppio dei pixel?

Per lo più sì, per qualsiasi cosa gli utenti guardino da vicino. Uno schermo 2x contiene quattro volte i pixel nello stesso spazio fisico, quindi un file 1x appare sfocato. La regola sicura: esporta al 2x della larghezza CSS per le immagini di contenuto.

Dove rompo deliberatamente questa regola:

• Sfondi decorativi che sfuocano o sbiadiscono possono rimanere vicino a 1x.
• Immagini sotto il fold dove la nitidezza è meno critica possono usare 1.5x.
• Icone e loghi sono migliori come SVG, che è indipendente dalla risoluzione.

La web.dev image guidance di Google raccomanda descrittori di densità o descrittori di larghezza; i descrittori di larghezza tramite srcset sono più facili da gestire, quindi questo è quello che uso per impostazione predefinita.

Servire varianti responsive con srcset

Un file per immagine è raramente corretto per ogni dispositivo. Uno smartphone non ha bisogno di un file da 1440px e un monitor 4K non dovrebbe accontentarsi di uno da 480px. srcset ti permette di offrire diverse larghezze e lasciare che il browser scelga.

<img
  src="hero-960.webp"
  srcset="hero-480.webp 480w, hero-720.webp 720w,
          hero-960.webp 960w, hero-1440.webp 1440w"
  sizes="(min-width: 900px) 720px, 92vw"
  alt="Illustrazione eroica di uno skyline cittadino al crepuscolo"
  width="960" height="640" loading="lazy">

L'attributo sizes deve dire la verità sullo slot renderizzato. Se lo lasci al valore predefinito 100vw, il browser assume che l'immagine copra l'intero viewport e scarica la variante più grande. Scegliere quali larghezze generare è una decisione a sé stante — il metodo che uso per accorciare la scala si trova in responsive image breakpoints.

Dimensione file vs dimensioni: cosa è più importante?

Entrambi sono importanti, ma per motivi diversi. Le dimensioni decidono il conteggio dei pixel; la compressione e il formato decidono i byte per pixel. Un'immagine con le dimensioni corrette ma una cattiva compressione è comunque pesante, e un'immagine minuscola ma troppo compressa sembra rotta.

L'obiettivo che mi prefiggo è inferiore a 200KB per la maggior parte delle immagini di contenuto e inferiore a 100KB per qualsiasi cosa sopra il fold che alimenta Largest Contentful Paint. Quando un file supera questo limite, la prima leva che tiro è la qualità di compressione, poi il formato. Il dettaglio byte-level su come la compressione riduce il peso si trova in compress without losing quality.

Lighthouse segnala le immagini sovradimensionate come un'opportunità concreta. Eseguilo da Chrome DevTools o segui la documentazione Lighthouse — l'audit "immagini correttamente dimensionate" riporta esattamente quanti KB sprechi servendo più pixel di quelli necessari allo slot.

Scegliere il formato giusto

Il formato è dove si nascondono molti byte. Di default uso WebP per quasi tutto fotografico, con AVIF dove posso permettermi un fallback. Abbinare il formato al contenuto è importante quanto le dimensioni: un PNG usato per una foto è più pesante dello stesso file come WebP senza beneficio.

La MDN responsive images guide copre l'elemento <picture> per servire AVIF con un fallback WebP o JPEG. Mi rivolgo a <picture> solo quando ho bisogno di negoziazione del formato; per foto responsive semplici, srcset da solo è sufficiente.

Errori che vedo quando eseguo audit sui siti

Quando esamino un sito lento, i problemi relativi alle immagini si ripetono. Questi sono quelli che risolvo più spesso.

• Caricare file con risoluzione fotocamera e ridimensionarli con CSS.
• Un unico file per ogni breakpoint invece di una scala srcset.
• Dimenticare width e height, il che causa layout shift.
• Lasciare sizes al valore predefinito in modo che il browser prenda il file più grande.
• Caricare tutte le immagini con avidità (eagerly) invece di ritardare quelle sotto il fold.

L'ultimo punto è un guadagno prestazionale gratuito. Il modello per ritardare le immagini fuori schermo è coperto in lazy loading images — aggiungi loading="lazy" e il browser salta le immagini che l'utente non ha ancora fatto scorrere.

Riepilogo

Prima di pubblicare un'immagine, passo attraverso questa lista: ridimensionata al 2x della larghezza di visualizzazione massima, esportata come WebP, compressa sotto i 200KB, con una scala srcset, un attributo sizes veritiero, larghezza e altezza esplicite, loading="lazy" sotto il fold e testo alt descrittivo.

Un vero avvertimento: ridimensionare è la leva più grande, ma non è tutto il lavoro. Ho visto team che padroneggiano le dimensioni e comunque pubblicano pagine lente perché servivano file dall'origine senza caching, senza CDN e senza nome di file con hash di contenuto. Misura con Lighthouse e profili di dispositivi reali, quindi fidati dei numeri più della checklist. Un WebP da 94KB che il browser scarica di nuovo ad ogni navigazione è comunque un errore da 94KB.

Domande frequenti

Quali dimensioni dovrebbe avere un'immagine ero web?

Associa la dimensione di visualizzazione: circa 1600px di larghezza per un hero full-width, 800–1200px per un'immagine colonna contenuto. Esportare al 2x della dimensione di visualizzazione (per il retina) raddoppia i pixel; servire la giusta dimensione per dispositivo con srcset piuttosto che pubblicare un unico file enorme.

Ho bisogno di immagini 2x per gli schermi retina?

Per grafiche nitide e foto ero, sì — gli schermi retina mostrano altrimenti morbidezza. Per le immagini sotto il fold e decorative, spesso è sufficiente un singolo file 1x. Usa srcset per servire varianti 1x e 2x in modo che i dispositivi non-retina non scarichino il file grande.

Cosa è più importante, dimensioni o dimensione del file?

Entrambi, ma la dimensione del file sposta di più Core Web Vitals. Ridimensiona prima alle dimensioni di visualizzazione (elimini pixel sprecati), quindi comprimi a una qualità target (elimina byte sprecati). La web speed guide copre l'intero ordine.

Come servo varianti responsive?

Usa srcset con sorgenti specifiche per dimensione e un attributo sizes che descrive la larghezza di visualizzazione, lasciando al browser scegliere il file giusto per viewport. Genera ogni dimensione dal master, poi lascia che il browser scelga. Vedi responsive images guide.

Cos'è srcset?

Un attributo HTML che elenca più sorgenti immagine a diverse dimensioni, permettendo al browser di scegliere quella giusta in base al viewport. Serve un file piccolo per uno schermo piccolo e un file grande per uno schermo grande, risparmiando byte. Vedi responsive images guide.

Cos'è l'attributo sizes?

Un attributo HTML che dice al browser quanto è larga l'immagine in diversi breakpoint di visualizzazione, in modo che il browser possa scegliere la sorgente srcset giusta prima di scaricare. Senza sizes, il browser indovina. Abbina srcset (le sorgenti) con sizes (le larghezze di visualizzazione) per immagini responsive che scaricano efficientemente. Vedi responsive images guide.

Crediti delle immagini

• Un MacBook su una scrivania che mostra un layout web progettato — foto di Tranmautritam su Pexels
• Primo piano di un monitor del computer che mostra righe di codice sorgente — foto di Nemuel Sereti su Pexels
• Uno schermo laptop che mostra un sito web caricato in una scheda browser — foto di cottonbro studio su Pexels