Caricamento differito

Il lazy loading significa rimandare il caricamento di asset non critici finché non si avvicinano alla viewport. Per la SEO, il vantaggio è semplice: meno richieste iniziali, pagine più leggere e migliori Core Web Vitals. L’inconveniente è altrettanto semplice. Se carichi in lazy l’asset sbagliato, soprattutto l’immagine LCP, rendi la pagina più lenta, non più veloce.

Cosa conta davvero per la SEO

Nei template ricchi di immagini, il lazy loading può ridurre le richieste iniziali di immagini del 30-80% e diminuire i byte trasferiti di 500 KB fino a diversi MB. Questo di solito aiuta LCP, INP in modo indiretto e l’efficienza di crawling sui siti di grandi dimensioni. Usa Google Search Console per le tendenze sui Core Web Vitals, Lighthouse o DebugBear per i test in laboratorio e Screaming Frog in modalità di rendering JavaScript per verificare che gli asset rimandati continuino a comparire nell’HTML renderizzato.

Google supporta il lazy loading nativo da anni e John Mueller di Google ha ripetutamente affermato che Google può elaborare contenuti caricati in lazy quando l’implementazione è corretta. Questa precisazione è importante. Correttamente significa che l’asset si carica nel DOM renderizzato senza richiedere interazioni utente strane, eventi di scroll personalizzati o dipendenze JS non funzionanti.

Come implementarlo senza penalizzare il posizionamento

• Usa il nativo loading="lazy" sugli elementi img e iframe sotto la sezione iniziale (below the fold).
• Non caricare in lazy l’immagine hero o l’asset che probabilmente è quello LCP. Impostalo su eager loading e valuta fetchpriority="high".
• Riserva le dimensioni con width/height o con CSS aspect-ratio per evitare CLS.
• Mantieni l’URL reale dell’immagine nel markup. Evita configurazioni in cui l’URL compare solo dopo l’esecuzione di JS complesso.
• Testa l’output renderizzato in Screaming Frog e usa l’URL Inspection in GSC, non solo nel browser.

Ahrefs e Semrush non ti diranno se il lazy loading è rotto. Possono mostrarti la perdita di traffico solo a posteriori. La diagnosi avviene negli strumenti di rendering, nelle browser waterfall e nell’ispezione a livello pagina di GSC.

Dove i team sbagliano più spesso

L’errore più comune è trattare il lazy loading come una regola generale. Non lo è. Le griglie di prodotto, i corpi degli articoli, i moduli di contenuti correlati e i video incorporati sono candidati validi. Le immagini above the fold, i background CSS usati come visual hero e i widget di recensione critici di solito no.

Un altro problema: le immagini di sfondo. Il lazy loading nativo non fa nulla per i background CSS, quindi i team presumono di aver ottimizzato la pagina quando il visual più pesante continua a bloccare il rendering. In quel caso serve una strategia diversa, spesso cambiamenti al template o la sostituzione dei background decorativi con elementi immagine reali.

La vera avvertenza

Il lazy loading non è, di per sé, una tattica di ranking. È una tattica di erogazione (delivery). Se il tuo collo di bottiglia è un TTFB lento, JavaScript appesantito o un bundle CSS da 1,5 MB, il lazy loading delle immagini non salverà la pagina. Inoltre, i guadagni sul crawl budget sono spesso sopravvalutati. Nella maggior parte dei siti con meno di 100.000 URL, il vantaggio SEO più grande è la velocità percepita dall’utente, non l’efficienza dei bot.

Usalo dove fa risparmiare davvero richieste. Salta dove ritarda contenuti critici. È tutto qui il gioco.