Risolvere '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 in modalità lazy. Lighthouse segnalava le immagini che soddisfacevano tutti questi criteri:

• L'immagine termina al di sotto di 3 volte l'altezza del viewport.
  Quando un'immagine non è in lazy loading 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 50ms per caricarsi.
  Le immagini piccole o inline vengono ignorate. Gli script di lazy loading usano spesso piccole immagini segnaposto che rientrano al di sotto di questa soglia.
• L'immagine non ha alcun attributo 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 deprioritizzano già le immagini fuori schermo, quindi l'audit generava più rumore che feedback utile.

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

Un rapido promemoria: cos'è il lazy loading?

Il lazy loading significa che le immagini non presenti nella parte visibile della pagina vengono caricate in un momento successivo, di solito appena prima di scorrere nella visuale. Il browser recupera l'immagine solo quando l'utente si avvicina ad essa. Questo fa risparmiare larghezza di banda e permette al browser di concentrarsi sulle risorse che contano davvero per il render iniziale.

Cosa causa il caricamento eager delle immagini fuori schermo?

Le immagini non vengono posticipate per impostazione predefinita. Le immagini fuori schermo che non vengono posticipate finiscono sulla pagina perché manca l'attributo loading o l'immagine non è gestita da una libreria di lazy loading. Cause comuni:

• Plugin mal programmati nel tuo CMS.
• Plugin che disabilitano il lazy loading nativo.
• Immagini di sfondo (queste necessitano di un approccio diverso rispetto a loading="lazy").
• Page builder che generano codice HTML scadente (ad esempio: Elementor o WP Bakery).
• Testo copiato e incollato in un editor WYSIWYG (come TinyMCE).
• Codifica scadente del 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 mostrata sullo schermo. Ci sono 3 problemi con le immagini fuori schermo caricate in modalità eager:

• Più download prima del rendering. Il tuo browser dovrà scaricare immagini che l'utente non può ancora nemmeno vedere.
• Le risorse critiche vengono deprioritizzate. Le immagini competono per la larghezza di banda con le risorse che sono effettivamente necessarie per il rendering, come il tuo CSS e la tua immagine LCP.
• Maggiore utilizzo della memoria. La decodifica di immagini a cui l'utente non è ancora arrivato 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, questo numero salta a 52. Sulle pagine ricche di immagini, il lazy loading di quelle fuori schermo può fare una vera differenza. Tra i siti monitorati da CoreDash, il 76% delle pagine che applicano correttamente il lazy loading alle immagini fuori schermo supera il test LCP, rispetto al 59% delle pagine che non lo fanno.

Come risolvere 'defer offscreen images'

Per correggere le immagini fuori schermo caricate in modalità 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="a native lazy loaded image"
     width="300" height="300">

Traccia le origini delle tue immagini caricate in modalità eager. Controlla quali immagini si caricano senza un attributo loading e scopri cosa le sta inserendo nella pagina. Ci sono 5 soliti sospetti:

1. Plugin mal programmati nel tuo CMS.
   Alcuni plugin aggiungono codice 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 dei tuoi plugin.
3. Page builder che generano codice HTML scadente.
   I page builder come Elementor o WP Bakery spesso creano codice inutilmente pesante che è tutt'altro che perfetto. Non esiste una soluzione semplice per questo. La soluzione include la pulizia del codice e la modifica del tuo flusso di lavoro.
4. Testo copiato e incollato in un editor WYSIWYG.
   La maggior parte degli editor WYSIWYG come TinyMCE fa un pessimo lavoro nel ripulire il codice incollato, specialmente quando viene incollato da un'altra fonte di testo ricco come Microsoft Word. Questi editor potrebbero non aggiungere il lazy loading alle tue immagini.
5. Codifica scadente del template.
   Anche quando il lazy loading è abilitato, le immagini hardcoded nei tuoi template potrebbero comunque non essere in lazy loading. Controlla i tuoi template alla ricerca di immagini fuori schermo e applica il lazy loading.

Non applicare il lazy loading alla tua immagine LCP

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

Fai invece 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 applicato il lazy loading alla 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 di lazy loading per gli 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ù manutenute 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 il viewport su connessioni veloci e 2500px su connessioni lente. Non puoi personalizzare questa distanza. Se hai bisogno di un controllo più stretto, un IntersectionObserver con un rootMargin personalizzato te lo permette.

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

Previeni i layout shift sulle immagini in lazy loading

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

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

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

Soluzioni alternative quando non puoi usare il lazy loading

A volte non è possibile posticipare le immagini fuori schermo. Potresti non avere accesso al template o il tuo CMS potrebbe non supportare il lazy loading. Ci sono alcune soluzioni alternative per ridurre 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 moderne tecniche di compressione per ridurre la dimensione del file.
• Usa formati di immagine più veloci. Passa da PNG e JPEG a WebP o AVIF. WebP si 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 di grandi dimensioni riduce il numero di immagini che devono essere caricate contemporaneamente.
• Implementa lo scroll infinito. L'infinite scroll è fondamentalmente un lazy loading, solo che non si applica alle immagini ma a 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 i dispositivi mobili, le immagini fuori schermo sono un problema ancora più grande perché le connessioni mobili sono più lente e i viewport mobili sono più piccoli, il che significa che più immagini finiscono fuori schermo.

Qualsiasi approccio tu scelga, verifica che funzioni con utenti reali. Configura il Real User Monitoring per tracciare se le tue modifiche migliorano effettivamente l'LCP e i Core Web Vitals complessivi sul campo.