Correggere 'Defer Offscreen Images': Guida al Lazy Loading per i Core Web Vitals

Cos'è 'defer offscreen images'?

L'avviso defer offscreen images era un audit di Lighthouse che segnalava le pagine con immagini che potevano essere caricate con il lazy load. Lighthouse segnalava le immagini che soddisfacevano tutti questi criteri:

• L'immagine termina sotto 3 volte l'altezza della viewport.
  Quando un'immagine non è caricata con lazy load e termina al di sotto di 3 volte l'altezza della parte visibile della pagina, e inizia al di sotto della parte visibile della pagina.
• L'immagine è più grande di 0,02 MB o impiega più di 50 ms per caricarsi.
  Le immagini piccole o incorporate (inlined) vengono ignorate. Gli script di lazy loading usano spesso piccole immagini segnaposto (placeholder) che scendono al di sotto di questa soglia.
• L'immagine non ha alcun attributo di caricamento (loading) definito.
  Lighthouse ignora le immagini che hanno l'attributo loading="lazy" o loading="eager".

Questo audit è stato rimosso in Lighthouse 13

A partire da Lighthouse 13 (ottobre 2025), questo audit è stato completamente rimosso. Il team di Chrome ha stabilito che i browser moderni già depriorizzano le immagini fuori schermo, quindi l'audit generava più rumore che feedback utili.

Ma ecco il punto: l'ottimizzazione in sé è ancora importante. Il lazy loading delle immagini fuori schermo riduce la larghezza di banda, libera connessioni di rete per le risorse critiche e migliora il tuo Largest Contentful Paint (LCP). Il fatto che Lighthouse non lo segnali più significa che devi verificarlo tu stesso. Usa il Real User Monitoring o fai un audit manuale delle tue pagine per le immagini che si caricano senza loading="lazy".

Un rapido promemoria: cos'è il lazy loading?

Lazy loading significa che le immagini non nella parte visibile della pagina vengono caricate in un secondo momento, di solito appena prima di scorrere nella vista. Il browser recupera l'immagine solo quando l'utente le si avvicina. Questo fa risparmiare larghezza di banda e consente al browser di concentrarsi sulle risorse che contano davvero per il rendering iniziale.

Cosa causa le immagini fuori schermo caricate in modo eager?

Le immagini non sono differite di default. Le immagini fuori schermo che non sono differite finiscono sulla pagina perché manca l'attributo loading o l'immagine non è gestita da una libreria di lazy loading. Cause comuni:

• Plugin mal codificati nel tuo CMS.
• Plugin che disabilitano il lazy loading nativo.
• Immagini di sfondo (Background images) (queste necessitano di un approccio diverso rispetto a loading="lazy").
• Page builder che generano HTML scadente (ad esempio: Elementor o WP Bakery).
• Testo che viene copiato e incollato in un editor WYSIWYG (come TinyMCE).
• Cattiva codifica dei template.

In che modo le immagini fuori schermo influenzano i tuoi Core Web Vitals?

Le immagini fuori schermo non influiscono direttamente sulle metriche di Lighthouse. Ma rendono il rendering di una pagina web inutilmente complicato. Il tuo browser dovrà scaricare più risorse prima che la pagina possa essere visualizzata sullo schermo. Ci sono 3 problemi con le immagini fuori schermo caricate in modo eager:

• Più download prima del rendering. Il tuo browser dovrà scaricare immagini che l'utente non può ancora nemmeno vedere.
• Le risorse critiche vengono depriorizzate. Le immagini competono per la larghezza di banda con risorse che sono effettivamente necessarie per il rendering, come il tuo CSS e la tua immagine LCP.
• Maggiore utilizzo della memoria. La decodifica delle immagini su cui l'utente non ha ancora scorso spreca memoria, specialmente sui dispositivi mobili di fascia bassa.

Secondo il capitolo Page Weight del Web Almanac 2025, la pagina mobile mediana carica 15 immagini. Al 90° percentile, quel numero salta a 52. Nelle pagine con molte immagini, il lazy loading di quelle fuori schermo può fare davvero la differenza. Nei siti monitorati da CoreDash, il [CD:placeholder]% delle pagine che applicano correttamente il lazy load alle immagini fuori schermo supera l'LCP, rispetto al [CD:placeholder]% delle pagine che non lo fanno.

Come risolvere 'defer offscreen images'

Per correggere le immagini fuori schermo caricate in modo eager, aggiungi loading="lazy" a ogni immagine che si trova below the fold. Il lazy loading nativo è ora supportato dal 95% dei browser a livello globale, inclusi Chrome, Firefox, Safari ed Edge. Non hai bisogno di una libreria per questo.

<img loading="lazy"
     src="image.webp"
     alt="un'immagine nativa caricata con lazy load"
     width="300" height="300">

Rintraccia le origini delle tue immagini caricate in modo eager. Controlla quali immagini si caricano senza un attributo loading e scopri cosa le sta posizionando sulla pagina. Ci sono 5 soliti sospetti:

1. Plugin mal codificati nel tuo CMS.
   Alcuni plugin aggiungono l'HTML direttamente alla pagina e non utilizzano gli hook corretti che abilitano il lazy loading.
2. Plugin che disabilitano il lazy loading nativo.
   Alcuni plugin disabilitano il lazy loading nativo per impostazione predefinita. Controlla le impostazioni del tuo plugin.
3. Page builder che generano HTML scadente.
   I page builder come Elementor o WP Bakery spesso creano codice gonfiato tutt'altro che perfetto. Non c'è una soluzione facile per questo. La soluzione include la pulizia del codice e la modifica del flusso di lavoro.
4. Testo copiato e incollato in un editor WYSIWYG.
   La maggior parte degli editor WYSIWYG come TinyMCE fa un pessimo lavoro nella pulizia del codice incollato, specialmente se incollato da un'altra fonte rich text come Microsoft Word. Questi editor potrebbero non aggiungere il lazy loading alle tue immagini.
5. Cattiva codifica dei template.
   Anche quando il lazy loading è abilitato, le immagini hardcoded nei tuoi template potrebbero non essere caricate in modo lazy. Controlla i tuoi template per le immagini fuori schermo e applica loro il lazy load.

Non applicare il lazy load alla tua immagine LCP

Questa è la regola più importante del lazy loading: non applicare mai loading="lazy" alla tua immagine di Largest Contentful Paint. L'immagine LCP è quasi sempre l'immagine hero o l'elemento visibile più grande nella viewport. Secondo il Web Almanac 2025, il 16% delle pagine mobili applica ancora il lazy load alla propria immagine LCP. Quel singolo attributo può aggiungere dai 200 ai 500 millisecondi al tuo LCP.

Invece, fai l'opposto per la tua immagine LCP. Assicurati che si carichi il più velocemente possibile con fetchpriority="high":

<img fetchpriority="high"
     loading="eager"
     src="hero.webp"
     alt="Hero image"
     width="1200" height="600">

Se hai accidentalmente caricato in modo lazy la tua immagine LCP, leggi come correggere un'immagine LCP caricata in modo lazy. Per una guida completa sull'ottimizzazione delle immagini, consulta ottimizzare le immagini per i Core Web Vitals.

Cheatsheet per il caricamento delle immagini

Non tutte le immagini dovrebbero essere trattate allo stesso modo. Ecco come gestire i 4 scenari più comuni:

Lazy loading nativo vs script di lazy loading

Usa loading="lazy" nativo. Nel 2026, non c'è motivo di aggiungere una libreria JavaScript per il lazy loading per elementi <img> standard. Il lazy loading nativo è supportato da tutti i principali browser incluso Safari (dalla versione 15.4), coprendo il 95% degli utenti a livello globale. Richiede zero JavaScript, aggiunge zero overhead e funziona out of the box.

Librerie come lazysizes erano essenziali prima che i browser supportassero il lazy loading nativo. Non sono più mantenute e non sono più necessarie per la maggior parte dei siti. Gli unici scenari in cui potresti ancora aver bisogno di una soluzione JavaScript:

• Immagini di sfondo CSS. Il lazy loading nativo funziona solo sugli elementi <img> e <iframe>. Per le immagini di sfondo hai bisogno di IntersectionObserver o content-visibility: auto.
• Soglie di caricamento personalizzate. Chrome inizia a caricare le immagini "lazy" a circa 1250px sotto la viewport su connessioni veloci e 2500px su connessioni lente. Non puoi personalizzare questa distanza. Se hai bisogno di un controllo più rigoroso, un IntersectionObserver con un rootMargin personalizzato te lo offre.

Se hai davvero bisogno di una libreria, usa vanilla-lazyload invece di lazysizes. È attivamente mantenuta, usa IntersectionObserver e supporta le immagini di sfondo.

Prevenire il layout shift sulle immagini con lazy load

Includi sempre gli attributi width e height nelle immagini con lazy load. Senza dimensioni esplicite, il browser non sa quanto spazio riservare. Quando l'immagine viene finalmente caricata, spinge il contenuto circostante verso il basso, causando un Cumulative Layout Shift (CLS). Secondo il Web Almanac 2025, il 62% delle pagine mobili ha ancora almeno un'immagine senza dimensioni.

<!-- Sbagliato: causa layout shift -->
<img loading="lazy" src="photo.webp" alt="Foto">

<!-- Giusto: le dimensioni riservano spazio -->
<img loading="lazy" src="photo.webp" alt="Foto" width="800" height="600">

Soluzioni alternative (Workaround) quando non puoi usare il lazy load

A volte non è possibile differire le immagini fuori schermo. Potresti non avere accesso al template o il tuo CMS potrebbe non supportare il lazy loading. Esistono alcune soluzioni alternative per attenuare l'impatto. Queste sono tutt'altro che perfette e potrebbero introdurre nuove sfide.

• Comprimi le tue immagini. Le immagini più piccole hanno un impatto minore sulle prestazioni di caricamento rispetto alle immagini di grandi dimensioni. Usa tecniche di compressione moderne per ridurre le dimensioni del file.
• Usa formati di immagine più veloci. Passa da PNG e JPEG a WebP o AVIF. WebP comprime a circa 1,3 bit per pixel rispetto a 2,0 per JPEG secondo il capitolo Media del Web Almanac 2024.
• Dividi le pagine di grandi dimensioni in più pagine. Dividere le pagine grandi riduce il numero di immagini che devono essere caricate in una volta.
• Implementa l'infinite scroll. L'infinite scroll è fondamentalmente il lazy loading, solo non per le immagini ma per intere parti della pagina web. Per le pagine con molti elementi ripetuti (pensa a Pinterest), l'infinite scroll può accelerare notevolmente il caricamento iniziale.

Per le considerazioni specifiche per il mobile, le immagini fuori schermo sono un problema ancora più grande perché le connessioni mobili sono più lente e le viewport dei dispositivi mobili sono più piccole, il che significa che più immagini finiscono fuori schermo.

Qualunque sia l'approccio che adotti, verifica che funzioni con utenti reali. Imposta il Real User Monitoring per tracciare se le tue modifiche migliorano effettivamente l'LCP e i Core Web Vitals complessivi sul campo (in the field).