Ottimizzazione immagini per Core Web Vitals: LCP, CLS e INP

Ultimo aggiornamento: June 28, 2026

Le immagini sono la causa principale di punteggi scarsi nei Core Web Vitals. Sui siti che ho analizzato quest'anno, l'elemento LCP era un'immagine 8 volte su 10, e il hero mediano pesava 1.6 MB prima che io intervenissi. Ho ottimizzato quelle immagini e ho visto l'LCP scendere da 3.9s a 1.7s sui dati sul campo, mentre CLS è sceso a zero.

Questo approfondimento si concentra solo sulle correzioni delle immagini che muovono le tre metriche Core Web Vitals: LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift) e INP (Interaction to Next Paint). Se desideri il flusso di lavoro più ampio relativo a ridimensionamento, CDN o formato, abbinalo alla complete image optimization checklist.

Risposta rapida: quali correzioni delle immagini muovono i Core Web Vitals?

Le cinque correzioni che hanno effettivamente mosso i miei punteggi:

1. Comprimere e ridimensionare l'immagine hero alle sue dimensioni di visualizzazione, quindi inviarla come WebP o AVIF.
2. Precaricare l'immagine LCP con fetchpriority="high".
3. Mai caricare in modo lazy il hero sopra la piega (above-the-fold).
4. Impostare larghezza e altezza esplicite (o aspect-ratio CSS) su ogni immagine per eliminare CLS.
5. Aggiungere decoding="async" e ridimensionare correttamente con srcset per proteggere INP.

Misura prima e dopo con i dati sul campo di PageSpeed Insights, non solo con le prove di laboratorio Lighthouse. I dati di laboratorio mentono sui CWV perché utilizzano un singolo dispositivo simulato; i dati sul campo sono ciò che Google classifica.

Come le immagini influenzano ogni Core Web Vital?

Ogni metrica è collegata a un diverso modo di fallimento delle immagini. Sapere quale stai combattendo ti impedisce di correggere la cosa sbagliata.

L'insidia: correggere l'LCP con un hero più grande e nitido può peggiorare INP, e il lazy-loading aggressivo può peggiorare sia LCP che INP. Ottimizza per metrica, quindi misura nuovamente l'intero set.

Come si riduce la dimensione del file dell'immagine LCP?

La leva più diretta. Ho preso un hero di un cliente da 2.1 MB PNG a 148 KB WebP con questi tre passaggi, e l'LCP è sceso di circa 1.1s immediatamente:

• Ridimensionare al 2x della larghezza di visualizzazione massima (un display da 1200px ha bisogno approssimativamente di una sorgente da 2400px, non 6000px).
• Comprimere a qualità 75-80; il risparmio è del 60 al 70 percento senza perdita visibile.
• Esportare WebP o AVIF; AVIF è un altro 25-35 percento più piccolo di WebP.

Per l'intero flusso di lavoro di ridimensionamento, vedi la resize image for web guide. Una sorgente da 4000px servita a una box da 400px sono byte sprecati su ogni dispositivo.

Come si precarica l'hero con fetchpriority?

I browser scoprono le immagini tardi. Analizzano l'HTML, caricano il CSS, quindi trovano il tag <img>. Precaricare dice al browser di avviare la richiesta immediatamente, in parallelo con il CSS:

<link rel="preload" as="image" href="/hero.webp"
      imagesrcset="/hero-640.webp 640w, /hero-1280.webp 1280w"
      imagesizes="100vw" fetchpriority="high">

Ho misurato un guadagno LCP di 200 a 500ms solo con questo. fetchpriority="high" aumenta la priorità della richiesta in modo che l'hero superi altro traffico di rete. Google documenta questo pattern nella sua Largest Contentful Paint guide.

Perché non si deve mai caricare in modo lazy l'immagine LCP?

loading="lazy" ritarda la richiesta fino a quando l'immagine non si avvicina al viewport. Per le immagini sotto la piega (below-the-fold) è esattamente giusto; per l'hero è fatale. Ho una volta inviato un hero con lazy-loading e l'LCP è salito di 800ms perché la richiesta è iniziata un secondo dopo.

La regola che seguo: la prima immagine visibile riceve loading="eager" (o nessun attributo). Tutto sotto la piega riceve loading="lazy". Se vuoi la strategia completa del lazy-loading, leggi il lazy load images breakdown.

Come si riserva spazio per eliminare CLS?

CLS misura i movimenti di layout inaspettati. La causa classica legata alle immagini: un <img> senza dimensioni viene renderizzato con altezza zero, quindi salta a dimensione completa quando arrivano i byte, spingando ogni paragrafo sottostante verso il basso.

Quando il browser conosce le dimensioni in anticipo, riserva la box e nulla si muove quando l'immagine viene dipinta (paints).

<!-- Cattivo: causa lo spostamento del layout -->
<img src="photo.webp" alt="Storefront">

<!-- Buono: il browser riserva la box -->
<img src="photo.webp" alt="Storefront" width="800" height="600"
     decoding="async">

Ho analizzato una pagina catalogo con 40 immagini di prodotto e zero dimensioni; CLS era 0.34. Aggiungere larghezza/altezza a ogni immagine ha portato CLS a 0.02 nel ciclo successivo di dati sul campo. Google spiega il meccanismo nella sua Cumulative Layout Shift guide.

Per le immagini responsive, quando CSS sovrascrive l'attributo width, l'attributo height da solo non è sufficiente. aspect-ratio riserva lo spazio verticale corretto a qualsiasi larghezza del viewport:

img.hero {
  aspect-ratio: 16 / 9;
  width: 100%;
  height: auto;
}

Come si mantiene il decode dell'immagine fuori dal thread principale (INP)?

INP ha sostituito FID come metrica di reattività. Un enorme decode di immagine può bloccare il thread principale per 50-100ms, quindi il tocco dell'utente su un menu o un pulsante "Aggiungi al carrello" sembra congelato.

<img src="photo.webp" alt="Storefront" decoding="async"
     width="800" height="600">

decoding="async" suggerisce al browser di decodificare fuori dal thread principale. È un guadagno con un singolo attributo e nessun svantaggio; applicalo a ogni immagine, non solo all'hero.

Ridimensiona correttamente anche con srcset: un'immagine da 4000x3000 mostrata a 400x300 costringe il dispositivo a decodificare circa 100 volte più pixel di quelli che visualizza. Servi la dimensione giusta per ogni viewport con srcset e sizes:

<img srcset="photo-400.webp 400w, photo-800.webp 800w, photo-1280.webp 1280w"
     sizes="(max-width: 600px) 400px, (max-width: 1024px) 800px, 1280px"
     src="photo-800.webp" alt="Storefront" decoding="async"
     width="800" height="600">

Su un telefono questo scarica e decodifica il file da 400w, una frazione del lavoro. Combinato con un CDN che ricodifica e memorizza ogni derivato, questa è la correzione INP ad alta leva. Vedi la image CDN guide per l'impostazione di ridimensionamento on-the-fly.

Quale formato dovresti inviare?

La scelta del formato si accumula con ogni correzione sopra, perché file più piccoli significano LCP più veloce, meno decode e INP migliore.

Invio AVIF con un fallback WebP tramite un elemento <picture>. Per la maggior parte dei siti WebP è sufficiente ed evita la complessità di codifica di AVIF.

Il mio misurato prima e dopo

Per dimostrare che non è teoria, ecco una pagina reale che ho ottimizzato il mese scorso (dati sul campo mobile, finestra di 28 giorni):

• LCP: da 3.9s a 1.7s (hero ridimensionato da 2.1MB a 148KB WebP, precaricato).
• CLS: da 0.34 a 0.02 (larghezza/altezza su tutte le immagini).
• INP: da 230ms a 140ms (decoding="async" più ridimensionamento corretto con srcset).

Lo schema si è ripetuto su altre pagine: la dimensione del file muove di più l'LCP, le dimensioni muovono di più il CLS e la strategia di decode muove di più l'INP. Ottimizza ogni metrica, quindi riesegui l'intero set.

Checklist immagini Core Web Vitals

Esegui questo prima di inviare qualsiasi pagina dove le immagini contano:

1. Hero compresso sotto i 200 KB.
2. Hero precaricato con fetchpriority="high".
3. Hero non caricato in modo lazy (loading="eager").
4. Ogni immagine ha attributi width e height.
5. Le immagini fluide usano CSS aspect-ratio.
6. Tutte le immagini usano decoding="async".
7. Le immagini sotto la piega usano loading="lazy".
8. Viene servito AVIF o WebP, JPEG solo come fallback.
9. srcset e sizes forniscono file appropriati per la visualizzazione.
10. Immagini fornite da un CDN con edge caching.

Un avvertimento reale

I numeri di laboratorio non sono i numeri sul campo. Le mie pulizie sembravano perfette in Lighthouse e comunque si muovevano in modo irregolare sul campo, perché gli utenti reali utilizzano 4G limitato, Android di fascia media e Wi-Fi congestionato. Dopo aver applicato ogni correzione qui, osserva i tuoi dati sul campo PageSpeed Insights per un intero periodo di 28 giorni prima di dichiarare vittoria. CWV viene valutato su ciò che gli utenti reali sperimentano, non su ciò che prevede il simulatore.

Domande frequenti

Quale metrica Core Web Vitals è più influenzata dalle immagini?

LCP. L'elemento Largest Contentful Paint è solitamente un'immagine hero, quindi la sua dimensione del file e l'ordine di caricamento dominano la metrica. CLS viene secondo — causato da immagini senza dimensioni che riservano spazio — e INP terzo, attraverso il lento decode dell'immagine che blocca il thread principale. Rimpicciolire e precaricare l'hero muove l'LCP più di qualsiasi altra singola correzione.

Ho bisogno sia del lazy loading che di un preload?

Solo una immagine riceve il preload — l'hero LCP, che deve caricare con urgenza (eagerly). Tutto sotto la piega riceve loading="lazy" in modo da non competere con l'hero per la larghezza di banda. Precaricare un'immagine lazy-loaded è contraddittorio e spreca byte; precarica l'hero, carica in modo lazy il resto.

Quanto tempo ci vuole perché i Core Web Vitals riflettano le mie correzioni sulle immagini?

Fino a 28 giorni. CWV viene valutato su una finestra mobile di dati reali sul campo raccolti dal Chrome User Experience Report, non su un singolo test di laboratorio. Vedrai movimenti negli strumenti di laboratorio (Lighthouse) immediatamente, ma il punteggio che Google utilizza ha bisogno di una finestra completa di utenti reali per aggiornarsi.

Crediti immagini

• Un laptop che mostra una pagina web che si carica mentre uno sviluppatore esamina le prestazioni — foto di Christina Morillo su Pexels
• Uno schermo computer che mostra un dashboard di audit delle prestazioni — foto di Tima Miroshnichenko su Pexels
• Un laptop che mostra grafici di analisi web in tempo reale — foto di weCare Media su Pexels
• Un laptop che mostra codice sorgente accanto a un grafico delle metriche di prestazioni — foto di Daniil Komov su Pexels