Immagini e velocità: formati, dimensioni, lazy loading

Perché le immagini decidono il tempo di caricamento

Google scrive che le immagini sono spesso la parte che contribuisce di più al peso complessivo della pagina, il che può rendere le pagine lente e costose da caricare. Due dei Core Web Vitals dipendono direttamente dalle immagini. Il Largest Contentful Paint (LCP) misura il caricamento: Google consiglia che l’elemento più grande compaia entro i primi 2,5 secondi dall’inizio del caricamento della pagina. In molte pagine questo elemento è un’immagine, per esempio una grande foto in cima. Il Cumulative Layout Shift (CLS) misura la stabilità visiva e dovrebbe restare sotto 0,1. Le immagini che arrivano senza spazio riservato spingono giù il testo e fanno salire questo valore.

Il formato giusto

• Foto: il JPEG funziona ovunque. WebP e AVIF sono spesso molto più leggeri a qualità simile.
• Grafiche con bordi netti o trasparenza: PNG, oppure WebP e AVIF, che possono essere anch’essi trasparenti.
• Loghi e icone: SVG, perché resta nitido a ogni dimensione e di solito è molto leggero.
• La Ricerca Google supporta le immagini nell’attributo src nei formati BMP, GIF, JPEG, PNG, WebP, SVG e AVIF.

Se offri WebP o AVIF, puoi tenere un JPEG di riserva in un elemento picture. Il browser sceglie la prima fonte che capisce.

La dimensione giusta

Un’immagine larga 2.400 pixel ma mostrata a 600 pixel spreca la maggior parte dei suoi byte. Esporta le immagini più o meno alla larghezza a cui vengono mostrate, e per gli schermi ad alta risoluzione a circa il doppio di quella larghezza. Poi comprimile. In molti programmi di grafica, un’impostazione di qualità intorno alla metà della scala basta per le foto sul web. Controlla il risultato a grandezza reale prima di sostituire l’originale.

srcset e sizes

Un solo file non va mai bene per tutti gli schermi. Con srcset offri più file della stessa immagine e indichi la larghezza di ciascuno. Con sizes dici al browser quanto sarà larga l’immagine visualizzata. Il browser sceglie allora il file più piccolo che sia abbastanza nitido.

<img src="/img/sofa-800.jpg"
     srcset="/img/sofa-400.jpg 400w, /img/sofa-800.jpg 800w, /img/sofa-1600.jpg 1600w"
     sizes="(max-width: 700px) 100vw, 700px"
     width="800" height="533"
     alt="…">

In questo esempio l’immagine occupa tutta la larghezza sugli schermi stretti ed è larga 700 pixel su quelli più ampi. Google consiglia di tenere sempre una soluzione di riserva nell’attributo src. Scrivi un vero testo alternativo al posto dei tre puntini.

width e height contro gli spostamenti del layout

Senza width e height, il browser non sa quanto spazio serve a un’immagine finché il file non arriva. Il testo sottostante allora salta giù. La guida di web.dev sugli spostamenti del layout consiglia di includere sempre gli attributi width e height su immagini ed elementi video, con le dimensioni in pixel del file o almeno con il giusto rapporto d’aspetto. I browser moderni ricavano da questi valori il rapporto d’aspetto predefinito dell’immagine e riservano lo spazio. Nel CSS, width: 100% e height: auto mantengono l’immagine flessibile. Se non puoi impostare gli attributi, la guida indica come alternativa la proprietà CSS aspect-ratio.

Lazy loading

Con loading="lazy" il browser carica un’immagine solo quando si avvicina all’area visibile. Questo fa risparmiare dati per le immagini più in basso nella pagina. Google dice del lazy loading: non aggiungerlo a contenuti che saranno probabilmente visibili subito quando un utente apre una pagina. Il lazy loading integrato del browser è disponibile per immagini e iframe.

L’immagine LCP

L’immagine più grande in cima, spesso un’immagine hero o la foto principale del prodotto, è il file più importante della pagina. La guida di web.dev sull’LCP dice: non caricare mai in lazy loading la tua immagine LCP. fetchpriority="high" è un suggerimento al browser per caricarla presto. Secondo la guida, una priorità alta su più di una o due immagini non aiuta più. Le immagini il cui indirizzo una libreria di script nasconde in data-src, o che sono solo uno sfondo CSS, vengono trovate tardi dal browser. Per un’immagine di sfondo, la guida indica un precaricamento con link rel="preload" nell’HTML. Anche AVIF o WebP e un file più piccolo riducono il tempo di caricamento.

Per vedere le prestazioni delle tue pagine, Google rimanda al rapporto Core Web Vitals in Search Console. Per una singola pagina, gli strumenti per le prestazioni del tuo browser mostrano quale elemento è l’elemento LCP e quali elementi spostano il layout. Misura prima e dopo una modifica, così sai se è servita.

Una breve checklist

• L’immagine più grande in cima viene caricata normalmente, non in lazy loading?
• Ogni img ha width e height, oppure lo spazio riservato con aspect-ratio?
• Ogni file è largo più o meno quanto viene mostrato, ed è compresso?
• Le foto grandi sono disponibili in più larghezze con srcset e sizes?
• Ci sono file JPEG o PNG che potrebbero essere WebP o AVIF?

Lavorare con Do4U

Il Controllo immagini legge una pagina e ogni immagine che contiene. Per ogni file indica formato, peso e pixel, e dall’HTML width e height, loading, fetchpriority, srcset e sizes, le fonti picture e le immagini di sfondo negli attributi style. Do4U stima dall’HTML la probabile immagine LCP. Non la misura, perché il vero elemento LCP lo decide il browser. Ricevi una tabella delle immagini con i risultati, il peso totale e un breve riepilogo. Le immagini inserite da JavaScript e le immagini di sfondo da file CSS esterni non sono incluse. Non si usa l’AI, e il controllo è gratuito, con un limite giornaliero.

Do4U trova indicazioni, tu controlli e decidi. Conferma l’elemento LCP con gli strumenti per le prestazioni del tuo browser prima di modificare la pagina.