Perché PageSpeed Insights continua a dire “Dimensiona le immagini correttamente” anche se ho un srcset?

Ha fatto tutto come si deve. Le sue immagini hanno un srcset ben popolato, diverse larghezze generate, WebP (un formato immagine di nuova generazione, più leggero di JPEG o PNG). Eppure l'audit di PageSpeed Insights mostra ancora Dimensiona le immagini correttamente, con diverse centinaia di KB indicati come possibile risparmio.

Non è un bug di PageSpeed. È un fraintendimento molto comune su come funzionano davvero le immagini responsive. Chiariamolo una volta per tutte.

Cosa fa srcset e cosa non fa

Prendiamo un caso tipico:

<img
  src="photo-1200.jpg"
  srcset="photo-400.jpg 400w,
          photo-800.jpg 800w,
          photo-1200.jpg 1200w,
          photo-2000.jpg 2000w">

Molti pensano che il browser “scelga quello più adatto”. In realtà, srcset da solo è soltanto un menu. Dice: ecco le dimensioni disponibili e la loro larghezza reale in pixel. Dice nulla sullo spazio che l'immagine occupa nella pagina.

Senza informazioni sulla larghezza di visualizzazione, il browser applica un valore predefinito: sizes="100vw" (vw = larghezza del viewport, la larghezza della finestra), ovvero “assumi che l'immagine occupi tutta la larghezza della finestra”. Ed è qui che tutto va storto.

La causa reale: l'attributo sizes (e la trappola della densità dello schermo)

Il calcolo che fa il browser è semplice:

Proviamo due scenari su un mobile largo 400px con schermo Retina (DPR = 2, la norma su mobile):

La conclusione che fa male: un srcset senza un sizes corretto è quasi inutile. Il browser, in caso di dubbio, sceglie un'immagine troppo grande, e PageSpeed se ne accorge.

Il DPR è il fattore che tutti dimenticano: su mobile la maggior parte degli schermi ha un DPR 2 o 3. Un'immagine mostrata a 200px fisici richiede una sorgente da 400 a 600px. Questo non è spreco; oltre quella soglia, lo è.

Il caso WordPress: il sizes predefinito spesso è sbagliato (la causa numero 1 nella pratica)

Se lei usa WordPress, è molto probabile che il problema venga da qui, e non è un sizes mancante, ma un sizes automatico e sbagliato.

WordPress genera da solo lo srcset e un sizes. Ma il valore che imposta di default è il seguente:

  sizes="(max-width: 1024px) 100vw, 1024px"

In altre parole: “questa immagine occupa tutta la larghezza del contenuto”. Questo è vero per un'immagine di articolo a piena larghezza. È sbagliato appena l'immagine si trova in una griglia, una colonna, una sidebar, una card, una galleria, che è il caso più frequente. Il risultato: il sizes dichiara una larghezza molto più grande della realtà, il browser carica un'immagine troppo grande, e PageSpeed se ne accorge.

Peggio: molti page builder (Divi, Elementor…) e i temi non adattano questo sizes alla colonna reale. Quindi lei si ritrova con uno srcset impeccabile, con varianti generate bene… e un sizes che le sabota. È la causa più frequente del reclamo “Dimensiona le immagini correttamente” su un sito WordPress, quella a cui non si pensa mai di controllare, proprio perché “ci pensa WordPress”.

Diagnosi in 30 secondi (senza tirare a indovinare)

Apra Chrome DevTools, la scheda Elements, passi il mouse sopra il tag <img>. Chrome mostra:

• Rendered size: la dimensione a cui l'immagine viene effettivamente visualizzata.
• Rendered aspect ratio e Intrinsic size: la dimensione del file scaricato.
• Current source: quale variante dello srcset è stata scelta.

Il verdetto è immediato. Se vede una rendered size di 180px ma la current source è photo-800.jpg, il suo sizes è mancante o sbagliato. Se la rendered size è 180px e la current source è photo-400.jpg, è tutto corretto: 400 = 180 × DPR 2, arrotondato allo step successivo.

Può anche usare la scheda Network: ordini per dimensione, ricarichi la pagina e osservi quale variante viene scaricata.

La correzione generica (quello che farebbe manualmente uno sviluppatore)

a. Scriva un sizes che corrisponda al suo layout reale

Questo è il cuore del problema. Il sizes deve riflettere la larghezza reale dell'immagine, quella imposta dal suo CSS, a ogni breakpoint (la larghezza dello schermo alla quale cambia il layout). Esempio per un'immagine a piena larghezza su mobile ma su 3 colonne su desktop:

  sizes="(max-width: 600px) 100vw,
         (max-width: 1024px) 50vw,
         33vw"

b. Generi le varianti giuste

Non ha senso avere una variante 2000w se la sua immagine non supera mai i 600px sullo schermo. E viceversa: fornisca gli step che coprono le sue larghezze reali × DPR (fino a 2, a volte 3).

c. Non dimentichi width e height

. Non cambiano il peso, ma prevengono il CLS (Cumulative Layout Shift, il contenuto che salta durante il caricamento), l'altro reclamo ricorrente di PageSpeed.

Il caso in cui anche un sizes perfetto non basta

Alcuni elementi non hanno alcun srcset: slider (Nivo, Swiper, molti temi), immagini di sfondo CSS, o qualsiasi markup che genera un <img src="..."> grezzo. In quel caso, non c'è letteralmente nulla da riscrivere: nessun plugin di ottimizzazione può intervenire, perché non c'è srcset/sizes da correggere. È un problema a parte (immagini senza srcset), che richiede un approccio diverso da quello descritto qui.

Perché è così doloroso mantenerlo a mano

Scrivere il sizes giusto presuppone di conoscere, per ogni immagine e ogni breakpoint, la larghezza di visualizzazione CSS reale. Su un sito vetrina di 5 pagine, è fattibile. Su un sito con decine di template, griglie che cambiano, contenuti editoriali… diventa ingestibile, e si disallinea a ogni redesign.

In sintesi

• srcset = un menu di dimensioni. sizes = l'istruzione di scelta. Senza quest'ultimo, il primo è quasi inutile.
• Il DPR mobile (×2, ×3) raddoppia o triplica la larghezza target, da cui il download eccessivo.
• Diagnosi con Rendered size vs Current source negli strumenti DevTools.
• La correzione = un sizes fedele al suo layout reale + le varianti giuste. A mano è tedioso e fragile; misurato e automatizzato, è affidabile.