loading=lazy non è l’immagine LCP

Il 27 ottobre 2026 loading="lazy" non è il modo per far arrivare prima l’immagine che decide il Largest Contentful Paint. Su web.dev, aggiornato il 31 marzo 2025, l’avviso è secco: non applicare il lazy loading all’immagine LCP. Lo standard HTML, letto lo stesso giorno, dice un’altra cosa ancora: l’attributo indica la policy per le immagini fuori dal viewport, e nell’esempio un’immagine lazy già in viewport non ritarda l’evento load della finestra. Non è lo status 103 e non è la differenza tra Lighthouse e CrUX.

In breve: un buon LCP, sulla stessa pagina di web.dev, è 2,5 secondi o meno per almeno il 75 per cento delle visite. fetchpriority="high" è un altro attributo: alza la priorità del fetch, non spegne il lazy loading. Metterlo su più di una o due immagini, scrive la guida, rende la priorità inutile per ridurre il LCP.

Cosa fa davvero loading=lazy

Ho riletto Optimize Largest Contentful Paint, autori Philip Walton e Barry Pollard, pubblicata il 30 aprile 2020 e aggiornata il 31 marzo 2025. Il LCP è una delle tre metriche Core Web Vitals. Misura il tempo da quando l’utente avvia il caricamento della pagina a quando il blocco di immagine o di testo più grande è renderizzato nel viewport.

La guida mette loading="lazy" tra i modi per ritardare l’immagine LCP. Il senso della frase è questo: il lazy loading fa sì che la risorsa non parta finché il layout non conferma che l’immagine è nel viewport, e quindi può cominciare più tardi di quanto farebbe senza l’attributo. L’avviso, in grassetto nella pagina, dice di non fare mai lazy loading sull’immagine LCP, perché produce sempre un ritardo inutile sul caricamento della risorsa e peggiora il LCP. Non ho misurato un sito di esempio. Riporto la frase della guida, non un laboratorio mio.

Senza lazy loading, la stessa pagina aggiunge che le immagini non partono comunque alla priorità più alta: non sono risorse che bloccano il rendering. Per dirlo al browser si usa fetchpriority. L’esempio è <img fetchpriority="high" src="/path/to/hero-image.webp">.

L’esempio dello standard: cinque file

Nello HTML Living Standard, sezione dell’elemento img, l’attributo loading è un lazy loading attribute. Lo scopo scritto è indicare la policy di caricamento delle immagini che stanno fuori dal viewport. L’esempio della specifica, letto il 27 ottobre, è questo comportamento, non un consiglio sul LCP.

Il punto che incrocia la guida è il 3.jpeg. È già nel viewport, ha comunque lazy, e la specifica dice che il caricamento aspetta che il layout sia noto. È lo stesso ritardo che web.dev descrive per l’immagine LCP: si aspetta la conferma del layout. In più, 3.jpeg e 5.jpeg non tengono aperto l’evento load. Un’immagine eager, nell’esempio, sì. Lazy non è quindi «carica dopo, ma il documento aspetta lo stesso». È un’altra policy. La nota sotto l’esempio chiede width e height sulle immagini lazy, anche se il CSS già impone le misure, per non far saltare il layout quando l’immagine arriva. Non è una soglia di LCP.

fetchpriority non cancella lazy

Nello standard, fetchpriority è un fetch priority attribute. Serve a impostare la priorità usata quando si fa il fetch dell’immagine. Non è definito come un interruttore che trasforma lazy in eager. Le due guide che ho letto non scrivono che high annulla loading="lazy" se stanno sullo stesso tag. Non lo affermo.

web.dev dice che ha senso fetchpriority="high" sull’img che si ritiene essere l’elemento LCP. Aggiunge che alzare la priorità su più di una o due immagini rende l’impostazione inutile per ridurre il LCP. Si può abbassare, con fetchpriority="low", un’immagine alta nel documento ma non visibile, per esempio una slide di un carosello che all’avvio non si vede. L’esempio è <img fetchpriority="low" src="/path/to/carousel-slide-3.webp">. La stessa frase chiede di controllare la priorità in DevTools e di provare il cambiamento con strumenti di laboratorio e di campo. Non ho aperto DevTools su un sito di terzi.

2,5 secondi non è un singolo test

La soglia, sulla pagina aggiornata il 31 marzo 2025, è doppia e va letta intera. Per una buona esperienza i siti dovrebbero tendere a un LCP di 2,5 secondi o meno per almeno il 75 per cento delle visite. Poi la pagina ripete: un buon valore di LCP è 2,5 secondi o meno. Non è «il mio Lighthouse ha fatto 2,4 una volta». Il 75 per cento è una quota di visite, non un singolo run. La guida dice anche che è raro che un solo ritocco, su un solo pezzo della pagina, sposti il LCP in modo significativo. Togliere lazy dall’immagine principale è uno dei pezzi, non l’intera pagina.

Il confronto con la cache HTTP è un altro piano. Una risposta 304 o un Cache-Control non decidono se il parser deve aspettare il layout prima di chiedere i byte dell’immagine. loading sta sull’elemento. La cache sta sulla risposta. Tenerli nello stesso elenco di «ottimizzazioni» senza distinguerli è il modo in cui il lazy finisce sull’hero.

Errori da evitare

• Mettere loading="lazy" sull’immagine che è il candidato LCP. web.dev dice che il ritardo c’è sempre e che il LCP peggiora.

• Credere che fetchpriority="high" spenga il lazy. Sono due attributi. La specifica non scrive che uno cancella l’altro.

• Alzare fetchpriority su tutte le immagini della pagina. La guida dice che oltre una o due il meccanismo non aiuta il LCP.

• Leggere l’esempio della specifica come una pagella. 4.jpeg non ha lazy, sta sotto il viewport, e parte comunque in eager.

• Trattare 2,5 secondi come il risultato di un solo test in laboratorio. La frase sul buon LCP parla del 75 per cento delle visite.

• Omettere width e height su un’immagine lazy e poi misurare il salto di layout come se fosse un altro bug. La nota dello standard lo mette tra le cause.

In sintesi

Il 27 ottobre 2026 web.dev, aggiornato il 31 marzo 2025, dice di non mettere loading="lazy" sull’immagine LCP: la risorsa aspetta che il layout confermi il viewport. Lo standard HTML, nell’esempio, fa partire in eager anche un file sotto la piega se l’attributo manca, e fa aspettare il layout a un file lazy già visibile, senza trattenerne l’evento load. fetchpriority="high" è la priorità del fetch, da usare sull’immagine che si pensa sia il LCP, non su tutte. Un buon LCP è 2,5 secondi o meno per almeno il 75 per cento delle visite. Non è un numero di tachimetro.

Foto di copertina: Anibal Clavel, «Speedometer showing 0 km/h», Wikimedia Commons, CC BY 3.0. Lo zero è una velocità, non un LCP e non un risultato di Lighthouse.