Come le Immagini e i Media Causano il Layout Shift (e Come Risolverlo)

Come le Immagini e i Media Causano il Layout Shift (e Come Risolverlo)

Il Web Almanac 2025 quantifica ciò che continuo a vedere sul campo: il 62% delle pagine mobile ha almeno un'immagine senza larghezza e altezza esplicite. Questo rende i media non dimensionati la causa numero uno del Cumulative Layout Shift sul web. E ognuno di questi shift è prevenibile con tecniche che esistono dal 2019.

Ultima revisione a cura di Arjen Karel a Marzo 2026

Il browser non sa quanto sia grande la tua immagine

Ogni layout shift dovuto a un'immagine si riduce a una cosa. Il browser non sa quanto spazio riservare prima che l'immagine venga caricata.

Quando il browser incontra un tag <img> senza dimensioni, esegue il render dell'immagine a 0x0 pixel. Il file arriva, il browser ricalcola il layout e tutto ciò che si trova sotto l'immagine salta verso il basso. Quel salto è il tuo CLS.

Come width e height prevengono il layout shift

Nel 2019 e nel 2020 tutti i principali browser hanno rilasciato una funzionalità che ha cambiato il funzionamento degli attributi width e height. I browser ora li usano per calcolare un aspect ratio prima che l'immagine venga scaricata.

Quando scrivi questo:

<img src="hero.jpg" width="800" height="450" alt="Description">

Il browser genera internamente questo:

img[Attributes Style] {
    aspect-ratio: auto 800 / 450;
}

Nessun dato dell'immagine è necessario. Il browser conosce le proporzioni e riserva lo spazio verticale.

Questo rapporto interno ha la priorità CSS più bassa, quindi qualsiasi regola CSS che scrivi lo sovrascrive. Questo è importante perché è il motivo per cui width: auto rompe tutto (ne parleremo tra un attimo).

La parola chiave auto dice al browser: usa questo rapporto come placeholder, ma una volta che l'immagine effettiva si carica, passa alle dimensioni reali. Se imposti accidentalmente valori errati (ad esempio width="4" height="3" su un'immagine 16:9), il browser riserva inizialmente uno spazio 4:3, per poi correggersi a 16:9 quando l'immagine viene caricata. Quella correzione è un layout shift. Usa sempre le dimensioni in pixel reali.

Per le immagini responsive, aggiungi questo CSS:

<style>
img {
    height: auto;
    max-width: 100%;
}
</style>

height: auto calcola l'altezza a partire dal rapporto. max-width: 100% impedisce all'immagine di superare il suo contenitore. Il browser conosce la larghezza e il rapporto. Questo è sufficiente.

Perché width:auto distrugge il tuo CLS

Questo è quello che vedo più spesso e quello che fa sprecare più tempo di debugging. Lo sviluppatore imposta width e height su ogni immagine, fa tutto bene in HTML, esegue Lighthouse, ottiene un punteggio verde, lo pubblica. Poi arrivano le lamentele sul CLS da parte degli utenti reali.

La causa è sempre da qualche parte nel CSS. Una singola regola globale annulla tutto:

<style>
img {
    width: auto;
    height: auto;
    max-width: 100%;
}
</style>

Il problema è width: auto. Poiché il rapporto interno del browser ha la priorità CSS più bassa, qualsiasi regola lo sovrascrive. width: auto rimuove la larghezza che il browser stava usando per calcolare l'altezza. Entrambe le dimensioni diventano sconosciute. L'immagine viene renderizzata a 0x0 finché il file non viene scaricato, per poi scattare a grandezza naturale.

Impostare aspect-ratio nel CSS non risolve il problema. Con width: auto, il browser tratta la larghezza come 0 prima che l'immagine venga caricata. Un aspect ratio calcolato da 0 produce comunque 0. Zero moltiplicato per qualsiasi cosa fa zero.

Ecco la parte che rende questo errore così difficile da individuare: causa uno shift solo per i visitatori al primo accesso. Se l'immagine è nella cache del browser, le dimensioni effettive sono disponibili immediatamente e non si verifica alcuno shift. Tu, come sviluppatore, non lo vedrai mai sulla tua macchina. I tuoi tester non lo vedranno. Il tuo team di QA non lo vedrà. Solo i tuoi utenti reali alla loro prima visita lo vedono, che è esattamente la visita che Google misura per CrUX.

Ho passato ore in chiamate con team di ingegneri che giuravano che il loro CLS fosse stato risolto perché non riuscivano a riprodurlo localmente. Era sempre questo. Controlla il tuo CSS. Se hai un width: auto globale sulle immagini, quello è il tuo problema.

La soluzione:

<style>
img {
    height: auto;
    max-width: 100%;
}
</style>

Rimuovi width: auto. Mantieni height: auto e max-width: 100%. Questo è il pattern raccomandato da web.dev.

Controllo rapido: fai clic con il tasto destro su qualsiasi immagine del tuo sito, scegli "Ispeziona elemento" e guarda gli stili calcolati. Se vedi width: auto, ora sai cosa fare. Per la guida completa, consulta risolvere il layout shift causato dal dimensionamento automatico delle immagini.

Quando aspect-ratio CSS è la scelta migliore

Gli attributi width/height sono l'approccio predefinito. Ma a volte si desidera che il CSS imponga un rapporto specifico indipendentemente dal contenuto dell'immagine. Un banner hero che deve essere sempre 16:9, o una griglia di schede prodotto in cui ogni immagine ha bisogno della stessa forma:

<style>
img {
    aspect-ratio: 16 / 9;
    width: 100%;
}
</style>

Funziona in tutti i browser moderni (Chrome 88+, Firefox 87+, Safari 15+) e su qualsiasi elemento, non solo immagini e video.

Per le normali immagini di contenuto, gli attributi width/height sono migliori. Descrivono le dimensioni reali e si autocorreggono quando l'immagine viene caricata.

Puoi combinare entrambi:

<style>
img {
    aspect-ratio: auto 16 / 9;
    width: 100%;
}
</style>

La parola chiave auto in questo caso significa: usa 16/9 prima che l'immagine venga caricata, passa al rapporto naturale dopo. Prenotazione dello spazio prima del caricamento, dimensionamento accurato in seguito.

I video hanno lo stesso problema

Un video senza width e height viene renderizzato a 0x0 finché il browser non scarica abbastanza del file per leggerne i metadati. Su una connessione lenta, questo richiede secondi. La soluzione è identica a quella delle immagini:

<video src="demo.mp4" width="1280" height="720" autoplay muted loop></video>

I browser calcolano un aspect-ratio: auto 1280 / 720 interno dagli attributi. Aggiungi height: auto; max-width: 100%; in CSS e il gioco è fatto.

Una cosa a cui prestare attenzione: l'immagine poster. Se imposti un poster ma non imposti le dimensioni sull'elemento video, l'elemento si adatta alle dimensioni del poster. Quando il video inizia la riproduzione e ha una risoluzione diversa, ottieni uno shift. Imposta larghezza e altezza in modo che corrispondano alla risoluzione del video, non al poster.

Gli iframe hanno come impostazione predefinita 300x150 pixel

Un iframe senza dimensioni esplicite ha come impostazione predefinita 300x150 pixel. Per la maggior parte degli elementi incorporati (YouTube, Google Maps, post sui social media) questo è sbagliato. Nel momento in cui l'elemento incorporato si carica e si ridimensiona, tutto ciò che lo circonda subisce uno shift.

A differenza delle immagini, gli iframe non calcolano automaticamente un aspect ratio dai loro attributi. Devi impostare tu stesso il dimensionamento:

<style>
.responsive-iframe {
    width: 100%;
    height: auto;
    aspect-ratio: 16 / 9;
}
</style>

Questo sostituisce il vecchio hack del padding-top in cui si avvolgeva l'iframe in un contenitore con padding-top: 56.25% e lo si posizionava in modo assoluto. Il vecchio hack funziona ancora. aspect-ratio è più pulito e non ha bisogno di alcun contenitore aggiuntivo (wrapper).

Oppure non caricare affatto l'iframe

Per YouTube, Vimeo, Google Maps e gli embed social ho smesso di caricare gli iframe al caricamento della pagina anni fa. Il facade pattern è migliore in ogni aspetto: mostra un'immagine placeholder statica con l'aspect ratio corretto. Quando l'utente fa clic, JavaScript la scambia con l'iframe reale. Zero iframe, zero CLS, zero risorse sprecate.

Lo shift dovuto allo scambio avviene entro 500 ms dall'input dell'utente ed è escluso dal CLS by design.

Per esempi di implementazione, vedi embed perfetti di YouTube e Google Maps senza perdere in PageSpeed.

Art direction: quando i ritagli per mobile e desktop hanno proporzioni diverse

Si parla di art direction quando servi ritagli (crop) diversi a diverse larghezze di viewport. Ampio in orizzontale su desktop, più stretto in verticale su mobile. L'elemento <picture> gestisce questo con gli elementi <source>.

Il problema del CLS: questi ritagli di solito hanno aspect ratio diversi. Il browser deve sapere quali dimensioni corrispondono a quale breakpoint. Puoi impostare width e height su ogni <source>:

<picture>
    <source
        media="(max-width: 799px)"
        srcset="hero-mobile.jpg"
        width="480" height="600">
    <source
        media="(min-width: 800px)"
        srcset="hero-desktop.jpg"
        width="1200" height="400">
    <img
        src="hero-desktop.jpg"
        width="1200" height="400"
        alt="Product hero image">
</picture>

Chrome e Safari rilevano la larghezza/altezza corretta dal <source> che è attivo. Firefox no. C'è un bug (bug 1694741) per cui Firefox usa sempre le dimensioni del fallback <img>, indipendentemente dalla sorgente selezionata. Se il ritaglio mobile ha un rapporto diverso, Firefox mostra uno shift.

Se tutti i tuoi ritagli condividono lo stesso rapporto (solo risoluzioni diverse), questo bug non ha importanza. Si attiva solo quando le proporzioni differiscono tra i breakpoint.

Soluzione alternativa per Firefox

Fino al rilascio della correzione, utilizza delle media query CSS che corrispondano ai breakpoint nei tuoi elementi <source>:

<style>
picture img {
    width: 100%;
    height: auto;
}
@media (max-width: 799px) {
    picture img {
        aspect-ratio: 480 / 600;
    }
}
@media (min-width: 800px) {
    picture img {
        aspect-ratio: 1200 / 400;
    }
}
</style>

Questo sovrascrive il rapporto interno del browser con un CSS esplicito per breakpoint. Funziona in tutti i browser.

Mantieni lo stesso rapporto in tutte le fonti srcset

Le immagini responsive con srcset e sizes possono causare CLS se gli attributi width/height non corrispondono alla sorgente selezionata. La regola è semplice: tutte le immagini in un srcset devono condividere lo stesso aspect ratio. Se lo fanno, è sufficiente un solo set di width/height sull'<img>:

<img
    src="hero-800.jpg"
    srcset="hero-400.jpg 400w, hero-800.jpg 800w, hero-1200.jpg 1200w"
    sizes="(max-width: 600px) 100vw, 800px"
    width="800" height="450"
    alt="Hero image">

800:450 è lo stesso rapporto su tutte e tre le varianti. Non importa quale il browser scelga, lo spazio riservato è corretto.

Se mescoli i rapporti nello stesso srcset (una fonte a 16:9, un'altra a 4:3), lo spazio riservato sarà sbagliato per almeno una di esse. Non farlo. Usa invece <picture> con elementi <source> se hai bisogno di proporzioni diverse.

Quando sizes è sbagliato

L'attributo sizes indica al browser quanto sarà larga l'immagine a ogni dimensione di viewport. Se non corrisponde al layout CSS effettivo, il browser sceglie una sorgente troppo grande o troppo piccola. Questo non causa CLS (il rapporto rimane lo stesso), ma spreca larghezza di banda o produce un'immagine sfocata.

sizes=auto per immagini lazy-loaded

Chrome 126+ ed Edge 126+ supportano sizes="auto" sulle immagini in lazy loading. Il browser calcola la dimensione corretta dal layout CSS invece di fare affidamento sul tuo attributo sizes scritto manualmente. Non funziona sulle immagini caricate con eager loading perché il browser ha bisogno della dimensione del layout prima che il CSS sia stato elaborato.

Non usare il lazy-loading above the fold

Il lazy loading delle immagini above the fold causa due problemi contemporaneamente. Ritarda l'LCP perché loading="lazy" nasconde la risorsa al preload scanner. Il browser non può scoprire l'immagine fino a dopo il layout. E se l'immagine manca anche di dimensioni, si ottiene un layout shift in aggiunta al ritardo del caricamento.

Il Web Almanac 2025 riporta che il 16% delle pagine usa ancora il lazy loading per la propria immagine LCP. Questo significa che il 16% del web ritarda l'immagine più importante per ottenere zero benefici.

loading="lazy" va utilizzato per le immagini al di fuori della viewport iniziale. Da nessun'altra parte.

I placeholder da 1x1 pixel causano shift massicci

Gli script JavaScript per il lazy loading spesso usano una minuscola GIF trasparente di 1x1 pixel come placeholder in src mentre l'URL reale si trova in data-src. Quando si attiva l'IntersectionObserver, JavaScript li scambia.

Questo causa CLS perché il placeholder 1x1 viene renderizzato con un'altezza di 1px. Quando l'immagine da 800x450 viene caricata, l'elemento salta da 1px a 450px. Se stai ancora usando una libreria JavaScript per il lazy loading nel 2026, fermati. Il loading="lazy" nativo gestisce il placeholder internamente e rispetta gli attributi width/height. Ha il pieno supporto dei browser dal 2022.

Se hai un motivo specifico per mantenere il lazy loading via JavaScript (soglie di intersezione, animazioni fade-in), usa un placeholder con lo stesso aspect ratio dell'immagine finale. Un SVG trasparente 16x9 invece di un 1x1.

LQIP fatto nel modo giusto

Un placeholder con una miniatura sfocata è sempre meglio di uno spazio vuoto. La chiave: preservare l'aspect ratio. Se la tua immagine finale è 800x450, il tuo LQIP dovrebbe essere una versione minuscola (10x6 o 20x11) con lo stesso rapporto. Ingrandiscilo con il CSS, applica un filtro di sfocatura (blur). Quando l'immagine reale viene caricata, sostituisce la sfocatura con le stesse dimensioni. Nessuno shift.

Next.js lo fa automaticamente. Il componente Image genera width, height e blurDataURL in fase di build. Zero CLS.

Usa object-fit per contenitori a dimensione fissa

Griglie di schede prodotto in cui ogni scheda ha la stessa altezza ma le immagini hanno proporzioni diverse. Vedo costantemente questo pattern:

<style>
.product-image {
    width: 100%;
    aspect-ratio: 1 / 1;
    object-fit: cover;
    object-position: center;
}
</style>
<img
    src="product.jpg"
    width="400" height="600"
    class="product-image"
    alt="Product name">

aspect-ratio: 1 / 1 forza un quadrato. object-fit: cover riempie il quadrato e ritaglia l'eccesso. La dimensione è bloccata prima che l'immagine venga caricata.

Questo è anche il modo in cui puoi sostituire le immagini di sfondo CSS con dei veri elementi <img>. Le immagini di sfondo non possono essere caricate in lazy loading, non possono usare fetchpriority, e il preload scanner non le trova finché il file CSS non viene analizzato. Un <img> con object-fit: cover ti dà tutti i controlli sulle performance che mancano a un'immagine di sfondo.

I caroselli in autoplay producono CLS infinito

Le transizioni delle slide che animano left, width o margin attivano il ricalcolo del layout. Poiché l'autoplay non è un input dell'utente, ogni shift conta per il CLS. Un carosello in autoplay con transizioni che innescano variazioni di layout può produrre CLS all'infinito.

Fissa le dimensioni del contenitore con un aspect ratio fisso, anima con transform: translateX() invece di left o margin-left (le trasformazioni vengono eseguite sulla GPU e non innescano mai ricalcoli del layout), e se devi assolutamente usare l'autoplay, le dimensioni del contenitore delle slide non possono cambiare. Qualsiasi ridimensionamento conta come CLS.

In un carosello senza autoplay, la maggior parte delle transizioni avviene entro 500 ms da un clic dell'utente e sono escluse dal CLS. L'autoplay rimuove questa protezione. La guida ai caroselli di web.dev copre i dettagli di implementazione.

SVG, containment e altri casi limite

Gli SVG caricati tramite <img> hanno bisogno di larghezza e altezza sul tag, proprio come le immagini raster. Gli elementi <svg> inline hanno bisogno di dimensioni esplicite o di un viewBox con aspect-ratio nel CSS. Un SVG senza nessuna di queste opzioni ha un valore predefinito di 300x150.

Per gli elementi incorporati che non puoi controllare (spazi pubblicitari, widget di terze parti, contenuti generati dagli utenti), usa il CSS containment per impedire allo shift di propagarsi:

<style>
.embed-container {
    min-height: 250px;
    contain: layout style;
}
</style>

contain: layout style dice al browser che niente all'interno di questo contenitore influisce sul layout all'esterno di esso. L'elemento incorporato può subire uno shift, crescere o restringersi. Il resto della pagina rimane al suo posto.

Per le sezioni below-the-fold con contenuti multimediali pesanti, content-visibility: auto con contain-intrinsic-size salta il layout per i contenuti fuori dallo schermo. Senza contain-intrinsic-size, l'elemento ha un'altezza pari a zero e l'espansione, quando l'utente vi scorre sopra, è un layout shift:

<style>
.below-fold-gallery {
    content-visibility: auto;
    contain-intrinsic-size: auto 500px;
}
</style>

La parola chiave auto significa: inizia con 500px come stima, ma una volta che il browser lo renderizza e conosce l'altezza reale, ricorda quel valore.

Come trovare il CLS delle immagini

Non individuerai il CLS delle immagini sulla tua macchina. La cache del tuo browser possiede già le dimensioni. Hai bisogno delle condizioni di un visitatore al primo accesso o di dati di utenti reali.

Real User Monitoring

Inizia con CoreDash o un altro strumento RUM. I dati di attribuzione del CLS mostrano esattamente quali elementi hanno subito uno shift. Naviga semplicemente fino al CLS e guarda la tabella Elementi (Element) di attribuzione. Ti dirà esattamente quali elementi hanno subito uno shift. Per trovare le immagini basta filtrare per immagine (image) e otterrai una tabella di tutti gli elementi immagine interessati da layout shift ordinati per impatto.

Chrome DevTools

Disabilita la cache nella scheda Network (Rete), rallenta a Slow 4G, abilita gli screenshot, ricarica. Fai attenzione ai salti visivi. Quindi apri il pannello Performance (Prestazioni) e cerca le voci "Layout Shift". Fai clic su uno shift per vedere il nodo, il punteggio e se si è verificato in seguito a un input utente recente.

Core Web Vitals Visualizer

L'estensione Core Web Vitals Visualizer evidenzia ogni layout shift con un overlay colorato. La uso come primo passo prima di aprire il pannello Performance. Ricarica con l'estensione attiva e vedrai esattamente cosa si è mosso.

Lighthouse ne cattura una parte

Lighthouse segnala le immagini senza width e height. Ma si perde completamente il problema di width: auto perché gli attributi HTML sono presenti. Il CSS li sta sovrascrivendo e Lighthouse non controlla gli stili calcolati (computed styles). Questo è il motivo per cui non mi fido mai di un punteggio CLS verde di Lighthouse senza controllare anche i dati sul campo (field data).

Checklist per soluzioni rapide

A che punto è il web con il CLS delle immagini

I numeri del Web Almanac 2025:

• Il 62% delle pagine mobile ha almeno un'immagine senza dimensioni. In calo rispetto al 66% del 2024. Resta comunque la maggioranza.
• Il 65% delle pagine desktop ha immagini senza dimensioni. In calo rispetto al 69%.
• Al p75, una pagina desktop ha 9 immagini senza dimensioni. Il mobile ne ha 8.
• Al p90: 25 su desktop, 22 su mobile.
• Altezza mediana delle immagini senza dimensioni: 111px su desktop, 98px su mobile. Abbastanza per causare lo shift di un paragrafo.
• Il 72% delle origini desktop e l'81% delle origini mobile superano il test per il CLS. In aumento rispetto al 62% del 2021.
• Il 40% delle pagine mobile utilizza ancora animazioni non composite che causano CLS per conto proprio.

Il CLS è migliorato più di qualsiasi altro Core Web Vitals negli ultimi quattro anni. Le immagini non dimensionate rimangono il principale fattore scatenante. Risolvi questo singolo problema e i layout shift scompariranno sulla maggior parte dei siti.

Guide correlate

• Cos'è il Cumulative Layout Shift (CLS): La guida completa. Formula, soglie, finestre di sessione e tutte le cause di CLS oltre le immagini.
• Trovare e Risolvere i Problemi di CLS: Diagnostica passo passo con dati RUM, DevTools e soluzioni per ogni causa.
• Risolvere il layout shift causato dal dimensionamento automatico delle immagini: La guida completa a width: auto.
• Ottimizzare le immagini per i Core Web Vitals: Preloading, immagini responsive, formati, prioritizzazione.
• Layout shift causato dalle transizioni CSS: Come le animazioni che innescano ricalcoli del layout causano CLS.
• Embed perfetti di YouTube: Il facade pattern per avere zero CLS.
• Google Maps 100% PageSpeed: Stesso approccio a facade per le mappe.