Immagini Responsive (srcset)

TL;DR — Le immagini responsive consentono al browser di caricare una versione delle giuste dimensioni di un’immagine invece di un unico file enorme: una piccola su uno smartphone, una grande su un desktop. Si fa con gli attributi srcset e sizes sul tag <img> (elenca le dimensioni che hai; il browser sceglie). Questo non migliora direttamente il posizionamento, ma rende le pagine più veloci ed evita che “saltino” mentre le immagini si caricano, e la velocità è una cosa che Google misura.

Cosa sono le immagini responsive

Un’immagine “responsive” si adatta al dispositivo che la visualizza. Invece di inviare la stessa enorme foto a uno smartphone e a un desktop, fornisci al browser alcune versioni a dimensioni diverse e gli lasci scegliere quella più adatta. Gli smartphone ricevono un file piccolo; gli schermi grandi uno grande. Meno dati sprecati, pagine più veloci.

Ci sono due modi per farlo, ed è utile sapere qual è la differenza:

• srcset + sizes su <img> — il più comune. Stessa immagine, dimensioni diverse. Elenchi ciò che hai e il browser sceglie. Si chiama resolution switching.
• L’elemento <picture> — per quando vuoi un’immagine davvero diversa a dimensioni diverse (ad esempio, un ritaglio ampio su desktop e uno stretto e alto su mobile), oppure un formato di file moderno con un fallback. Si chiama art direction, e la maggior parte dei siti non ne ha bisogno.

La versione base

Ecco come appare il resolution switching:

<img
  src="puppy-1000.jpg"
  srcset="puppy-1000.jpg 1000w, puppy-2000.jpg 2000w, puppy-3000.jpg 3000w"
  sizes="(max-width: 600px) 480px, 1000px"
  width="1000" height="1000"
  alt="Puppy with balloons" />

• src è il tuo normale fallback, sempre presente. Tienilo.
• srcset elenca le versioni che hai e la larghezza di ciascuna (1000w = 1000 pixel di larghezza).
• sizes dice al browser quanto sarà grande l’immagine nella pagina, così può scegliere il file giusto prima di caricare qualsiasi cosa.
• width e height riservano lo spazio così la pagina non salta mentre l’immagine si carica.
• alt è la stessa descrizione che scriveresti sempre. Tienila identica in ogni versione.

Perché preoccuparsene (la risposta onesta)

Le immagini responsive non ti fanno guadagnare un “boost” nel posizionamento. Quello che fanno è rendere le pagine più veloci ed evitare che il layout si sposti — e queste sono cose che Google misura come parte dell’esperienza di pagina. Se uno strumento di velocità (Lighthouse, PageSpeed Insights) ti sta dicendo di “dimensionare correttamente le immagini”, srcset/sizes è la soluzione che sta chiedendo.

Un’altra cosa: questo non cambia ciò che appare in Google Immagini. Google indicizza l’immagine nell’attributo src — le varianti responsive sono solo consegna. Quindi mantieni il testo alt, il nome del file e l’URL dell’immagine principale invariati, indipendentemente dalla versione che il browser carica.

Vuoi la versione precisa — descrittori w vs x, quando ti serve davvero <picture>, le meccaniche di LCP e layout shift, e le regole di indicizzazione mobile — passa alla scheda Avanzate.

TL;DR — Due lavori, una famiglia di sintassi. srcset/sizes su <img> = resolution switching (stessa immagine, il browser sceglie la migliore — un suggerimento); <picture> = art direction o format switching (ritagli/formati decisi dall’autore — un comando). La maggior parte dei siti ha bisogno solo del primo. Le immagini responsive non sono un segnale di ranking diretto e non cambiano ciò che Google indicizza — Google indicizza l’URL src, quindi mantieni testo alt, nomi file e URL delle immagini stabili tra i breakpoint (indicizzazione mobile-first). Il vero vantaggio sono i Core Web Vitals: dimensionare correttamente le immagini è la soluzione dietro l’audit “Properly size images” di Lighthouse (fallisce con uno scarto di 4KiB), e width/height (o aspect-ratio) — non srcset — è ciò che previene il CLS. Non caricare in lazy-load l’immagine LCP. Riutilizzo esattamente il pattern srcset + width/height dal mio articolo Ahrefs sul CLS.

Due lavori diversi, una famiglia di sintassi

Tutto in questo argomento si riduce a due meccanismi, e metà della confusione là fuori nasce dal mescolarli:

1. Cambio di risoluzione — la stessa immagine a dimensioni o densità di pixel diverse. Dai al browser un menu con srcset e sizes sull’<img>, e il browser decide quale file scaricare in base al viewport e alla densità dello schermo. Questo è il caso comune.
2. Art direction — un’immagine davvero diversa per condizione: un ritaglio largo su desktop, un ritaglio verticale stretto su mobile, o un formato di file completamente diverso. Qui tu imponi la scelta con l’elemento <picture>.

Il corso web.dev Learn: Responsive images spiega la differenza esattamente nel modo giusto: con srcset il browser riceve suggerimenti, mentre “the picture element gives commands.” E la frase che definisce l’ambito, degna di essere tatuata sul muro, sempre da web.dev: “You probably won’t need to use the picture element for most of your responsive images — the srcset and sizes attributes on the img element cover a lot of use cases.” (traduzione) «Probabilmente non avrai bisogno di usare l’elemento picture per la maggior parte delle tue immagini responsive — gli attributi srcset e sizes sull’elemento img coprono molti casi d’uso.» Ricorri a <picture> solo quando ti serve davvero un’immagine diversa, non una dimensione diversa della stessa.

srcset e sizes — cambio di risoluzione

Descrittori w vs. descrittori x

srcset accetta un elenco separato da virgole di file candidati, ciascuno etichettato con un descrittore. Ce ne sono due tipi:

• Descrittori di larghezza (w) — dichiari la larghezza intrinseca in pixel di ogni file (puppy-2000.jpg 2000w). Il browser combina questo con il tuo valore sizes per capire quale file si adatta meglio allo spazio e alla densità di pixel del dispositivo. Questa è l’opzione flessibile e quella che userai più spesso.
• Descrittori di densità di pixel (x) — dichiari quale file è per quale rapporto di pixel del dispositivo (logo.png 1x, logo@2x.png 2x). Usali per immagini a dimensione fissa (un avatar, un logo) dove la dimensione visualizzata non cambia mai; non ti serve sizes con i descrittori x.

Regola pratica: immagini fluide a larghezza di contenuto → descrittori w + sizes; immagini UI a dimensione fissa → descrittori x.

Perché sizes è importante (e cosa succede se lo salti)

Con i descrittori w, sizes non è un optional estetico — è il modo in cui il browser sa quanto grande verrà renderizzata l’immagine, così può scegliere prima del layout. Secondo web.dev, sizes “tells the browser what size you expect the image to be displayed at under different conditions,” come elenco separato da virgole di condizioni media e larghezze:

sizes="(max-width: 600px) 480px, 1000px"

Leggilo come: “se il viewport è 600px o più stretto, l’immagine sarà larga circa 480px; altrimenti, circa 1000px.” Se ometti sizes, il browser assume che l’immagine riempia tutta la larghezza del viewport (100vw) — quindi su uno schermo largo potrebbe scaricare il tuo file più grande per un’immagine che in realtà viene renderizzata a 400px, vanificando silenziosamente tutto lo scopo. La mancanza di sizes è l’errore srcset più comune.

Non indovinare quei valori di larghezza dal layout nella tua testa — controlla la larghezza CSS effettiva renderizzata dell’immagine nel browser (DevTools → Elements → la larghezza calcolata del box dell’<img>) a ogni breakpoint che ti interessa, e imposta sizes di conseguenza. Un valore sizes che non corrisponde alla larghezza renderizzata reale fa comunque sì che il browser selezioni il candidato sbagliato anche se il markup è sintatticamente corretto — la validazione della sintassi da sola non lo rileva; vedi il controllo currentSrc qui sotto per confermare cosa è stato effettivamente caricato.

Esempio pratico (il mio schema riutilizzabile)

Questo è lo schema esatto dal mio articolo su Ahrefs, What Is Cumulative Layout Shift (CLS) & How To Improve It, espanso con sizes:

<img
  src="puppy-1000.jpg"
  srcset="puppy-1000.jpg 1000w,
          puppy-2000.jpg 2000w,
          puppy-3000.jpg 3000w"
  sizes="(max-width: 600px) 480px, 1000px"
  width="1000" height="1000"
  alt="Puppy with balloons" />

Ogni elemento è fondamentale: src è il fallback e l’URL che Google indicizza; srcset elenca i candidati con i descrittori w; sizes indica al browser la larghezza di rendering; width/height riservano spazio (la soluzione per il CLS — più sotto); alt resta identico indipendentemente dal file caricato.

L’elemento picture — direzione artistica e cambio di formato

Quando ti serve davvero

Usa <picture> per due cose che srcset non può fare:

1. Direzione artistica — un ritaglio diverso per ogni breakpoint. L’esempio di web.dev: su uno smartphone stretto potresti servire un ritaglio alto e stretto; su un desktop largo, uno corto e largo. Stesso soggetto, inquadratura deliberatamente diversa.
2. Cambio di formato — offri AVIF/WebP con un fallback JPEG tramite <source type="…">, lasciando che il browser scelga il primo formato supportato. Questo si ricollega direttamente alle linee guida sui formati nell’hub SEO per le immagini.

La sintassi (e la regola del fallback)

L’elemento <picture> racchiude uno o più elementi <source> e termina sempre con un semplice <img>:

<!-- Art direction: different crop per breakpoint -->
<picture>
  <source media="(max-width: 600px)" srcset="hero-crop-mobile.jpg">
  <img src="hero-crop-desktop.jpg" width="1200" height="675"
       alt="Product hero shot">
</picture>

<!-- Format switching: modern format with a fallback -->
<picture>
  <source type="image/avif" srcset="hero.avif">
  <source type="image/webp" srcset="hero.webp">
  <img src="hero.jpg" width="1200" height="675" alt="Product hero shot">
</picture>

Quel <img src> finale non è opzionale. Google lo afferma direttamente: secondo la sezione 4.8.1 dello standard HTML, “make sure that you provide an img element as a fallback with a src attribute when using the picture element.” (traduzione) «Assicurati di fornire un elemento img come fallback con un attributo src quando usi l’elemento picture.» È il file a cui ricorrono i browser più vecchi e i crawler — e, di nuovo, quello che Google indicizza.

srcset aiuta la SEO? Direttamente vs. indirettamente

Ecco l’inquadramento che tutte le guide concorrenti sbagliano, quindi sarò diretto.

Direttamente: no. Il markup delle immagini responsive non è un segnale di ranking come lo sono l’alt text o i nomi dei file per la ricerca di immagini. Aggiungere srcset non alza le tue posizioni e non cambia ciò che appare in Google Immagini. Google indicizza l’immagine referenziata in src; le varianti srcset/<picture> sono un meccanismo di consegna, non asset indicizzabili separatamente. Mantieni l’alt text, il nome del file e i dati strutturati associati a quell’immagine src primaria.

Indirettamente: sì, ed è una delle leve più grandi che hai. Immagini dimensionate correttamente sono la soluzione concreta più efficace per due Core Web Vitals — LCP e CLS — che alimentano i segnali di page-experience di Google. Questo è tutto il vantaggio. È la stessa forma della storia WebP/AVIF nell’hub SEO per le immagini: nessun boost per il formato in sé, la vittoria è la velocità.

Immagini responsive e LCP

Le immagini sovradimensionate sono una delle cause più comuni di un Largest Contentful Paint lento, e le immagini responsive sono la soluzione raccomandata da Lighthouse. L’audit “Properly size images” di Lighthouse elenca “all images in your page that aren’t appropriately sized, along with the potential savings” (traduzione) «tutte le immagini nella tua pagina che non sono dimensionate in modo appropriato, insieme ai risparmi potenziali» — qualsiasi cosa più grande del necessario “just results in wasted bytes and slows down page load time.” (traduzione) «si traduce solo in byte sprecati e rallenta il tempo di caricamento della pagina.» La sua soluzione, testualmente: “With responsive images, you generate multiple versions of each image, and then specify which version to use in your HTML or CSS using media queries, viewport dimensions, and so on.” (traduzione) «Con le immagini responsive, generi più versioni di ogni immagine, e poi specifichi quale versione usare nel tuo HTML o CSS usando media query, dimensioni del viewport e così via.»

Due dettagli che vale la pena conoscere:

• La soglia di errore è 4KiB. Lighthouse segnala un’immagine solo quando “the rendered size is at least 4KiB smaller than the actual size.” (traduzione) «la dimensione renderizzata è almeno 4KiB più piccola della dimensione effettiva.» Piccoli superamenti non contano; servire un file da 3000px in uno slot da 400px sì.
• Una scorciatoia con gli strumenti. Google raccomanda RespImageLint, “a helpful bookmarklet for identifying the optimal srcset and sizes values for your images.” (traduzione) «un bookmarklet utile per identificare i valori ottimali di srcset e sizes per le tue immagini.» Eseguilo prima di calcolare a mano i breakpoint.

Non caricare pigramente l’immagine LCP

Questa è la regola che la gente infrange più spesso. srcset sulla tua hero va bene — ma non abbinarlo mai al lazy loading sull’elemento LCP. L’immagine più grande sopra la piega dovrebbe caricarsi eager con fetchpriority="high", esattamente come copre l’hub Image SEO. E quando costruisci una hero <picture> responsive, mantieni la logica di scambio nativa: Google avverte che “non caricherà contenuti che richiedono interazioni utente” come lo swipe o il click, quindi uno schema JS che carica l’immagine reale solo dopo l’interazione la nasconde a Google.

Immagini responsive e CLS

Ecco la trappola: srcset da solo non fa nulla per lo spostamento del layout. Il cambio di risoluzione decide quale file caricare; non riserva spazio per esso. Senza dimensioni, secondo la guida Optimize CLS di web.dev, “man mano che le immagini si caricano, il testo si sposta verso il basso nella pagina per fare spazio” — perché lo spazio “non può essere allocato finché il browser non inizia a scaricarlo e non può determinarne le dimensioni.”

La soluzione sono dimensioni esplicite, e si combina con il markup responsive:

• Imposta gli attributi width e height sull’<img>. I browser moderni “impostano il rapporto d’aspetto predefinito delle immagini in base agli attributi width e height dell’immagine,” quindi quei due numeri riservano il riquadro corretto prima che qualsiasi variante srcset venga scaricata. (web.dev)
• Abbinali a height: auto in CSS per contenitori fluidi. Questa è la parte che sembra contraddittoria ma non lo è: la guida di web.dev stessa è di “usare CSS per ridimensionare l’immagine alla larghezza del contenitore” e “impostare height: auto; per evitare di usare un valore fisso per l’altezza dell’immagine.” Gli attributi HTML impostano il rapporto d’aspetto intrinseco; il CSS permette all’immagine di scalare in modo fluido. Insieme prevengono il CLS e restano responsive.
• Oppure usa aspect-ratio in CSS per riservare lo spazio quando non puoi impostare gli attributi.

Il che sfata un mito persistente: gli attributi width/height non rompono i layout fluidi. Attributi + height: auto è la combinazione corretta, non un conflitto. Spiego tutta la meccanica dello spostamento del layout nel mio articolo Ahrefs CLS; la versione breve è “riserva lo spazio così che non ci sia spostamento” e lascia che l’immagine lo riempia.

Implicazioni dell’indicizzazione mobile-first

Google indicizza principalmente la versione mobile delle tue pagine, quindi due regole contano più di prima quando servi varianti responsive:

• Mantieni lo stesso testo alt su tutti i breakpoint. Le best practice per l’indicizzazione mobile-first di Google dicono di “assicurarsi che il sito mobile abbia lo stesso testo alt per le immagini del sito desktop.” Un crop mobile art-directed non deve perdere il contesto di cui Google ha bisogno.
• Mantieni stabili gli URL delle immagini. Non usare URL che cambiano ogni volta che la pagina viene caricata per le immagini. Questo si allinea con la guida Image SEO di Google per riferire costantemente l’immagine con lo stesso URL così che possa essere memorizzata nella cache e riutilizzata. I CDN responsive che generano un nuovo URL per ogni richiesta rompono questo — fissa URL stabili per le tue varianti.

Il riepilogo di Google sul perché vale la pena è semplice: “progettare pagine web responsive porta a una migliore esperienza utente, poiché le persone possono accedervi da una moltitudine di tipi di dispositivi.”

E Bing?

Non esiste una guida specifica di Bing su srcset, sizes o l’elemento <picture> — la documentazione pubblica di Bing non affronta affatto il markup delle immagini responsive. Quindi non motivare le immagini responsive con un gancio algoritmico di Bing; il caso è prestazioni e UX, che Bing (come Google) tratta come qualità dell’esperienza di pagina piuttosto che qualcosa a cui puoi fare riferimento con una regola documentata per le immagini responsive.

Errori comuni

• Dimenticare sizes con i descrittori w — il browser assume 100vw e potrebbe scaricare il file più grande per uno slot piccolo.
• Tralasciare il src di fallback su <picture> — una violazione delle specifiche che Google segnala esplicitamente, ed è l’URL che i crawler indicizzano.
• Proporzioni width/height non corrispondenti rispetto all’immagine effettivamente servita — causa ancora spostamento.
• Lazy-loading dell’hero LCP — ritarda l’LCP senza motivo; caricalo con eager loading e fetchpriority="high".
• Rigenerare gli URL delle immagini per ogni richiesta — rompe la cache di Google e la regola mobile-first dell‘“URL stabile”.
• Ricorrere a <picture> quando srcset/sizes basterebbero — complessità inutile; web.dev dice che la maggior parte dei siti non ne ha bisogno.

Dove si colloca

Questo è l’approfondimento su dimensionamento e consegna sotto l’hub più ampio di Image SEO — la metà delle prestazioni dell’image SEO, in parallelo a come la guida sul testo alt gestisce la metà della ricerca di immagini. Per i meccanismi completi dello spostamento del layout, vedi il mio articolo Ahrefs su CLS; per LCP, fetchpriority e la strategia di caricamento, quello è lavoro Core Web Vitals con un cappello da immagine.

Riepilogo AI

Una sintesi della versione Advanced:

• Due meccanismi, una famiglia. srcset/sizes su <img> = cambio di risoluzione (stessa immagine, il browser sceglie la migliore — un suggerimento). <picture> = art direction o cambio di formato (ritagli/formati decisi dall’autore — un comando). La maggior parte dei siti ha bisogno solo di srcset/sizes.
• Descrittori: i descrittori w (larghezza) richiedono un attributo sizes e coprono immagini fluide, a larghezza di contenuto; i descrittori x (densità di pixel) sono adatti a immagini UI a dimensione fissa e non richiedono sizes.
• sizes è obbligatorio con i descrittori w — se lo ometti, il browser assume 100vw, spesso scaricando il file più grande inutilmente. Errore srcset più comune.
• Non è un segnale di ranking diretto. Il markup responsive non cambia ciò che Google indicizza — Google indicizza l’URL src; le varianti sono solo consegna. Mantieni testo alt, nomi file e dati strutturati sull’immagine src primaria.
• Vantaggio LCP: le immagini sovradimensionate sono una delle principali cause di LCP lento; le immagini responsive sono la correzione raccomandata da Lighthouse (audit “Properly size images”; fallisce con un divario di 4KiB; RespImageLint aiuta a scegliere srcset/sizes).
• CLS: srcset da solo non fa nulla per lo spostamento — imposta gli attributi width/height (o CSS aspect-ratio), abbinati a height: auto per layout fluidi. Attributi + height: auto è la combinazione corretta, non un conflitto.
• Non fare mai lazy-load dell’immagine LCP; caricala con eager loading e fetchpriority="high", e mantieni gli scambi responsive nativi (Google non caricherà contenuti attivati da interazioni).
• Indicizzazione mobile-first: stesso testo alt e URL immagine stabili su tutti i breakpoint; non creare un nuovo URL per ogni richiesta.
• Bing: nessuna guida dedicata alle immagini responsive — giustifica il lavoro su prestazioni/UX.

Documentazione ufficiale

Documentazione di fonti primarie e guida per sviluppatori.

Google — Ricerca

• Best practice per le immagini di Google — la nota su srcset, il requisito del src di fallback per <picture>, la guida sullo stesso URL e la logica del design responsive.
• Best practice per l’indicizzazione mobile-first — stesso testo alt e URL immagine stabili su mobile e desktop; non fare lazy-load dei contenuti primari su interazione.

Google — web.dev (linee guida per sviluppatori)

• Learn: Responsive images — srcset integra src; come funzionano sizes e le condizioni media.
• Learn: The picture element — quando serve <picture>, art direction e “suggerimenti vs. comandi.”
• Optimize Cumulative Layout Shift — attributi width/height, aspect ratio e height: auto per immagini fluide.
• Fetch Priority API — fetchpriority="high" per l’immagine LCP.

Chrome DevTools / Lighthouse

• Properly size images (uses-responsive-images) — l’audit, la soglia di 4KiB e il bookmarklet RespImageLint.

MDN

• Using responsive images in HTML — il riferimento per srcset, sizes, descrittori w/x e sintassi <picture>.

Citazioni dalla fonte

Dichiarazioni ufficiali dalla documentazione e dalle linee guida per sviluppatori di Google. Dove una pagina espone il testo, il link è un deep link che salta al passaggio citato.

Google — Documentazione SEO per le immagini

• “The srcset attribute allows specifying different versions of the same image, specifically for different screen sizes.” (traduzione) «L’attributo srcset consente di specificare diverse versioni della stessa immagine, in particolare per diverse dimensioni dello schermo.» Vai alla citazione
• “Designing responsive web pages leads to better user experience, since people can access them across a plethora of device types.” (traduzione) «Progettare pagine web responsive porta a una migliore esperienza utente, poiché le persone possono accedervi su una moltitudine di tipi di dispositivi.» Fonte
• Sulla stabilità degli URL delle immagini: “consistently reference the image with the same URL, so that Google can cache and reuse the image.” (traduzione) «fai riferimento in modo coerente all’immagine con lo stesso URL, così che Google possa memorizzarla nella cache e riutilizzarla.» Vai alla citazione

Google — Documentazione sull’indicizzazione mobile-first

• “Make sure that the mobile site has the same alt text for images as the desktop site.” (traduzione) «Assicurati che il sito mobile abbia lo stesso testo alt per le immagini del sito desktop.» Vai alla citazione
• “Don’t use URLs that change every time the page loads for images.” (traduzione) «Non usare URL che cambiano ogni volta che la pagina viene caricata per le immagini.» Vai alla citazione

web.dev — srcset vs. picture

• “Where the srcset attribute gives suggestions to the browser, the picture element gives commands.” (traduzione) «Dove l’attributo srcset dà suggerimenti al browser, l’elemento picture dà comandi.» Vai alla citazione

Io — sulla correzione del CLS

• “Reserve the space so that there’s no shift” e l’immagine semplicemente lo riempie. (traduzione) «Riserva lo spazio così che non ci sia spostamento» e l’immagine semplicemente lo riempie. Vai alla citazione

Pattern di immagini responsive copia-incolla

Tre pattern che coprono quasi ogni caso reale. Tutti mantengono un src di fallback, width/height espliciti (la correzione del CLS) e testo alt identico.

1. Cambio di risoluzione — il quotidiano <img srcset> (il mio schema riutilizzabile)

<img
  src="puppy-1000.jpg"
  srcset="puppy-1000.jpg 1000w,
          puppy-2000.jpg 2000w,
          puppy-3000.jpg 3000w"
  sizes="(max-width: 600px) 480px, 1000px"
  width="1000" height="1000"
  alt="Puppy with balloons" />

Abbinalo a questo CSS affinché l’immagine si adatti in modo fluido senza causare spostamenti del layout:

img {
  max-width: 100%;
  height: auto; /* with width/height attributes set, this prevents CLS */
}

2. Immagine a dimensione fissa — descrittori di densità di pixel (x), nessun sizes necessario

<img
  src="logo.png"
  srcset="logo.png 1x, logo@2x.png 2x"
  width="200" height="60"
  alt="Company logo" />

3. L’eroe LCP — eager + alta priorità, e fallback di formato tramite <picture>

<picture>
  <source type="image/avif" srcset="hero.avif">
  <source type="image/webp" srcset="hero.webp">
  <img
    src="hero.jpg"
    width="1200" height="675"
    fetchpriority="high"
    loading="eager"
    alt="Product hero shot" />
</picture>

Regole incorporate in questi esempi:

• Mantieni sempre il <img src> finale — è il fallback e l’URL che Google indicizza.
• Con i descrittori w, sizes è obbligatorio; senza, il browser assume 100vw.
• Con i descrittori x, ometti sizes.
• Non aggiungere mai loading="lazy" all’immagine LCP (schema 3) — questo ritarda l’LCP; usa fetchpriority="high" invece.

Per trovare i valori giusti di srcset/sizes invece di indovinare, esegui RespImageLint, il bookmarklet raccomandato da Google, sulla pagina live.

Quale ti serve davvero: srcset/sizes o picture?

Segui il vero ramo che l’articolo traccia tra il cambio di risoluzione e la direzione artistica / il cambio di formato.

La maggior parte dei siti si ferma al primo ramo e non lascia mai srcset/sizes — ricorri a <picture> solo quando l’immagine stessa deve cambiare, non solo la sua dimensione.

Cosa non fare

Sei errori concreti che l’articolo evidenzia, ciascuno con il motivo per cui è sbagliato e la correzione.

• Dimenticare l’attributo sizes con i descrittori w. Perché è sbagliato: senza sizes, il browser assume che l’immagine riempia l’intera larghezza del viewport (100vw), quindi potrebbe scaricare il candidato più grande per uno spazio che viene renderizzato molto più piccolo. Fai invece: abbina sempre srcset con descrittori w a un valore sizes che corrisponda a come l’immagine viene effettivamente renderizzata a ogni breakpoint.
• Tralasciare il fallback <img src> su <picture>. Perché è sbagliato: è una violazione delle specifiche che Google segnala esplicitamente, ed è l’URL che i crawler e Google Images indicizzano effettivamente — nessun fallback significa nessuna immagine indicizzabile. Fai invece: ogni blocco <picture> termina con un semplice <img src="...">, mai solo elementi <source>.
• Rapporto width/height non corrispondente rispetto all’immagine effettivamente servita. Perché è sbagliato: gli attributi impostano il rapporto d’aspetto riservato; se l’immagine reale non corrisponde, il layout si sposta comunque una volta che l’immagine viene caricata. Fai invece: mantieni il rapporto width/height (o aspect-ratio) identico ai file immagine che stai effettivamente servendo in tutte le varianti srcset/<picture>.
• Caricare pigramente l’immagine hero LCP. Perché è sbagliato: loading="lazy" ritarda il recupero proprio dell’immagine che Largest Contentful Paint sta misurando, spingendo LCP più avanti senza alcun beneficio. Fai invece: carica l’immagine LCP in modo eager con fetchpriority="high", mai loading="lazy".
• Rigenerare gli URL delle immagini a ogni richiesta. Perché è sbagliato: rompe la cache delle immagini di Google e viola la regola dell’indicizzazione mobile-first contro gli URL che cambiano a ogni caricamento della pagina. Fai invece: fissa URL stabili e coerenti per ogni variante di immagine così che Google possa metterli in cache e riutilizzarli.
• Ricorrere a <picture> quando srcset/sizes basterebbero. Perché è sbagliato: è complessità inutile — web.dev è esplicito sul fatto che la maggior parte dei siti non ha bisogno di <picture> affatto. Fai invece: usa per impostazione predefinita il cambio di risoluzione con srcset/sizes; aggiungi <picture> solo quando hai davvero bisogno di un ritaglio o formato diverso per condizione.

Problemi comuni

Ricerca basata sui sintomi per i due problemi delle immagini responsive che i lettori incontrano realmente.

Il layout si sposta ancora (CLS) anche se srcset è configurato

• Sintomo: Lighthouse o PageSpeed Insights segnalano ancora spostamenti del layout su un’immagine, oppure vedi visivamente il contenuto saltare mentre l’immagine viene caricata, nonostante un srcset/sizes funzionante.
• Causa probabile: srcset da solo non fa nulla per lo spostamento del layout — decide solo quale file caricare, non quanto spazio riservare. L’immagine non ha attributi width/height (o aspect-ratio CSS), quindi il browser non può allocare spazio finché il file non inizia a scaricarsi e le sue dimensioni non sono note.
• Correzione + conferma: Aggiungi attributi width e height espliciti all’<img> (o imposta aspect-ratio CSS) e abbinali a height: auto nel CSS così che l’immagine continui a scalare fluidamente. Conferma rieseguendo il controllo CLS (Lighthouse o un controllo CrUX live) e osservando che lo spostamento scompaia — il box riservato dovrebbe ora mantenere la sua dimensione prima che l’immagine finisca di caricarsi.

Lighthouse segnala “Properly size images” / un’immagine sovradimensionata viene caricata

• Sintomo: L’audit Lighthouse “Dimensiona correttamente le immagini” elenca una o più immagini con byte sprecati, oppure una pagina risulta lenta a raggiungere il suo Largest Contentful Paint anche se l’immagine stessa sembra a posto.
• Causa probabile: La dimensione renderizzata dell’immagine è almeno 4KiB inferiore al file effettivamente servito — comunemente perché non c’è alcun srcset, oppure manca sizes e il browser ha usato il valore predefinito 100vw selezionando il candidato più grande per uno spazio piccolo.
• Correzione + conferma: Aggiungi (o correggi) srcset con candidati di dimensioni appropriate e un valore sizes che corrisponda alla larghezza renderizzata reale; esegui RespImageLint per verificare i valori invece di fare supposizioni. Conferma eseguendo di nuovo l’audit Lighthouse “Dimensiona correttamente le immagini” e controllando che l’immagine segnalata non compaia più (o che il suo risparmio potenziale scenda sotto la soglia di 4KiB).

Cheat sheet: descrittori, picture vs. srcset e regole CLS/LCP

Test di validazione

Controlli di superamento/fallimento che confermano che una modifica alle immagini responsive ha effettivamente avuto effetto.

Le immagini dimensionate correttamente vengono servite correttamente

Test da eseguire: Esegui l’audit Lighthouse “Dimensiona correttamente le immagini” (Chrome DevTools > Lighthouse > Performance, o PageSpeed Insights) sulla pagina che hai appena aggiornato. Risultato atteso: L’immagine che hai corretto non compare più nell’elenco segnalato dall’audit, oppure il suo risparmio potenziale scende sotto la soglia del divario di 4KiB. Interpretazione del fallimento: Se è ancora segnalata, o i candidati srcset sono ancora troppo grandi per la dimensione renderizzata, oppure sizes manca/è sbagliato e il browser sta ancora usando il valore predefinito 100vw. Finestra di monitoraggio: Immediata — riesegui subito dopo aver distribuito la modifica. Trigger di rollback: L’audit segnala ancora la stessa immagine con risparmio potenziale invariato dopo aver confermato che sizes corrisponde alla larghezza renderizzata reale.

I valori srcset/sizes sono effettivamente ottimali

Test da eseguire: Esegui RespImageLint (il bookmarklet raccomandato da Google) sulla pagina live. Risultato atteso: Nessun avviso su candidati sovradimensionati o su un valore sizes mancante/errato. Interpretazione del fallimento: Un avviso significa che un candidato è inutilmente grande per il suo breakpoint o che sizes non corrisponde alla larghezza renderizzata reale del contenitore. Finestra di monitoraggio: Immediata, sull’URL live dopo la distribuzione. Trigger di rollback: RespImageLint continua a segnalare la stessa immagine dopo che hai corretto il valore sizes.

Il browser ha effettivamente selezionato il candidato che ti aspettavi

Test da eseguire: Superare i controlli Lighthouse/RespImageLint conferma che il tuo markup è valido — non conferma che il browser abbia scelto il file che intendevi a un dato viewport. Carica la pagina al breakpoint che ti interessa, apri DevTools, seleziona l’<img> e controlla la proprietà currentSrc nella console ($0.currentSrc in Chrome/Firefox DevTools) — l’esempio di MDN fa esattamente questo: confronta currentSrc con il nome file previsto per confermare quale candidato è stato caricato. Controlla anche la scheda Network per vedere quale file è stato effettivamente richiesto. Ripeti ai tuoi breakpoint stretti e larghi, e a 1x e 2x di device pixel ratio se lo emuli. Risultato atteso: currentSrc corrisponde al file candidato che ti aspetteresti per quella larghezza di viewport e densità di pixel, e la scheda Network mostra che è stato scaricato solo quel file. Interpretazione del fallimento: Se currentSrc restituisce un candidato più grande o più piccolo del previsto, o il valore di sizes non corrisponde alla larghezza CSS effettivamente renderizzata dell’immagine (vedi “Perché sizes è importante” nella scheda Avanzate) oppure un descrittore di srcset è sbagliato. Nota che la selezione del browser è definita dall’implementazione — lo standard HTML lascia la scelta esatta tra i candidati validi al browser (densità, zoom e condizioni di rete possono tutti influire), quindi non aspettarti un comportamento identico tra browser; verifica la presenza di un “candidato ragionevole”, non una risposta fissa. Finestra di monitoraggio: Immediata — controlla per ogni breakpoint subito dopo la distribuzione. Trigger di rollback: currentSrc continua a restituire un candidato sovradimensionato a un viewport stretto dopo aver corretto sizes per corrispondere alla larghezza reale renderizzata.

Nessuno spostamento del layout dovuto all’immagine

Test da eseguire: Controlla il Cumulative Layout Shift della pagina — il punteggio CLS di Lighthouse, o un controllo live dei dati sul campo CrUX/PageSpeed Insights per l’URL. Risultato atteso: Il CLS attribuibile all’immagine scende a (quasi) zero una volta impostati width/height (o aspect-ratio). Interpretazione del fallimento: Uno spostamento persistente di solito significa che il rapporto width/height non corrisponde all’immagine effettivamente servita, o che gli attributi mancano del tutto. Finestra di monitoraggio: I dati di laboratorio sono immediati; i dati sul campo (CrUX) richiedono circa 28 giorni per accumulare una tendenza affidabile. Trigger di rollback: Il CLS nei dati sul campo non migliora dopo 28 giorni nonostante il controllo di laboratorio sia superato — rivaluta se il rapporto dell’immagine servita corrisponde effettivamente al box riservato.

Mettiti alla prova: Immagini responsive

Cinque domande rapide su srcset, sizes, <picture> e su come le immagini responsive influenzano la SEO. Scegli una risposta per ciascuna, poi controlla.

Cronologia modifiche