Guida pratica alle dimensioni e ai formati dei file immagine per il web

Ogni immagine compete per risorse di rete, decodifica, memoria e rendering. Un budget utile è specifico per pagina: considera il ruolo dell’immagine, il pubblico, la cache, il viewport e la qualità richiesta. Gli intervalli seguenti sono punti di partenza da provare, non limiti universali da superare.

Budget iniziali per caso d’uso

Questi intervalli illustrano un budget contenuto per la distribuzione web. I risultati JPEG, WebP o AVIF possono essere superiori o inferiori; adattali in base a sorgente, encoder, dimensione renderizzata, prestazioni sul campo e controllo visivo.

Trasformare gli intervalli iniziali nel proprio budget

Il rapporto sul peso delle pagine di HTTP Archive fornisce dati di distribuzione aggiornati, ma una mediana globale non rappresenta il tuo pubblico. La soglia LCP “buona” pubblicata da Google è 2,5 secondi al 75º percentile delle visite. Usa dati sul campo e una cascata per suddividere il tempo tra risposta del server, scoperta della risorsa, trasferimento, decodifica e ritardo di rendering.

Parti da un budget di trasferimento per la pagina e assegnane di più alle immagini che offrono maggiore valore all’utente. Rivaluta gli intervalli della tabella quando cambiano layout, numero di immagini, pubblico o qualità richiesta.

Il formato è una variabile importante

La stessa sorgente può produrre dimensioni molto diverse secondo encoder e obiettivo di qualità. Questa tabella mostra comportamenti da confrontare, non risultati di riferimento universali per una foto da 1200 pixel:

WebP o AVIF possono superare un’uscita JPEG in alcuni confronti, ma nessuna percentuale fissa vale per tutte le sorgenti e gli encoder. Entrambi i formati moderni supportano la trasparenza. Vedi la nostra guida WebP e AVIF.

Puoi creare candidati con JPG in WebP, con Converti in AVIF per i formati di ingresso elencati, oppure con la Conversione batch per i formati mostrati dallo strumento.

Dimensioni in pixel: il moltiplicatore nascosto

Numero di pixel, contenuto, profondità di bit, metadati, formato, encoder e impostazioni incidono sulle dimensioni. Ridurre dimensioni inutili spesso lascia molti meno dati da rappresentare all’encoder.

Un’immagine 4000 × 3000 ha 12 milioni di pixel; 1200 × 900 ne ha 1,08 milioni, il 91% in meno. A parità di canali e precisione, questo riduce molto i dati raster non compressi forniti all’encoder, anche se il risparmio finale in byte dipende ancora da contenuto e impostazioni.

Regola pratica per il responsive: offri candidati vicini alle possibili larghezze e densità renderizzate. Se uno spazio è largo 720 CSS pixel, un candidato da 1440 pixel può essere adatto a un display 2×, ma zoom, ritaglio, cambi di layout e densità superiori possono cambiare la scelta. Lascia che srcset e sizes descrivano le opzioni.

Usa lo strumento Ridimensiona immagine di Vizua per creare un candidato alle dimensioni richieste dal layout. Poi prova il compressore JPEG o PNG appropriato; una sorgente già ottimizzata potrebbe non ridursi.

Qualità di compressione: trovare il punto di equilibrio

Una volta che l'immagine ha le dimensioni giuste e il formato corretto, la qualità di compressione è l'ultima variabile da regolare. Ecco uno scenario pratico che mostra come funzionano insieme le tre leve:

Flusso illustrativo: parti da un master 4000 × 3000 e tienilo fuori dall’insieme distribuito.

1. Ridimensiona a un candidato come 1200 × 900 quando corrisponde allo spazio e alla densità di destinazione
2. Esporta un candidato WebP a una qualità iniziale scelta e controlla il file reale
3. Esporta un candidato AVIF quando lo stack lo supporta, poi confronta dimensione, aspetto e costo di codifica

Scegli il candidato più piccolo che soddisfa il caso d’uso. Il risparmio finale e la differenza visibile dipendono dalle sorgenti e uscite reali, non soltanto dalle dimensioni dell’esempio.

Per raccomandazioni dettagliate sulla qualità per ogni formato, consulta la nostra guida: Come comprimere le immagini senza perdere qualità.

Casi particolari

Pagine prodotto e-commerce

Le foto di prodotto devono restare utili allo zoom supportato dal negozio. Genera candidati responsive da un master protetto, prova i dettagli fini e fissa budget separati per griglia, vista principale e zoom. I requisiti di caricamento dei marketplace possono differire dalla distribuzione del negozio.

Portfolio fotografici

I portfolio possono distribuire anteprime responsive e offrire una vista ad alta risoluzione intenzionale quando opportuno. Ricava dimensioni e budget di byte dal layout e dagli schermi previsti, quindi controlla texture, sfumature e profili colore.

Immagini per la condivisione social (Open Graph)

Le raccomandazioni e i formati accettati per le immagini Open Graph variano tra piattaforme e possono cambiare. Un JPEG o PNG 1200 × 630 è un punto di partenza comune tra piattaforme, ma verifica le indicazioni attuali e l’anteprima della destinazione. I crawler scaricano questi file indipendentemente dal lazy loading della pagina.

Budget totale delle immagini per pagina

Crea un budget di pagina dall’obiettivo prestazionale. Una possibile assegnazione iniziale da provare è:

• 1 immagine hero: ~150 KB
• 3-4 immagini di contenuto: ~100 KB ciascuna, per un totale di ~300-400 KB
• Miniature, avatar, icone: ~50 KB complessivi

Questo esempio non garantisce velocità. Gallerie e griglie possono rimandare immagini appropriate fuori schermo, ma le risorse in lazy loading consumano comunque dati quando richieste e possono influire sullo scorrimento. Misura prestazioni iniziali e di interazione su dispositivi e reti rappresentativi.

Domande frequenti