Lazy Load Images nel 2026: Pagine Più Veloci e Sicure da LCP

Ultimo aggiornamento: June 28, 2026

Il lazy loading aiuta le pagine ricche di immagini a sembrare più veloci perché il browser può saltare le richieste di immagini al di fuori del viewport durante il primo rendering. Usato con leggerezza, può anche ritardare l'unica immagine che gli utenti necessitano immediatamente: l'hero, la foto principale del prodotto o la copertina dell'articolo che diventa l'elemento Largest Contentful Paint.

Questa guida mostra dove utilizzare loading="lazy" nativo, dove mantenere le immagini "eager" (immediatamente caricate) e come pubblicare immagini lazy-loaded senza compromettere Core Web Vitals, SEO o la consegna tramite CDN.

Risposta rapida: come dovresti eseguire il lazy loading delle immagini?

Utilizza il lazy loading solo per le immagini che iniziano fuori dal primo viewport. Mantieni l'immagine LCP probabile "eager", riserva larghezza e altezza per ogni immagine e servi file WebP o AVIF responsive da un URL CDN cacheabile.

Per HTML semplice, l'implementazione più semplice è loading="lazy" su elementi <img> al di fuori del viewport. Non aggiungerlo a un'immagine hero, a una foto principale di prodotto, all'immagine articolo visibile per prima o a qualsiasi immagine che debba apparire prima che l'utente scorra.

In caso di dubbio, testa la pagina in Lighthouse o Chrome DevTools. Se un'immagine lazy viene segnalata come elemento LCP, rimuovi il lazy loading da quell'immagine e considera fetchpriority="high".

Cosa cambia realmente il lazy loading?

Il lazy loading modifica i tempi di richiesta. Il browser può attendere di scaricare un'immagine finché l'utente non è abbastanza vicino per vederla. Questo fa risparmiare banda su pagine lunghe, riduce la pressione delle richieste iniziali e dà a CSS, font, script e all'immagine visibile una migliore possibilità di terminare prima.

Non rende piccole le immagini sovradimensionate. Un JPEG da 2400 px è comunque uno spreco dopo che viene finalmente caricato. Abbina il lazy loading con ridimensionamento, compressione e markup responsive fin dall'inizio. Image Compression Deep Dive copre la riduzione dei byte, mentre Mobile Image Optimization Guide copre srcset e le dimensioni di visualizzazione mobile.

La funzione nativa del browser è documentata da MDN come la proprietà loading su immagini e iframes in HTMLImageElement.loading. Per i siti moderni, preferisci questa funzione del browser prima di aggiungere una libreria JavaScript per il lazy loading.

Quali immagini non dovrebbero essere sottoposte a lazy loading?

Non eseguire il lazy loading su immagini che definiscono la prima impressione della pagina. L'errore comune è applicare loading="lazy" a ogni immagine in un template CMS perché sembra una soluzione universale di performance.

Mantieni queste immagini "eager":

1. L'immagine hero principale.
2. L'immagine del prodotto sopra il pulsante di acquisto.
3. La prima immagine in un articolo quando appare vicino alla parte superiore su mobile.
4. Un logo o uno screenshot di interfaccia che deve essere visibile prima dell'interazione.
5. Qualsiasi immagine che Chrome segnala come elemento LCP.

Le linee guida Core Web Vitals di Google trattano LCP come il tempo di rendering del più grande elemento di contenuto visibile nel viewport; vedi Largest Contentful Paint. Quando quell'elemento è un'immagine, ritardare la sua richiesta è uno dei modi più rapidi per peggiorare la metrica.

Usa questa regola per i template: la prima posizione immagine dovrebbe impostare di default su eager, e i blocchi immagine ripetibili successivi dovrebbero impostare di default su lazy. Quindi sovrascrivi in base al tipo di pagina quando gli screenshot mobile mostrano un primo viewport diverso.

Come si implementa il lazy loading in HTML?

Usa prima l'markup nativo:

<img
  src="/images/gallery-chair.webp"
  alt="Sedia in noce fotografata frontalmente per una galleria di prodotti"
  width="1200"
  height="800"
  loading="lazy"
  decoding="async"
>

Gli attributi width e height sono importanti quanto loading. Permettono al browser di riservare lo spazio del layout prima che arrivi il file. Senza spazio riservato, un'immagine ritardata può spingere il testo verso il basso nella pagina e creare Cumulative Layout Shift.

Per immagini responsive, mantieni il lazy loading sul fallback <img>:

<picture>
  <source type="image/avif" srcset="/images/gallery-chair-800.avif 800w, /images/gallery-chair-1200.avif 1200w">
  <source type="image/webp" srcset="/images/gallery-chair-800.webp 800w, /images/gallery-chair-1200.webp 1200w">
  <img
    src="/images/gallery-chair-1200.webp"
    alt="Sedia lounge in noce con cuscino verde su sfondo bianco da studio per una galleria di prodotti"
    width="1200"
    height="800"
    sizes="(max-width: 700px) 92vw, 680px"
    loading="lazy"
  >
</picture>

Per l'immagine LCP probabile, usa il pattern opposto:

<img
  src="/images/product-hero.webp"
  alt="Sedia lounge in noce con cuscino verde su sfondo bianco da studio"
  width="1600"
  height="1000"
  fetchpriority="high"
>

L'articolo di Google su browser-level image lazy loading raccomanda il lazy loading nativo e avverte che le immagini nel primo viewport visibile dovrebbero caricarsi normalmente. Questo consiglio è ancora la baseline più pulita per le pubblicazioni del 2026.

Come influisce il lazy loading sulla SEO?

Il lazy loading è sicuro per la SEO quando i contenuti importanti rimangono scopribili nella pagina renderizzata. Google può elaborare JavaScript moderno, ma la SEO delle immagini diventa più debole quando l'URL finale dell'immagine è nascosto dietro interazioni, script che funzionano solo con lo scroll, cookie o un placeholder rotto.

Usa markup normali <img> o <picture> per le immagini di contenuto. Mantieni il testo alternativo alt descrittivo, gli URL CDN indicizzabili e i testi circostanti che spiegano l'immagine. Image SEO Guide 2026 ha il flusso più ampio per crawl e alt-text.

Le linee guida JavaScript SEO di Google Search Central per il lazy loading dicono che i contenuti dovrebbero caricarsi quando sono visibili nel viewport e non dovrebbero dipendere da azioni utente come cliccare o digitare; vedi Fix lazy-loaded content. Questo è un utile guardrail per gallerie di immagini, schede e pagine con scroll infinito.

Quanto può risparmiare il lazy loading in termini di performance?

Il risparmio dipende da quante immagini si trovano sotto il primo viewport e quanto sono grandi quei file. Su un articolo lungo, un browser può evitare di scaricare la maggior parte delle immagini del corpo durante il caricamento iniziale. Su una pagina prodotto corta con una foto visibile, il lazy loading potrebbe non salvare quasi nulla.

Ho codificato le quattro grafiche di questo articolo come file WebP locali alle dimensioni di pubblicazione. I file finali sono da 25 KB a 36 KB ciascuno, quindi il lazy loading non nasconde un enorme problema di byte qui. Il guadagno maggiore deriva dai tempi di richiesta: la copertina è disponibile immediatamente e i diagrammi successivi possono aspettare che il lettore scorra.

Usa questo ordine prima di incolpare il lazy loading:

1. Ridimensionare l'immagine sorgente alla più grande slot di visualizzazione reale.
2. Convertire foto e grafiche miste in WebP o AVIF.
3. Aggiungere srcset e sizes per i layout mobile.
4. Riservare dimensioni immagine o rapporto d'aspetto.
5. Mantenere l'immagine LCP "eager".
6. Eseguire lazy loading solo sulle immagini below-fold.
7. Pubblicare tramite un CDN con caching a lunga durata.
8. Testare la pagina su un viewport mobile stretto.

Se hai bisogno di una sequenza più ampia, Complete Image Optimization Checklist è un buon passaggio finale prima della pubblicazione. Per le regole CDN e gli header cache, usa Image CDN Guide.

Cosa dovresti testare prima di pubblicare?

Testa la pagina renderizzata, non solo il codice. Le soglie del browser per il lazy loading nativo sono dettagli di implementazione, e una pagina che funziona su desktop può comunque ritardare l'immagine sbagliata su un viewport mobile da 390 px.

Esegui questo controllo di pubblicazione:

• L'immagine copertina o hero carica eager (immediatamente).
• L'immagine LCP probabile non è contrassegnata con loading="lazy".
• Ogni immagine ha width e height o un contenitore a rapporto d'aspetto stabile.
• Le immagini below-fold usano loading="lazy".
• Le immagini responsive includono valori sizes realistici.
• Gli URL delle immagini CDN restituiscono HTTP 200.
• I nomi dei file descrivono l'immagine visibile.
• Il testo alt è specifico e non riempito di parole chiave.
• Lighthouse o PageSpeed Insights non segnalano l'immagine lazy come LCP.
• Uno screenshot mobile non mostra grandi lacune vuote o salti di layout.

Per i team di sviluppatori, aggiungi una regola di template: solo i componenti di immagini del corpo ripetuti dovrebbero eseguire il lazy loading per impostazione predefinita. I componenti hero, i media principali dei prodotti e le immagini editoriali above-the-fold dovrebbero richiedere una decisione esplicita.

Checklist lazy-loading per il 2026

Il lazy loading funziona meglio come piccola parte del pipeline di gestione delle immagini. Dovrebbe venire dopo controlli su formato, dimensioni, priorità, accessibilità e CDN.

Prima di inviare, ispeziona il primo viewport e poni una domanda pratica: la pagina avrebbe ancora senso se ogni immagine below-fold aspettasse lo scroll? Se sì, è probabile che il lazy loading stia aiutando. Se la pagina inizia con uno slot hero vuoto, correggi prima la priorità toccando qualsiasi altra cosa.