What is the native, no-JavaScript way to lazy-load an image or iframe?

The loading="lazy" HTML attribute on and

A defer="true" attribute on the tag

The rel="lazy" attribute on a tag

A JavaScript scroll-event listener is always required

What is the single most damaging lazy-loading mistake for Core Web Vitals?

Lazy-loading the hero / LCP image above the fold

Setting width and height on a lazy image

Using loading="lazy" on an off-screen iframe

Why can content gated behind a scroll or click event go unseen by Google?

Googlebot renders pages but does not scroll or click, so those events never fire

Googlebot blocks all JavaScript by default

Google only crawls the first 2 MB of any page

Scroll-triggered content is banned by Google's guidelines

How do you verify Google can see your lazy-loaded images?

Confirm the image URLs appear in the src attribute of the rendered HTML in Search Console's URL Inspection Tool

Check that the page has no JavaScript at all

Count the images in the raw HTML source before rendering

Lazy loading e SEO

TL;DR — Il lazy loading dice al browser di rimandare il download di immagini e contenuti incorporati finché non stanno per entrare nell’area visibile, così la pagina si carica più velocemente all’inizio. Il modo semplice, senza codice, è aggiungere loading="lazy" a un <img> o <iframe>. L’unica regola da ricordare: non applicare il lazy loading all’immagine grande in cima alla pagina — questo rende la pagina più lenta, non più veloce.

Cos’è il lazy loading

Normalmente, quando un browser apre una pagina, cerca di scaricare tutto ciò che contiene — ogni immagine, ogni mappa o video incorporato — subito. Su una pagina lunga con molte immagini, significa scaricare molti dati per elementi che potresti non raggiungere mai.

Il caricamento differito risolve questo problema. Rimanda immagini e contenuti incorporati fuori schermo finché non stanno per entrare nell’area visibile. La pagina mostra rapidamente ciò che è in cima, e il resto si carica man mano che procedi. Meno dati all’inizio significa una prima impressione più veloce, più risparmi su larghezza di banda e batteria — ciò che conta di più sui telefoni.

Il modo semplice: l’attributo `loading`

Prima serviva una libreria JavaScript per fare questo. Non più. I browser moderni lo hanno integrato. Devi solo aggiungere un attributo:

<img src="photo.jpg" loading="lazy" alt="…">

Tutto qui. Funziona su <img> e <iframe> (pensa a video YouTube incorporati, Google Maps, widget social) in tutti i browser principali, senza JavaScript.

L’unico errore da evitare

Non applicare il caricamento differito all’immagine grande in cima alla pagina — l’immagine principale, la prima cosa che le persone vedono. Il caricamento differito dice al browser “questo può aspettare”, quindi un’immagine in cima caricata in modo differito arriva più tardi di quanto dovrebbe e la pagina sembra più lenta. Le linee guida di Google stesse dicono di saltare il lazy loading per qualsiasi cosa visibile subito all’apertura della pagina.

In breve: applica il lazy loading alle cose sotto la piega, carica normalmente le cose sopra la piega.

Danneggia la SEO?

Da solo, no. Google può indicizzare immagini e contenuti con lazy loading senza problemi quando è fatto nel modo normale. I problemi iniziano solo quando una pagina nasconde contenuti dietro lo scorrimento o il clic — perché i motori di ricerca non scorrono né cliccano. Se le tue immagini usano solo loading="lazy", sei a posto. Vuoi i dettagli su come Google vede realmente questo, e come verificarlo? Passa alla scheda Avanzate.

TL;DR — Il caricamento differito rimanda immagini e iframe fuori schermo finché non si avvicinano alla viewport, riducendo il peso iniziale della pagina (aiuta LCP) e il lavoro sul thread principale all’avvio (aiuta INP). L’attributo nativo loading="lazy" su <img>/<iframe> ha sostituito la maggior parte delle librerie JS; solo lazy e eager sono valori significativi (auto è deprecato). Gli errori dannosi sono applicare il caricamento differito all’immagine LCP subito visibile (ritarda proprio la metrica che stai cercando di migliorare) e nascondere contenuti dietro scorrimento/clic — che Googlebot non attiva mai perché non interagisce con la pagina. Non è un fattore di ranking diretto; l’effetto passa attraverso Core Web Vitals e la possibilità di scansione. Verifica nello strumento Controllo URL di Search Console che gli URL delle immagini finiscano nell’attributo src dell’HTML renderizzato.

Cosa fa realmente il lazy loading

L’idea è semplice: caricare le risorse solo quando servono, invece di caricare tutto in una volta. Su una pagina ricca di media, scaricare ogni immagine e contenuto incorporato all’inizio mantiene il browser occupato a recuperare cose che il visitatore potrebbe non scorrere mai — bruciando larghezza di banda, memoria e batteria per nulla. Rimandare quelli fuori schermo permette al contenuto subito visibile di apparire prima. Martin Splitt ha spiegato proprio questo nel episodio “Lazy loading demystified” del podcast ufficiale di Google: l’obiettivo è evitare lavoro che non produce nulla, perché le immagini non critiche di cui la pagina potrebbe fare a meno tengono semplicemente occupato il browser.

Questo si collega alle Core Web Vitals che la maggior parte delle persone insegue. Meno byte in competizione per la rete all’inizio significa che l’elemento Largest Contentful Paint può essere renderizzato prima. Per gli iframe — annunci, widget social, sezioni commenti, mappe — rimandarli riduce anche il lavoro sul thread principale durante l’avvio, il che è un vantaggio per Interaction to Next Paint, non solo per LCP. La guida web.dev di Google presenta gli iframe caricati in modo differito come un miglioramento INP durante il caricamento della pagina.

Lazy loading nativo vs. guidato da JavaScript

Qualche anno fa, i browser hanno acquisito un attributo loading nativo per immagini e iframe, così puoi affidare l’intero compito al browser invece di configurare un’API JavaScript. In la mia guida SEO JavaScript su Ahrefs faccio la stessa osservazione: da quando ho scritto quel pezzo, il lazy loading si è spostato per lo più dall’essere guidato da JavaScript all’essere gestito dai browser. Incontrerai ancora configurazioni guidate da JS, e per le immagini di solito vanno bene — la cosa che controllo è se il contenuto effettivo (non solo le immagini) viene caricato in modo lazy, perché quelle configurazioni sono quelle che hanno causato il mancato recupero corretto del contenuto.

La versione nativa:

<!-- Below-the-fold image: defer it -->
<img src="gallery-07.jpg" loading="lazy" width="800" height="600" alt="…">

<!-- Off-screen embed: defer it -->
<iframe src="https://www.youtube.com/embed/…" loading="lazy" title="…"></iframe>

Imposta sempre width/height espliciti (o un rapporto d’aspetto) sulle immagini differite così il browser riserva lo spazio prima che l’immagine venga caricata — questo è il rischio più grande di layout shift con immagini differite. Le dimensioni riservate non sono una garanzia assoluta di CLS, però: se il layout circostante o un ritaglio adattivo cambia ancora dopo il caricamento dell’immagine, puoi osservare comunque uno spostamento; conferma quindi con una traccia reale degli spostamenti di layout invece di presumere che le dimensioni fisse da sole lo risolvano.

Il lazy loading e gli iframe richiedono un’ulteriore distinzione: loading="lazy" su un <iframe> differisce solo per il momento in cui avvengono il recupero e la creazione del contenuto incorporato. Non imposta il suo title, il comportamento del focus, sandbox, allow o la politica delle autorizzazioni, referrerpolicy, la gestione del consenso o le dimensioni: questi aspetti richiedono ancora attenzione, e un contenuto incorporato può continuare a fare lavoro (script, pixel di tracciamento, layout) una volta che diventa idoneo al caricamento. E non dare per scontato che un elemento fuori dalla prima schermata si comporti allo stesso modo ovunque: contenuti con display: none, diapositive di carosello fuori schermo, elementi trasformati e contenitori di scorrimento annidati possono intersecare la viewport in modo diverso rispetto a un semplice elemento più in basso nella pagina, quindi testa il layout effettivo e i controlli di navigazione piuttosto che assumere equivalenza.

I valori dell’attributo `loading`

Solo due valori contano oggi:

loading="lazy" — rimanda la risorsa finché non è vicina al viewport.
loading="eager" — caricala immediatamente, il comportamento predefinito. Usalo per essere esplicito sulle immagini nella prima schermata.

Potresti vedere loading="auto" in articoli più vecchi — è deprecato in Chrome, quindi non usarlo. Non ce n’è bisogno; omettere l’attributo ti dà già il comportamento predefinito, cioè immediato.

Quanto è vicino “vicino”? loading="lazy" è un suggerimento, non una garanzia controllata dall’autore — la specifica lascia la decisione effettiva sulla vicinanza al viewport al browser. Chromium cerca di recuperare una risorsa lazy abbastanza presto da essere pronta quando scorri fino ad essa, e la distanza di attivazione varia in base al browser, alla velocità di connessione e al tipo di risorsa; non è un valore fisso in pixel su cui puoi fare affidamento o riprodurre tra browser o versioni. Non pubblicare — o fidarti — di un numero specifico “carica N pixel prima del viewport”; tratta la finestra vicino al viewport come definita dall’implementazione e conferma il comportamento effettivo con una traccia di rete sul browser/connessione che ti interessa invece di assumere una costante.

Il lazy loading nativo funziona bene anche con le immagini responsive: si applica alla normale selezione di src e srcset/sizes, quindi non perdi il comportamento delle immagini responsive aggiungendo loading="lazy". Se invece nascondi l’URL reale solo in un attributo data-* per farlo sostituire da uno script in seguito, il caricamento ora dipende da quello script — verifica l’HTML renderizzato e cosa succede se lo script fallisce (ne parleremo nelle schede Script e Risoluzione dei problemi).

L’errore n. 1: caricamento differito dell’immagine LCP subito visibile

Questo è l’errore che vedo più spesso, e tutte le fonti concordano. Se carichi in modo differito l’immagine principale — o qualsiasi immagine che probabilmente è l’elemento LCP — hai detto al browser di aspettare il pixel più importante per la velocità di caricamento percepita. Inoltre, il browser non può differire un’immagine finché non sa dove si troverà nella pagina, quindi le immagini subito visibili caricate in questo modo tendono ad arrivare più lentamente di quelle caricate subito. Questo ritarda direttamente Largest Contentful Paint, la metrica che secondo Google dovrebbe completarsi entro i primi 2,5 secondi dal caricamento.

Do not lazy-load the observed or likely LCP image; confirm the actual request and paint timing in a trace. Fonte: Lazy Loading

The eager path discovers the likely LCP image in HTML and starts its request promptly. The lazy path waits for browser loading heuristics before request start. The comparison uses no fixed timing values and notes that actual LCP must be measured.

Splitt ha detto chiaramente il lato opposto nell’episodio SOTR: se non usi il lazy loading dove dovresti, probabilmente danneggerai qualche aspetto dei Core Web Vitals — molto probabilmente l’LCP. Quindi è un’arma a doppio taglio. La regola:

Candidato LCP probabile o osservato → carica subito (ometti loading="lazy", oppure imposta eager). Considera fetchpriority="high" sull’immagine LCP.
Sotto la piega → loading="lazy".

Non tutte le immagini nella prima schermata sono il candidato LCP: identifica quella effettiva (una traccia Performance o PageSpeed Insights la nominerà) e verifica i suoi tempi di richiesta invece di trattarle tutte allo stesso modo. Sono suggerimenti separati, non un’unica impostazione: loading="eager" (o l’assenza di loading) significa solo che il browser non rimanderà la scoperta della risorsa; non ne aumenta da solo la priorità di recupero. fetchpriority è un suggerimento distinto e aggiuntivo. Sovrapporre un <link rel="preload"> a loading="lazy" sulla stessa risorsa comunica al browser intenzioni contrastanti; controlla quindi la sequenza effettiva delle richieste invece di presumere che la combinazione funzioni come previsto.

L’anti-pattern generalizzato è attivare il lazy loading per ogni immagine a livello di sito — un’impostazione predefinita comune nei CMS. Come ha notato Splitt, se ogni immagine è in lazy loading, anche le immagini che sono (o dovrebbero essere) immediatamente visibili vengono caricate in lazy loading, che è esattamente il caso che vuoi evitare.

Come Googlebot renderizza i contenuti in lazy loading

Ecco la realtà della scansione che mette in difficoltà le persone: Googlebot non scorre e non clicca. Renderizza la tua pagina con un browser headless, ma non simula un utente che interagisce con essa. Google lo afferma direttamente — i suoi metodi consigliati per il lazy loading non si basano deliberatamente su azioni dell’utente come lo scorrimento o il clic, perché Google Search non interagisce con la tua pagina.

Ecco perché il come della tua implementazione conta. Il documento di Google elenca tre implementazioni che considera sicure: il lazy loading integrato del browser per immagini e iframe, l’API IntersectionObserver (con un polyfill) o una libreria JavaScript che carica i dati quando entrano nel viewport. Tutte e tre si basano sull’intersezione con il viewport — non su un evento di scorrimento o clic che Googlebot non attiverà mai.

Il pattern ad alto rischio è una libreria JS di lazy loading personalizzata o di terze parti. Se la libreria si comporta male e l’URL dell’immagine non arriva mai nell’attributo src, Google semplicemente non raccoglierà quell’immagine — Splitt ha descritto esattamente questa modalità di errore nell’episodio SOTR. Non c’è nulla da indicizzare se l’URL non è presente. Questo è lo stesso problema che segnalo nella mia guida SEO JavaScript: il lazy loading delle immagini di solito va bene, ma il contenuto caricato in lazy loading è dove si insinuano i problemi di indicizzazione, e la soluzione è controllare ciò che Google effettivamente renderizza.

Lo scroll infinito è un problema diverso

Non confondere il lazy loading di base di immagini/iframe con lo scroll infinito o il caricamento paginato. Rimandare le immagini è una cosa; caricare nuovi blocchi di contenuto mentre l’utente scorre è un’altra, e richiede una propria architettura. La guida di Google: assegna a ogni blocco un URL persistente e univoco, mantieni il contenuto stabile per URL (usa numeri di pagina assoluti come ?page=12, non valori relativi come ?date=yesterday), e aggiorna l’URL visualizzato con la History API man mano che ogni blocco diventa il contenuto visibile principale così può essere aggiornato, condiviso e collegato. Se salti questo passaggio, il contenuto più profondo dietro uno scroll infinito potrebbe non essere mai indicizzato o scansionato in modo affidabile.

Come testarlo

Il percorso di verifica è lo stesso nel documento di Google e nella mia metodologia: usa lo Strumento di controllo URL di Search Console e guarda l’HTML renderizzato. Se i tuoi URL di immagini (o video) compaiono nell’attributo src sugli elementi <img>/<video> in quell’HTML renderizzato, la tua configurazione funziona. Google lo dice chiaramente: “Check the rendered HTML to make sure your content is in the rendered HTML” (traduzione) «Controlla l’HTML renderizzato per assicurarti che il contenuto sia presente nell’HTML renderizzato». Consulta il passaggio originale. Se l’URL manca da src, questo è il tuo problema, e di solito riconduce a un evento di scorrimento o clic oppure a una libreria non funzionante.

Per una griglia di prodotti con lazy loading, vai oltre questo controllo di presenza. Esegui la matrice di test SEO per lo scroll infinito con viewport standard e alte, navigazione fresca e ridimensionamento dopo il caricamento, esecuzioni senza azione e con scroll incrementale, conteggi di link di prodotto univoci e ispezione dell’albero di accessibilità. Ridimensionare una pagina inizializzata non equivale a navigare alla dimensione finale della viewport perché observer e calcoli batch potrebbero essere registrati solo durante l’avvio. Evidence for this claim Google Search does not scroll or click to trigger lazy-loaded content, so implementations should not depend on user interaction and should expose resource URLs in rendered HTML. Scope: Google Search guidance for JavaScript-driven lazy loading. Confidence: high · Verified: 2026-07-14 Google Search Central: Lazy-load content

Puoi anche affidarti ai tuoi strumenti di performance web: PageSpeed Insights segnala le immagini fuori schermo che dovresti rimandare. Nella mia guida PageSpeed Insights su Ahrefs noto che l’audit “defer offscreen elements” ti sta dicendo di caricare le immagini in lazy loading — un modo pratico per collegare la diagnostica che già esegui alla soluzione.

Onestà sul segnale di ranking

Sii chiaro su cosa è e cosa non è il lazy loading. Usarlo non è un fattore di ranking diretto, e non usarlo non è una penalità. La connessione al ranking è indiretta: passa tramite i Core Web Vitals (principalmente LCP, a volte INP per gli iframe) e tramite la scansionabilità, se una cattiva implementazione nasconde contenuti. Splitt ha caratterizzato l’effetto sul ranking tramite i Core Web Vitals come un fattore minuscolo e minimo nella maggior parte dei casi. Quindi ottimizza il lazy loading per l’esperienza di caricamento dei tuoi utenti e per un’indicizzazione pulita — non perché ti aspetti un aumento del ranking dall’attributo stesso.

Dove si colloca

Il lazy loading è una leva nel più ampio toolkit di performance web. Si abbina a resource hints (preload/preconnect per le risorse che vuoi in anticipo), alla strategia di font-loading, alla caching e a una CDN — ed è giudicato, in definitiva, tramite i Core Web Vitals. Ottieni la giusta suddivisione sopra/sotto la piega ed è una delle vittorie più economiche disponibili.

Riepilogo AI

Una sintesi della versione Advanced:

Lazy loading rimanda le immagini e gli iframe fuori schermo finché non si avvicinano al viewport, riducendo il peso iniziale della pagina e il lavoro di avvio. Il modo nativo, senza JS, è loading="lazy" su <img> e <iframe>; ha in gran parte sostituito le librerie JS. È un suggerimento del browser, non una distanza o un tempo garantito — il punto di attivazione varia in base al browser, alla connessione e al tipo di risorsa, quindi non fare affidamento su un numero fisso di pixel.
Valori: contano solo lazy ed eager. auto è deprecato in Chrome.
Collegamento ai Core Web Vitals: meno byte iniziali aiutano LCP; rimandare gli iframe riduce il lavoro sul thread principale all’avvio, aiutando INP. Imposta width/height in modo che le immagini rimandate non causino CLS — anche se le dimensioni riservate da sole non garantiscono zero spostamenti se il layout circostante cambia comunque.
Errore #1: lazy loading dell’immagine LCP probabile/osservata, non solo di qualsiasi immagine sopra la piega. Ritarda la Largest Contentful Paint, che Google dice dovrebbe risolversi entro 2,5 s. eager/omettere loading influisce solo sulla scoperta — non aumenta di per sé la priorità di fetch; fetchpriority è un suggerimento separato, e impilare preload con loading="lazy" sulla stessa risorsa è in conflitto. Il lazy loading generalizzato su tutto il sito è l’anti-pattern comune dei CMS.
Gli iframe hanno il loro contratto: loading="lazy" rimanda solo i tempi di fetch/creazione — title, sandbox, permissions policy, referrer policy, consenso e dimensioni devono comunque essere impostati in modo indipendente, e i layout nascosti/carosello/trasformati possono intersecare il viewport in modo diverso rispetto a un semplice elemento sotto la piega.
Googlebot non scorre né fa clic. Qualsiasi contenuto subordinato a questi eventi può non essere visto. I metodi sicuri di Google — caricamento differito nativo, IntersectionObserver o una libreria JS ben funzionante — si basano tutti sull’intersezione con la viewport.
Rischio più alto: librerie JS di lazy loading personalizzate/di terze parti. Se l’URL non finisce mai in src, Google non indicizzerà l’immagine (secondo Martin Splitt).
Lo scroll infinito è distinto: richiede URL paginati unici + History API.
Verifica in Search Console URL Inspection → HTML renderizzato → URL delle immagini presenti nell’attributo src.
Non è un fattore di ranking diretto. L’effetto è indiretto, attraverso Core Web Vitals e possibilità di scansione, e Splitt ha definito minimo l’effetto dei Core Web Vitals sul ranking.

Documentazione ufficiale

Linee guida dalle fonti primarie dei motori di ricerca e da web.dev di Google.

Google — Search Central

Correggere i contenuti caricati in modo differito — il documento definitivo: metodi di implementazione sicuri, la regola “Google non interagisce con la tua pagina”, i requisiti per scroll infinito e caricamento paginato e come verificare l’HTML renderizzato.
Comprendere le nozioni di base della SEO JavaScript — raccomanda il caricamento differito delle immagini come buona pratica per larghezza di banda e prestazioni e rimanda alla guida dedicata.
Core Web Vitals — perché il lazy loading dell’elemento LCP è controproducente (l’obiettivo LCP è 2,5 s).

Google — web.dev (Imparare le prestazioni)

Caricare in modo differito immagini ed elementi <iframe> — quando rimandare le risorse e il beneficio per INP degli iframe differiti.
Caricamento differito nativo delle immagini sul web — l’attributo nativo e perché non applicarlo alle immagini nella viewport o all’elemento LCP.
È il momento di differire gli iframe fuori schermo — il caso specifico degli iframe, come annunci, widget e mappe.
Caricamento differito nativo per i CMS — linee guida per le piattaforme CMS.

Podcast ufficiale

Episodio 98: il caricamento differito spiegato (21 ago 2025) — John Mueller e Martin Splitt ne parlano nel programma Search Off the Record, affrontando rendering, indicizzazione e Core Web Vitals. L’episodio è indicizzato anche nella pagina del podcast di Google.

Riferimento per sviluppatori (non specifico per SEO, ma autorevole sull’API)

Bing / Microsoft

Bing non pubblica un documento dedicato al lazy loading. Le sue Linee guida generali per i webmaster coprono in generale la scansione e il rendering JS. Bingbot esegue il rendering con un browser headless basato su Chromium e, come Googlebot, non scorre né fa clic — quindi lo stesso approccio nativo loading="lazy" / IntersectionObserver che soddisfa Google dovrebbe soddisfare anche Bing. Quest’ultimo punto è un’inferenza dal comportamento generale di rendering di Bingbot, non una dichiarazione Bing documentata sul lazy loading — trattalo di conseguenza.

Citazioni dalla fonte

Dichiarazioni ufficiali dalla documentazione di Google. Ogni collegamento è un collegamento profondo che salta al passaggio citato nella pagina di origine.

Google — Search Central, “Fix Lazy-Loaded Website Content”

“Deferring loading of non-critical or non-visible content, also commonly known as ‘lazy-loading’, is a common performance and UX best practice.” (traduzione) «Rimandare il caricamento di contenuti non critici o non visibili, noto anche come ‘lazy-loading’, è una pratica comune di performance e UX.» Vai alla citazione
“However, if not implemented correctly, this technique can inadvertently hide content from Google. This document explains how to make sure Google can crawl and index lazy-loaded content.” (traduzione) «Tuttavia, se non implementata correttamente, questa tecnica può nascondere involontariamente contenuti a Google. Questo documento spiega come assicurarsi che Google possa scansionare e indicizzare contenuti caricati in modo lazy.» Vai alla citazione
“The methods mentioned don’t rely on user actions, such as scrolling or clicking, to load content, which is important as Google Search does not interact with your page.” (traduzione) «I metodi menzionati non si basano su azioni dell’utente, come lo scorrimento o il clic, per caricare i contenuti, il che è importante perché Google Search non interagisce con la tua pagina.» Vai alla citazione
“Don’t add lazy-loading to content that is likely to be immediately visible when a user opens a page. That might cause content to take longer to load and show up in the browser, which will be very noticeable to the user.” (traduzione) «Non aggiungere lazy-loading a contenuti che probabilmente saranno immediatamente visibili quando un utente apre una pagina. Ciò potrebbe far sì che i contenuti impieghino più tempo a caricarsi e a comparire nel browser, il che sarà molto evidente per l’utente.» Vai alla citazione
“Give each chunk its own persistent, unique URL.” — sullo scorrimento infinito / caricamento paginato. (traduzione) «Assegna a ogni blocco il proprio URL persistente e univoco.» Vai alla citazione

Nota: l’episodio di Search Off the Record di Google “Lazy loading demystified” (ago 2025) è la fonte ufficiale più ricca su come Googlebot gestisce i contenuti differiti, ma le citazioni verbatim che circolano online sono state catturate tramite un riepilogo di terze parti. Ho parafrasato i punti di Martin Splitt nell’articolo piuttosto che citarli verbatim, in attesa di conferma rispetto alla trascrizione ufficiale.

Checklist per il lazy loading

Esegui questo prima di pubblicare una modifica al lazy loading:

Anti-pattern del lazy loading (miti ed errori)

Ciascuno di questi è una convinzione o un’abitudine comune: ecco perché è sbagliata e che cosa fare invece.

“Il caricamento differito è sempre positivo, quindi applicalo a ogni immagine.” Perché è sbagliato: applicarlo a tutto il sito include anche l’immagine principale o LCP, il che ritarda il Largest Contentful Paint — l’opposto del guadagno di velocità che volevi. Fai invece: differisci solo le immagini fuori dalla prima schermata e carica subito quelle visibili.

“Google non indicizza affatto i contenuti caricati in modo differito.” Perché è sbagliato: Google esegue la scansione e indicizza questi contenuti senza problemi quando il caricamento usa il metodo nativo, IntersectionObserver o una libreria ben funzionante. Il rischio riguarda configurazioni rotte o subordinate allo scorrimento o al clic — secondo le stesse parole di Google, il problema è quando è “not implemented correctly.” (traduzione) «non implementato correttamente». Fai invece: usa un metodo basato sull’intersezione con il viewport e verifica nell’HTML renderizzato.

“loading='auto' è una buona impostazione predefinita.” Perché è sbagliato: auto è deprecato in Chrome; raccomandarlo è un consiglio obsoleto. Fai invece: usa lazy per le risorse fuori schermo, eager (o niente) per il resto.

“Il lazy loading e lo scroll infinito sono la stessa soluzione.” Perché è sbagliato: sono distinti. Lo scroll infinito richiede inoltre URL paginati unici e aggiornamenti dell’API History, altrimenti i contenuti più profondi potrebbero non essere mai indicizzati in modo affidabile. Fai invece: tratta il caricamento paginato/infinito come un’architettura a sé con URL per blocco.

“loading='lazy' funziona su qualsiasi elemento.” Perché è sbagliato: è specificato per <img> e <iframe>. Il supporto per altri elementi non fa parte della specifica principale allo stesso modo. Fai invece: usa l’attributo su immagini e iframe; gestisci altri media con una tecnica appropriata (per i video, un’immagine poster che carica il video all’ingresso nel viewport).

“Il lazy loading danneggia la SEO.” Perché è sbagliato: il caricamento differito in sé non è una penalità. L’effetto rilevante per il ranking passa attraverso i Core Web Vitals ed è piccolo; è la implementazione scadente a danneggiare, non la tecnica. Fai invece: implementalo correttamente, escludi l’immagine LCP e verifica cosa viene renderizzato.

Cheat sheet del lazy loading

L’attributo loading

Valore	Cosa fa	Quando usarlo
`loading="lazy"`	Rimanda la risorsa finché non è vicina al viewport	Immagini e iframe sotto la piega
`loading="eager"`	Carica immediatamente (comportamento predefinito)	Immagini nella prima schermata o LCP (oppure ometti l’attributo)
`loading="auto"`	Deprecato in Chrome — non usarlo	—

Quali elementi lo supportano

<img> — sì
<iframe> — sì
Altri elementi (video/audio) — non fanno parte della specifica principale allo stesso modo; usa un pattern con immagine poster + caricamento su visualizzazione per i video.

Sopra vs. sotto la piega

Sopra la piega / probabile LCP → eager (mai lazy). Aggiungi fetchpriority="high" all’immagine LCP.
Sotto la piega → lazy.

Impatto sui Core Web Vitals

Rimandare le immagini fuori schermo → aiuta LCP (meno byte competono all’inizio).
Rimandare gli iframe fuori schermo → aiuta INP (meno lavoro sul thread principale all’avvio).
width/height mancanti su immagini lazy → possono danneggiare CLS (spostamento del layout al caricamento).

Regole che Googlebot considera

Googlebot non scorre né clicca — niente contenuti bloccati da scroll o click.
Metodi sicuri: loading="lazy" nativo, IntersectionObserver, libreria JS ben comportata.
Verifica: URL Inspection → HTML renderizzato → URL dell’immagine nell’attributo src.
Scroll infinito ≠ lazy loading delle immagini — richiede URL unici paginati + History API.

Prima / dopo

Correzioni concrete, presentate come le incontreresti in un audit.

1. L’immagine principale viene caricata in modo differito (LCP ritardato)

Prima:

<img src="hero.jpg" loading="lazy" alt="Product hero">

Dopo:

<img src="hero.jpg" fetchpriority="high" alt="Product hero">

Perché: l’immagine principale è l’elemento LCP. Caricarla subito e dare priorità al recupero le permette di essere visualizzata prima. Il caricamento differito fa l’opposto.

2. Caricamento differito generalizzato da un’impostazione predefinita del CMS

Prima: ogni <img> nel template ha loading="lazy", incluso il logo nell’header l’immagine in evidenza in cima alla pagina. Dopo: il template carica in eager le immagini sopra la piega e applica loading="lazy" solo alle immagini renderizzate sotto la viewport iniziale. Perché: il lazy loading generalizzato cattura le immagini visibili immediatamente, ritardando ciò che l’utente (e LCP) vede per primo.

3. Embed fuori schermo caricato al caricamento della pagina

Prima:

<iframe src="https://maps.google.com/…" title="Store map"></iframe>

Dopo:

<iframe src="https://maps.google.com/…" loading="lazy" title="Store map"></iframe>

Perché: la mappa è sotto la piega. Rimandarla rimuove il suo costo di avvio e aiuta INP, poiché gli embed fanno lavoro sul thread principale mentre la pagina si carica.

4. Lazy loading JS personalizzato lascia src vuoto per Googlebot

Prima: una libreria memorizza l’URL reale in data-src e lo sostituisce in src su un evento di scroll — che Googlebot non attiva mai, quindi l’HTML renderizzato mostra un src vuoto/placeholder. Dopo: usa loading="lazy" nativo (URL reale in src dall’inizio), oppure una libreria basata su IntersectionObserver, poi conferma in URL Inspection che l’URL sia presente nel src renderizzato. Perché: se l’URL non è in src nell’HTML renderizzato, Google non può raccogliere l’immagine.

Trova immagini che dovrebbero (o non dovrebbero) essere caricate in lazy

Uno snippet della console DevTools che puoi incollare su qualsiasi pagina per fare un audit dell’attributo loading. Elenca le immagini con il loro valore loading e se sono attualmente nella viewport — così puoi individuare un’immagine sopra la piega marcata lazy, o una sotto la piega che non lo è.

Chrome DevTools Console

// Audit loading attributes vs. viewport position
[...document.images].forEach(img => {
  const r = img.getBoundingClientRect();
  const inView = r.top < innerHeight && r.bottom > 0;
  const loading = img.getAttribute('loading') || '(none/eager)';
  // Flag the two mistakes: in-view + lazy, or off-view + not lazy
  const flag =
    (inView && loading === 'lazy') ? '⚠ above-the-fold but LAZY' :
    (!inView && loading !== 'lazy') ? '· off-screen, not lazy' : '';
  console.log(loading.padEnd(14), inView ? 'in-view ' : 'off-view', flag, img.currentSrc || img.src);
});

Cerca nel tuo sorgente pattern di lazy loading rischiosi

Controlla i tuoi template/output di build per il valore deprecato auto e per il lazy loading JS stile data-src (che può lasciare src vuoto per Googlebot).

macOS / Linux (bash)

# Deprecated loading="auto"
grep -rn 'loading="auto"' ./src

# JS-driven lazy load leaving real URL in data-src (verify these render into src)
grep -rn 'data-src=' ./src

Windows (PowerShell)

# Deprecated loading="auto"
Get-ChildItem -Recurse .\src | Select-String -Pattern 'loading="auto"'

# JS-driven lazy load using data-src
Get-ChildItem -Recurse .\src | Select-String -Pattern 'data-src='

Ricorda: data-src non è automaticamente un problema — è un invito a confermare che l’URL reale finisca nel src renderizzato, cosa che verifichi in Search Console URL Inspection.

La richiesta dell’immagine principale parte più tardi dopo aver abilitato il caricamento differito

Sintomo: LCP diventa più lento e la richiesta dell’immagine principale parte tardi nella sequenza delle richieste.

Causa probabile: Una regola CMS globale ha aggiunto loading="lazy" a un’immagine sopra la piega o LCP.

Correzione e conferma: Rimuovi l’attributo lazy da quell’immagine, aggiungi facoltativamente fetchpriority="high" e conferma che la sua richiesta inizi prima in una traccia corrispondente.

L’immagine lazy appare ma sposta la pagina

Sintomo: Il contenuto salta quando un’immagine differita entra nel viewport.

Causa probabile: L’immagine non ha dimensioni esplicite o un rapporto d’aspetto riservato.

Correzione e conferma: Aggiungi gli attributi width e height o riserva lo stesso rapporto d’aspetto in CSS. Ricarica con le regioni di layout-shift abilitate e verifica che l’immagine non sposti più il contenuto circostante.

Google non vede il contenuto differito

Sintomo: Un’ispezione renderizzata manca dell’URL dell’immagine o del contenuto che appare dopo che un utente scorre.

Causa probabile: Googlebot non esegue mai un gestore di scorrimento o clic, oppure una libreria di caricamento differito lascia l’URL reale in data-src invece che nel src renderizzato.

Correzione e conferma: Usa il lazy loading nativo o un’implementazione basata su IntersectionObserver, poi ispeziona l’HTML renderizzato e conferma che l’URL finale e il contenuto siano presenti senza interazione.

L’embed fuori schermo si carica ancora immediatamente

Sintomo: Un iframe sotto la piega appare nella sequenza iniziale delle richieste nonostante una modifica al lazy-loading.

Causa probabile: L’attributo è assente dall’iframe distribuito, un wrapper crea l’iframe in modo eager, oppure l’embed è abbastanza vicino al viewport per la soglia di caricamento del browser.

Correzione e conferma: Ispeziona il DOM live e l’iniziatore della richiesta, testa su una pagina lunga con cache fredda e verifica che la richiesta sia differita fino alla soglia vicino al viewport del browser.

Strumenti per implementazione e prova

Pannelli Elements e Network di Chrome DevTools: conferma l’attributo loading distribuito, identifica quale script ha creato un iframe e confronta i tempi di inizio delle richieste prima e dopo una modifica.
Pannello Performance di Chrome DevTools: registra un caricamento e verifica che il differimento di un embed riduca il lavoro iniziale sul thread principale senza ritardare l’immagine LCP.
PageSpeed Insights: usa la diagnostica off-screen-image come elenco iniziale, poi separa i veri candidati sotto la piega dall’immagine principale o da altro contenuto immediato.
URL Inspection di Search Console: ispeziona l’HTML renderizzato e verifica che gli URL delle immagini differite finiscano in src e che il contenuto caricato in modo differito esista senza scorrimento o click.
Il viewport del browser e la filmstrip: testa più di una dimensione di viewport. Un’immagine sotto la piega su desktop può essere sopra la piega su un dispositivo più piccolo o di forma diversa.

Differimento delle immagini sotto la piega

Test da eseguire: Registra una traccia di rete a caricamento freddo prima e dopo l’aggiunta del lazy loading nativo a un’immagine ben sotto il viewport iniziale.

Risultato atteso: La richiesta dell’immagine è assente dalla sequenza critica iniziale e inizia quando il viewport si avvicina.

Interpretazione del fallimento: Il markup distribuito manca dell’attributo, JavaScript crea o recupera l’immagine in modo eager, oppure l’immagine di test è entro la soglia vicino al viewport del browser.

Finestra di monitoraggio: Controlla immediatamente dopo la distribuzione su dimensioni di viewport rappresentative per mobile e desktop.

Trigger di rollback: Esegui il rollback se un’immagine visibile al caricamento iniziale viene differita o se l’immagine non appare regolarmente prima che l’utente la raggiunga.

Esclusione dell’immagine LCP

Test da eseguire: Confronta tracce di prestazioni corrispondenti e sequenze di richieste per l’immagine LCP della pagina dopo aver rimosso il lazy loading generalizzato.

Risultato atteso: L’immagine LCP si carica in modo eager, la sua richiesta inizia prima e LCP non regredisce.

Interpretazione del fallimento: Un altro template o livello di ottimizzazione riaggiunge l’attributo, oppure la scoperta è ancora ritardata da CSS, JavaScript o markup.

Finestra di monitoraggio: Controlla ripetuti test di laboratorio immediatamente, poi osserva il LCP sul campo nella finestra di reporting successiva.

Trigger di rollback: Esegui il rollback del rollout circostante se la modifica ritarda altre risorse critiche abbastanza da causare una regressione LCP ripetibile.

Visibilità del contenuto renderizzato

Test da eseguire: Usa URL Inspection per visualizzare l’HTML renderizzato senza interagire con la pagina e cerca l’URL dell’immagine differita e il contenuto associato.

Risultato atteso: L’URL finale appare in src e il contenuto importante è presente nell’HTML renderizzato.

Interpretazione del fallimento: L’implementazione dipende da un evento di scorrimento o clic, oppure lo script di caricamento differito non è riuscito durante il rendering.

Finestra di monitoraggio: Testa ogni modello interessato dopo il rilascio e dopo aver modificato la libreria di caricamento differito o la pipeline di immagini del CMS.

Trigger di rollback: Esegui il rollback se il contenuto indicizzabile o gli URL delle immagini scompaiono dall’output renderizzato.

Mettiti alla prova: caricamento differito

Cinque domande rapide sul differimento di immagini e iframe senza danneggiare Core Web Vitals o l’indicizzazione. Scegli una risposta per ciascuna, poi controlla.

Risorse che meritano il tuo tempo

I miei scritti correlati

Problemi e buone pratiche della SEO JavaScript — dove tratto il passaggio dal caricamento differito basato su JS a quello nativo del browser e perché il contenuto differito, non solo le immagini, rappresenta il rischio per l’indicizzazione.
Google PageSpeed Insights per SEO e sviluppatori — collega il controllo sulle immagini fuori schermo da differire al caricamento differito, oltre al resto del report PSI.
Guida introduttiva alla SEO tecnica — dove prestazioni e rendering si inseriscono nel quadro generale.

Dal settore

Correggere i contenuti caricati in modo differito (Google Search Central) — il documento definitivo su implementazione e test.
Caricamento differito nativo delle immagini sul web (web.dev) — l’attributo nativo e l’avvertenza sull’LCP, direttamente dal team prestazioni di Google.
È il momento di differire gli iframe fuori schermo (web.dev) — il caso degli iframe e il loro vantaggio durante l’avvio e per INP.
Il caricamento differito spiegato — Search Off the Record, episodio 98 (Google) — l’episodio completo di Mueller e Splitt su caricamento differito, rendering, indicizzazione e Core Web Vitals.
Caricamento differito: velocizzare rapidamente sito ed esperienza utente (Search Engine Land) — una guida approfondita del settore con note specifiche per CMS.
Caricamento differito — guida alle prestazioni (MDN) — il riferimento per sviluppatori dell’API.
Introduzione al caricamento differito per scansione e indicizzazione (Oncrawl) — un approfondimento sulla scansione e sull’indicizzazione.

Cronologia modifiche