Che cosa fa davvero il lazy loading al tuo Largest Contentful Paint

Il lazy loading è una decisione di scheduling, non un incantesimo di velocità

Il lazy loading viene spesso descritto come un miglioramento delle performance, il che è vero nello stesso senso in cui non preparare una valigia è una riduzione di peso. Aiuta perché il browser fa meno lavoro all’inizio.

Questa distinzione conta per il Largest Contentful Paint, di solito abbreviato in LCP. LCP misura quando viene renderizzato l’elemento significativo più grande nella viewport. Su molte pagine, quell’elemento è una hero image. Su altre, è un grande titolo, un’immagine poster, una foto prodotto o un blocco di contenuto.

Il lazy loading cambia il momento in cui le risorse vengono richieste. Non fa decodificare un’immagine più velocemente, non fa rispondere un server più rapidamente e non fa renderizzare un font prima. Se applichi il lazy loading alla cosa sbagliata, soprattutto all’elemento che diventa l’LCP, stai dicendo al browser di aspettare prima di recuperare proprio ciò che deve mostrare per superare i Core Web Vitals.

Ecco perché il lazy loading è sia abusato sia poco compreso.

Che cosa fa il browser quando applichi il lazy loading a un’immagine

Il lazy loading nativo delle immagini di solito si aggiunge così:

<img src='hero.jpg' loading='lazy' alt='...'>

Con loading='lazy', al browser è consentito rimandare il recupero dell’immagine finché ritiene che l’immagine sarà probabilmente necessaria. In pratica, i browser usano la distanza dalla viewport, le condizioni di rete, le dimensioni dell’immagine e altre euristiche. Le regole esatte sono dettagli implementativi e possono cambiare.

Con loading='eager', oppure senza attributo lazy nella maggior parte dei casi, il browser tratta l’immagine come parte del normale processo di caricamento. Deve comunque stabilire le priorità tra CSS, JavaScript, font, immagini e altre richieste, ma l’immagine è scopribile immediatamente.

Questo significa che il lazy loading incide soprattutto su tre fasi:

• Discovery: quando il browser nota la risorsa.
• Request start: quando inizia il recupero dalla rete.
• Render timing: quando la risorsa può finalmente essere decodificata e disegnata.

Per l’LCP, quella pericolosa è il request start. Se la richiesta dell’immagine LCP parte tardi, anche tutto ciò che viene dopo slitta in avanti.

La regola semplice: non applicare mai il lazy loading al candidato LCP

Se un’immagine è visibile nella viewport iniziale ed è probabile che sia il largest contentful element, non caricarla in lazy loading.

Questo include:

• hero image
• foto prodotto principali above the fold
• grandi immagini di apertura degli articoli
• grandi immagini simili a sfondi implementate come <img>
• immagini poster dei video quando il poster è l’elemento visivo principale

Il browser non può renderizzare l’immagine LCP finché non è stata richiesta, trasferita, decodificata e disegnata. Il lazy loading inserisce incertezza prima del primo passaggio. Anche un piccolo ritardo può bastare a spostare l’LCP da accettabile a scarso su una connessione più lenta.

Un pattern di errore comune è questo:

1. Il server invia l’HTML.
2. Il browser analizza un’immagine above-the-fold.
3. L’immagine ha loading='lazy'.
4. Il browser aspetta perché l’euristica del lazy loading dice che può farlo.
5. CSS e JavaScript continuano a caricarsi.
6. La richiesta dell’immagine parte più tardi del dovuto.
7. L’LCP arriva in ritardo, anche se il file dell’immagine in sé è ragionevolmente ottimizzato.

È frustrante perché la pagina può sembrare ordinata in una code review. Il problema non è solo la dimensione del file. È la priorità.

Se stai leggendo l’output di laboratorio e cerchi di capire se l’LCP sia davvero il problema, la nostra guida su come leggere un report Lighthouse senza farsi prendere dal panico è volutamente pratica: separa dati di campo, suggerimenti di laboratorio e correzioni prima di iniziare a modificare il codice. (Nota: se il routing è case-sensitive, usa l’URL esatto del tuo CMS.)

Correzione: usa l’URL interno effettivo

L’URL corretto dell’articolo Wux è Come leggere un report Lighthouse senza farsi prendere dal panico. Il punto resta valido: identifica l’elemento LCP prima di modificare il comportamento di caricamento.

Quando il lazy loading può migliorare l’LCP

Il lazy loading può migliorare l’LCP indirettamente quando tiene le risorse non critiche fuori dalla strada del browser.

Immagina una pagina prodotto con una hero image del prodotto in alto e un carousel di dodici immagini di raccomandazione sotto la piega. Se tutte e tredici le immagini vengono caricate eager, il browser può spendere banda e slot di connessione su immagini che l’utente non può ancora vedere. Su una rete limitata, questo può competere con la hero image, i CSS o i file dei font.

Applicare il lazy loading alle immagini del carousel sotto la piega può aiutare l’immagine LCP a caricarsi prima, perché durante il caricamento iniziale della pagina ci sono meno richieste non critiche in competizione.

Questo è il caso di performance legittimo per il lazy loading:

• carica eager il candidato LCP above-the-fold
• carica in lazy loading le immagini sotto la viewport iniziale
• evita script pesanti che iniettano tardi immagini importanti
• mantieni le dimensioni delle immagini nell’HTML per evitare layout shift

Il lazy loading non è di per sé un’ottimizzazione dell’LCP. È uno strumento di prioritizzazione delle risorse. Aiuta quando protegge il percorso critico.

Il pattern migliore per le immagini LCP

Per un’immagine LCP above-the-fold, l’obiettivo è fare in modo che il browser la scopra presto, la richieda presto e la renderizzi senza instabilità di layout.

Una base solida è questa:

<img
  src='/images/product-hero.avif'
  srcset='/images/product-hero-800.avif 800w, /images/product-hero-1400.avif 1400w'
  sizes='(max-width: 768px) 100vw, 720px'
  width='1400'
  height='900'
  loading='eager'
  fetchpriority='high'
  decoding='async'
  alt='Black hiking backpack with roll-top closure'
>

Le parti importanti non sono decorative:

• loading='eager' evita il ritardo del lazy loading.
• fetchpriority='high' dice al browser che questa immagine è importante.
• width e height riservano spazio e riducono il layout shift.
• srcset e sizes evitano download sovradimensionati.
• Un formato moderno può ridurre il tempo di trasferimento se usato con attenzione.

Se stai ancora servendo un unico grande JPEG a ogni schermo, il formato dell’immagine e il dimensionamento responsive possono contare più dell’attributo di lazy loading. Per un albero decisionale pratico, vedi quando AVIF batte WebP e quando no.

Le immagini di background richiedono più attenzione

Le immagini di background in CSS non vengono scoperte presto quanto le normali immagini HTML. Il browser deve recuperare e analizzare il CSS prima di conoscerle. Se il tuo elemento LCP è un’immagine di background CSS, hai già reso la discovery più difficile.

Questo non significa che le immagini di background siano vietate. Significa però che dovresti usarle in modo deliberato.

Per immagini decorative, i background CSS vanno bene. Per hero imagery significativa, un elemento <img> o <picture> è di solito migliore perché è visibile al parser HTML, supporta il testo alternativo e funziona bene con gli attributi per immagini responsive.

Se devi usare un background CSS per un’immagine LCP, valuta il preload:

<link rel='preload' as='image' href='/images/hero.avif'>

Neanche il preload è una bacchetta magica. Precaricare troppe immagini crea lo stesso problema di priorità con un altro costume. Usalo per l’unica immagine che conta davvero, non per ogni immagine del design system.

Il lazy loading in JavaScript spesso peggiora le cose

Prima che il lazy loading nativo fosse ampiamente supportato, molti siti usavano librerie JavaScript che sostituivano data-src con src dopo il caricamento della pagina o dopo l’attivazione di un intersection observer. Alcuni lo fanno ancora.

Può essere ragionevole per lunghi articoli o gallerie molto ricche di immagini. È una scelta scadente per il contenuto above-the-fold.

Il preload scanner del browser è veloce, ma non può richiedere un’immagine il cui URL è nascosto in un attributo personalizzato finché JavaScript non viene eseguito. Se la tua hero image parte come data-src='hero.jpg', hai ritardato la discovery dietro download dello script, parsing, esecuzione e hydration del framework.

È un cattivo scambio per l’LCP. Metti gli URL delle immagini critiche in vero HTML. Lascia che il browser faccia il suo lavoro.

L’LCP non è sempre un problema di immagini

Su alcune pagine, l’elemento LCP è testo. In quel caso, il lazy loading delle immagini può avere poco effetto diretto. Il collo di bottiglia può essere CSS render-blocking, risposta lenta del server, rendering client-side o web font.

Vale la pena richiamare i font perché sono una causa nascosta frequente di rendering tardivo del testo. Un grande titolo può diventare LCP, e il comportamento di caricamento dei font può ritardare o modificare il momento in cui quel titolo viene disegnato. Se il lavoro sulle immagini non sta spostando la metrica, ispeziona direttamente l’elemento LCP invece di fare supposizioni. Il nostro articolo sui web font come vittoria di performance copre le correzioni noiose che spesso funzionano: meno pesi, formati moderni, fallback sensati.

Come testare le modifiche al lazy loading senza ingannarti

Non testare fissando la pagina sulla rete Wi-Fi dell’ufficio. Devi vedere il timing delle richieste.

Usa questo workflow:

1. Apri Chrome DevTools e registra una traccia Performance.
2. Abilita il network throttling, per esempio Fast 4G o Slow 4G.
3. Ricarica la pagina con la cache disabilitata.
4. Trova il marker LCP.
5. Identifica l’elemento LCP.
6. Nel pannello Network, controlla quando quella risorsa ha iniziato a caricarsi.

Se la risorsa LCP parte tardi, chiediti perché:

• È stata caricata in lazy loading?
• È stata iniettata da JavaScript?
• Era nascosta nel CSS?
• È stata de-prioritizzata dietro altre immagini?
• Il server ha risposto lentamente?

Poi fai una sola modifica e ritesta. Il lavoro sulle performance diventa confuso quando i team cambiano formato delle immagini, lazy loading, preloading, bundle JavaScript e impostazioni CDN nello stesso deploy. Potresti migliorare la pagina, ma non saprai quale cambiamento ha contato.

Anche i dati di campo contano. Gli strumenti di laboratorio sono utili per la diagnosi, ma l’LCP varia in base a dispositivo, rete, viewport, stato della cache e geografia. Usa real-user monitoring o dati del Chrome User Experience Report quando puoi.

<!-- tool-cta:start -->

💡 Prova questo: Mantieni la tua immagine LCP piccola e caricata con priorità passandola in Image Compressor, così viene renderizzata rapidamente senza bisogno del lazy loading.

<!-- tool-cta:end -->

Una policy pratica per la maggior parte dei siti web

Per la maggior parte dei siti marketing, pagine ecommerce, siti di documentazione e pagine editoriali, questa policy basta:

• Immagine primaria above-the-fold: carica eager, valuta una fetch priority alta.
• Immagini di contenuto sotto la piega: carica in lazy loading.
• Icone e piccoli asset UI: di solito non vale la pena pensarci singolarmente.
• Hero con background CSS: riconsiderala come immagine HTML o fai preload con cautela.
• Hero image iniettata da JavaScript: correggi l’architettura di rendering se possibile.
• Carousel: carica eager solo la prima slide visibile; carica in lazy loading il resto.

Esistono casi limite. Le euristiche dei browser migliorano. I framework aggiungono componenti immagine automatici. Alcune piattaforme ora evitano il lazy loading per immagini rilevate vicino alla viewport. Tuttavia, il principio non cambia: le risorse critiche dovrebbero essere precoci ed evidenti; le risorse non critiche dovrebbero aspettare.

Il lazy loading è prezioso quando esprime questa distinzione. È dannoso quando nasconde al browser il contenuto più importante finché la pagina ha già iniziato a perdere la gara dell’LCP.