📌 lazy loading: a cosa serve e come applicarlo bene

Lazy loading: a cosa serve davvero (e quando conviene usarlo)

Un sito non è “lento” perché è brutto o perché l’hosting è scarso: nella maggior parte dei casi è lento perché carica troppe cose troppo presto. Immagini, iframe, embed social e widget di terze parti competono per banda, CPU e tempo di parsing proprio nel momento più critico: l’avvio pagina.

Il lazy loading serve a risolvere questo problema in modo chirurgico: rimanda il caricamento delle risorse non essenziali finché non stanno per diventare visibili. Il risultato è concreto:

• Caricamento iniziale più leggero (meno richieste e meno payload subito).
• Velocità percepita maggiore: l’utente vede prima contenuto utile, non attende media “inutili”.
• Meno consumo dati su mobile (fondamentale per pagine lunghe o con molte immagini).
• Migliori metriche di esperienza se implementato correttamente: riduzione del carico iniziale e prevenzione dei “salti” di layout (CLS).

Attenzione però: il lazy loading non è un trucco, è una priorità di caricamento. Se lo applichi in modo cieco peggiori l’elemento più importante: LCP (Largest Contentful Paint). Quindi la regola è netta: lazy sotto la piega, prioritario sopra la piega.

Cos’è il lazy loading (definizione operativa)

Il lazy loading è una strategia di caricamento “a domanda”:

• carichi subito solo ciò che serve per rendere la parte iniziale della pagina (above the fold);
• rimandi tutto il resto (below the fold) finché l’utente non ci arriva con lo scroll.

In pratica, sposti risorse non critiche dal momento più delicato (avvio pagina) a un momento successivo, dove il browser e la rete hanno più margine.

Dove conviene usarlo (e dove è un errore)

Da lazy-loadare (quasi sempre)

• Immagini sotto la prima schermata (articoli lunghi, liste di card, gallery).
• Iframe (YouTube, mappe, embed social): spesso pesanti e ricchi di script.
• Componenti terze parti non essenziali (widget extra, contenuti “secondari”).

Da NON lazy-loadare (regola ferrea)

• Hero image o qualsiasi elemento che probabilmente è il tuo LCP.
• Contenuti essenziali per comprendere la pagina immediatamente (titolo, incipit, call-to-action primaria).

Se l’utente apre una pagina e il contenuto principale arriva in ritardo perché l’hai messo in lazy, è un peggioramento misurabile della performance percepita.

Implementazione 1: lazy loading nativo (la soluzione migliore quando basta)

Il metodo più pulito è quello nativo: loading="lazy". È leggero, semplice e non richiede JavaScript.

Immagini

<img
  src="immagine-grande.webp"
  alt="Descrizione"
  loading="lazy"
  decoding="async"
  width="1200"
  height="800">

Perché questi dettagli contano:

• loading="lazy" rimanda il download finché l’immagine è vicina alla viewport.
• decoding="async" aiuta a non bloccare il rendering quando possibile.
• width/height (o un rapporto fisso) evita CLS: il layout non deve “saltare” quando l’immagine arriva.

Iframe (video, mappe, embed)

<iframe
  src="https://www.youtube.com/embed/VIDEO_ID"
  loading="lazy"
  title="Video"
  width="560"
  height="315"></iframe>

Gli iframe spesso trascinano dietro JavaScript, font, tracciamenti e rendering aggiuntivo. Rimandarli, quando non sono visibili, riduce drasticamente il peso iniziale.

Implementazione 2: controllo avanzato (Intersection Observer)

Se devi gestire casi non coperti dal nativo (placeholder personalizzati, caricamento di immagini gestite via data-src, logiche di pre-caricamento controllato), usa Intersection Observer: assegni src solo quando serve.

HTML: non caricare subito

<img
  data-src="immagine-grande.webp"
  alt="Descrizione"
  width="1200"
  height="800">

JavaScript: carica quando entra (o sta per entrare)

document.addEventListener("DOMContentLoaded", () => {
  const imgs = document.querySelectorAll("img[data-src]");

  const io = new IntersectionObserver((entries, observer) => {
    for (const entry of entries) {
      if (!entry.isIntersecting) continue;

      const img = entry.target;
      img.src = img.dataset.src;

      img.removeAttribute("data-src");
      observer.unobserve(img);
    }
  }, {
    root: null,
    threshold: 0,
    rootMargin: "200px"
  });

  imgs.forEach(img => io.observe(img));
});

Nota tecnica: rootMargin è la differenza tra un lazy loading “buono” e uno fastidioso. Se carichi troppo tardi, l’utente vede un buco. Se carichi un po’ prima, l’esperienza resta fluida.

Errori tipici che peggiorano le prestazioni

1) Lazy-loadare l’elemento LCP

È il modo più rapido per peggiorare la performance percepita. L’hero (o il contenuto principale) deve essere prioritario, non rimandato.

2) Non riservare spazio alle immagini (CLS)

Se non dichiari dimensioni o rapporto, l’immagine arriva e spinge giù il contenuto: layout instabile, UX peggiore, metriche peggiori.

3) Credere che lazy loading sostituisca l’ottimizzazione immagini

Lazy loading rimanda. Non “alleggerisce” automaticamente. Devi comunque:

• comprimere e scegliere formati efficienti (WebP/AVIF quando possibile),
• usare immagini responsive (srcset/sizes) se hai layout variabili,
• configurare caching corretto.

Come verificare se hai migliorato davvero

• Fai un test con Lighthouse / PageSpeed per un confronto rapido.
• Controlla soprattutto LCP e CLS: il lazy deve migliorare il carico iniziale senza creare instabilità.
• Prova su mobile e rete lenta: è lì che il lazy loading mostra il suo valore reale.

Conclusione

Il lazy loading serve a una cosa precisa: proteggere l’avvio pagina dal peso delle risorse non critiche. Usalo su immagini e iframe sotto la piega, proteggi l’LCP, riserva sempre lo spazio per evitare CLS, e misura i risultati. Se fai queste tre cose, l’ottimizzazione è reale, non cosmetica.