LCP request discovery in Lighthouse: controlli e fix

Cosa indica LCP request discovery sull'immagine LCP?

LCP request discovery è l'insight di Lighthouse 13 che ha sostituito "Preload Largest Contentful Paint image" e "Largest Contentful Paint image was lazily loaded". Verifica se l'immagine LCP, la foto principale che i visitatori aspettano, è individuabile dall'HTML: se cioè il browser ha potuto iniziare a scaricarla appena arrivato l'HTML, con priorità alta. La soluzione: la foto come <img> nell'HTML, senza loading="lazy", con fetchpriority="high".

Vuoi subito la soluzione rapida? Salta a WordPress, ai page builder, a Shopify o a Next.js.

Cosa significano i tre controlli di LCP request discovery?

In Lighthouse 13 e PageSpeed Insights l'avviso recita: "Optimize LCP by making the LCP image discoverable from the HTML immediately, and avoiding lazy-loading". Sotto compaiono tre controlli, ciascuno verde o rosso.

L'avviso per la home page di un hotel la cui foto principale ha loading="lazy". Lighthouse 13.6 con throttling di DevTools.

• fetchpriority=high should be applied: il browser ha richiesto l'immagine LCP senza fetchpriority="high". Quando la foto arriva tramite un preload, il controllo recita "fetchpriority=high should be applied to the image preload request": serve anche al preload. Quando il controllo passa, indica "fetchpriority=high applied".
• Request is discoverable in initial document: l'URL della foto si trova nell'HTML stesso, in un <img> o in un preload, dove il preload scanner (la parte del browser che legge in anticipo l'HTML) può trovarlo. Un'immagine di sfondo in un foglio di stile, uno slider che costruisce le slide con JavaScript o uno script di lazy loading che ha spostato l'URL in data-src rendono rosso questo controllo.
• LCP resources shouldn’t use loading=lazy: la foto ha loading="lazy", quindi il browser la richiede solo quando il layout mostra che è a schermo.

Basta un controllo rosso per rendere rosso l'avviso. L'elemento LCP in basso, una miniatura con il relativo HTML, mostra quale elemento Lighthouse ha misurato sullo schermo di uno smartphone. Unscored significa che l'avviso non assegna punti di per sé, ma il LCP vale un quarto del punteggio di Performance, e per il ranking Google si basa sui dati dei visitatori reali. L'avviso compare solo se l'elemento LCP è un'immagine: un <img>, uno sfondo CSS o il poster di un video.

Perché un'immagine LCP in ritardo rallenta la pagina?

Su smartphone, il visitatore vede il titolo e il testo attorno a uno spazio vuoto destinato alla foto grande, per un secondo o più.

Durante il download dell'HTML, il preload scanner di Chrome legge il codice in anticipo e richiede ogni immagine presente nel src o srcset di un <img> privo di loading="lazy": è il momento più rapido in cui una foto può partire. Qualsiasi altra foto parte dopo: in un foglio di stile attende quel file e il layout; in un attributo style o con loading="lazy" attende il layout, che richiede prima ogni foglio di stile render blocking; uno slider o uno script di lazy loading deve prima scaricarsi ed eseguirsi per poter richiedere la foto.

Quell'attesa, il resource load delay, dura di solito più del download stesso: nel sito mediano con un LCP scarso, l'immagine attende 1.290 ms e poi si scarica in 350 ms (web.dev).

Sulla home page di un hotel creata come un sito WordPress con page builder, ho inserito la stessa foto in sette modi diversi e ho caricato ciascuna variante su uno smartphone con throttling:

Mediana di cinque caricamenti, in secondi, su rete Slow 4G con CPU 4x più lenta. L'HTML è arrivato a 0,58 s in ogni test.

Ogni versione caricava la stessa foto da 63 kB, tranne quella con l'attributo style, che non può passare al file più piccolo per smartphone. A fare la differenza è stato il momento di avvio della richiesta: la foto nell'HTML è stata richiesta appena arrivato l'HTML, mentre le altre hanno atteso il first paint a 1,7 s o gli script a 2,4 s.

La pagina dell'hotel dopo 2,5 secondi di caricamento sullo stesso smartphone con throttling.

fetchpriority="high" segnala a Chrome fin dal primo istante che questa immagine è prioritaria, riservandole una quota maggiore della connessione. Su una pagina complessa, dove la foto compete con decine di script e fogli di stile, questo può velocizzare il LCP: Google ha misurato un calo da 2,6 s a 1,9 s su Google Flights. Aiuta però solo una foto che il browser ha già individuato: per una foto inserita in un foglio di stile o in uno script serve prima la modifica nell'HTML.

Perché fetchpriority=high è ancora rosso quando l'immagine include l'attributo?

Il controllo analizza la richiesta che ha caricato l'immagine LCP. Cerca nel sorgente della pagina, da utente disconnesso, il nome del file della foto. Le cause più comuni (soluzioni in basso):

• Un preload che non hai impostato tu. Un tema, l'hosting o una CDN possono inviare un preload per la foto in un header Link o tramite 103 Early Hints; un plugin di cache o Next.js aggiunge un <link rel="preload"> nell'head. Per verificare gli header, apri il pannello Network in DevTools, clicca sulla prima richiesta (la pagina stessa) e controlla Headers.
• Un plugin di lazy loading ha riscritto l'immagine. Se anche il controllo sull'individuazione è rosso, cerca data-src o data-lazy-src sulla foto: un plugin ha spostato l'URL lì e uno script richiede la foto più tardi.
• WordPress ha assegnato l'attributo a un'altra immagine. WordPress aggiunge fetchpriority="high" alla prima immagine grande nella prima schermata (50.000 pixel o più). Un logo caricato a risoluzione doppia, ad esempio 600 per 200 pixel, compare prima e se ne appropria.
• Lighthouse ha misurato un'immagine diversa. L'elemento LCP in fondo all'avviso mostra quale. Su smartphone può trattarsi di una hero separata per mobile, con la foto desktop nascosta via CSS e l'attributo rimasto su quest'ultima.

La pagina dell'hotel con uno script di lazy loading: due controlli rossi. Lighthouse 13.6 con throttling di DevTools.

Quanto attendono i visitatori per l'immagine LCP?

I field data mostrano quanto attendono i visitatori reali. Su CoreDash, apri LCP Breakdown per mobile e seleziona LCP Priority sotto More dimensions: ogni riga rappresenta una modalità di caricamento dell'immagine LCP, con il relativo LCP al p75 suddiviso nelle sue parti. La parte verde è il load delay, l'attesa tra l'arrivo dell'HTML e l'inizio del download dell'immagine. Raggruppa per URL per trovare il template in cui questa attesa è lunga.

CoreDash su mobile, p75: confronta la parte verde di ogni riga di LCP Priority.

Come vedere in DevTools quanto è partita in ritardo l'immagine?

Registra una traccia della pagina nel pannello Performance di Chrome DevTools e apri LCP request discovery nella barra laterale Insights. Nella mia pagina di test dell'hotel, con la foto impostata come sfondo nel foglio di stile del page builder, l'insight mostra quanto tempo dopo il primo byte dell'HTML (il suo "earliest start point") è partita la richiesta della foto. La barra a strisce nella traccia Network evidenzia questa attesa.

La richiesta della foto parte dopo i fogli di stile. Chrome DevTools, pannello Performance, smartphone con throttling.

Nel pannello Network, la colonna Initiator accanto alla foto indica il file che l'ha richiesta: un foglio di stile, lo script di uno slider, oppure l'HTML se è partita in tempo.

Come risolvere LCP request discovery?

Cerca il nome del file della foto nel sorgente della pagina. Nel src o srcset di un <img> il browser la trova subito; in un data-src, in un foglio di stile o da nessuna parte: ecco cosa devi modificare. L'obiettivo ovunque: la foto come <img> nell'HTML, senza loading="lazy", con fetchpriority="high", solo su quell'immagine specifica. Aggiungi fetchpriority="high" a un preload che non hai impostato tu, oppure disattivalo. Sostituisci una hero mobile separata con una sola foto per entrambi gli schermi, oppure usa un <picture> con un <source> per il file per smartphone e fetchpriority="high" sul relativo <img>.

WordPress e i plugin di lazy loading

WordPress esclude le prime immagini dal lazy loading e assegna fetchpriority="high" alla prima immagine grande. Se l'avviso è ancora rosso, di solito un plugin sovrascrive questo comportamento:

• WP Rocket: Optimize Critical Images, attivo di default, rileva l'immagine LCP dalle visite reali, ne esegue il preload con fetchpriority="high" e la esclude da LazyLoad. Esegui nuovamente il test dopo la ricostruzione della cache.
• Perfmatters: imposta Exclude Leading Images e Preload Critical Images sul numero di immagini presenti nella prima schermata su smartphone, spesso una sola.
• LiteSpeed Cache: aggiungi il nome del file della foto a Lazy Load Image Excludes, oppure attiva Viewport Images.
• FlyingPress: verifica che la foto abbia loading="eager" e un preload; in caso contrario, escludila dal lazy loading.

Carica il logo alle dimensioni esatte con cui viene mostrato, così l'attributo andrà alla foto. Mantieni un solo meccanismo di lazy loading, altrimenti la foto rimarrà differita dopo averla esclusa da uno dei due. Nel blocco Cover, Fixed background trasforma la foto in uno sfondo dentro un attributo style: disattivalo e la foto tornerà a essere un <img>. Il mio plugin WP Core Web Vitals rileva l'immagine LCP per dimensione dello schermo in base ai visitatori e la carica per prima, ad alta priorità.

Elementor e altri page builder

Una foto impostata come sfondo di un Container o di una Section di Elementor finisce nel CSS di Elementor, quindi il browser la trova solo dopo quel CSS e il layout. Usa un widget Immagine per la foto hero (una hero di Elementor con un'immagine); a quel punto Optimized Image Loading (Settings, Performance) la gestirà come fa WordPress. Lazy Load Background Images, attivo di default, può frenare una hero di sfondo posizionata sotto una barra di notifica. Anche negli altri builder, usa un elemento immagine per la prima foto.

Slider

La prima slide deve essere un <img> nell'HTML, senza loading="lazy", con fetchpriority="high"; le altre slide avranno loading="lazy" e fetchpriority="low". Uno slider che costruisce le slide con JavaScript avvia la prima slide solo dopo l'esecuzione dello script: usane uno che inserisca la prima slide nell'HTML, oppure mostra una sola foto su smartphone. Nel widget Image Carousel di Elementor, l'opzione Lazyload sposta l'URL di ogni slide in data-src: disattivala.

Shopify

Dawn, Horizon e i temi basati su di essi assegnano fetchpriority="high" all'immagine nella prima sezione del template e la caricano subito: imposta quindi il banner o lo slideshow come prima sezione. Sulle pagine prodotto di Dawn la foto principale è priva di fetchpriority: in snippets/product-thumbnail.liquid, aggiungi fetchpriority: 'high' a image_tag quando lazy_load è false (la prima foto). L'aggiornamento del tema può sostituire questo file: ricontrolla l'attributo dopo l'aggiornamento. Una hero creata da un'app tramite JavaScript parte in ritardo a prescindere dal tema: usa una sezione del tema.

Negli altri temi, cerca nel file della sezione loading: 'lazy' o una classe lazyload con data-src, e imposta la priorità in base alla posizione della sezione:

{%- liquid
  assign fetch_priority = 'auto'
  if section.index == 1
    assign fetch_priority = 'high'
  endif
-%}
{{ section.settings.image | image_url: width: 1600 | image_tag: widths: '750, 1100, 1600', sizes: '100vw', fetchpriority: fetch_priority }}

Senza un parametro loading, image_tag applica il lazy loading alle immagini a partire dalla quarta sezione.

Immagini di sfondo CSS

Senza un'opzione immagine nel tema o nel builder, serve uno sviluppatore. Converti prima lo sfondo in un <img>: il browser lo troverà nell'HTML, e srcset permetterà a ogni schermo di scegliere il proprio file. object-fit riempirà lo spazio esattamente come faceva lo sfondo:

<section class="hero">
  <img class="hero-img" src="/wp-content/uploads/2026/10/terrace-1024.jpg"
    srcset="/wp-content/uploads/2026/10/terrace-768.jpg 768w, /wp-content/uploads/2026/10/terrace-1024.jpg 1024w, /wp-content/uploads/2026/10/terrace-1600.jpg 1600w"
    sizes="100vw" width="1600" height="1067" alt="Terrace above the sea" fetchpriority="high">
</section>

.hero { position: relative; }
.hero-img { position: absolute; inset: 0; width: 100%; height: 100%; object-fit: cover; }

Se deve rimanere uno sfondo, fai il preload del file che il CSS sceglie per ciascuna dimensione dello schermo, usando le stesse media query del CSS e fetchpriority="high"; un preload per un file diverso scarica la foto due volte. Aggiungilo solo al template di quella pagina. Per un CSS che passa al file da 768 px sotto i 768 px:

<link rel="preload" as="image" href="/wp-content/uploads/2026/10/terrace-768.jpg" media="(max-width: 767px)" fetchpriority="high">
<link rel="preload" as="image" href="/wp-content/uploads/2026/10/terrace-1600.jpg" media="(min-width: 768px)" fetchpriority="high">

Next.js, Astro e React

next/image applica il lazy loading di default. A partire da Next.js 15, priority (preload nella versione 16) rende l'immagine eager e ne esegue il preload senza fetchpriority, lasciando il controllo in rosso. Imposta entrambi manualmente, senza priority:

<Image src={hero} alt="Terrace above the sea" sizes="100vw" loading="eager" fetchPriority="high" />

In Astro 5.10 e versioni successive, la prop priority su <Image> imposta entrambi gli attributi. Una hero renderizzata da React nel browser esiste solo dopo l'esecuzione di JavaScript: effettua il rendering sul server o il prerendering della pagina, così che il tag <img> sia nell'HTML.

Una hero che non puoi modificare

Un test A/B che sostituisce la foto o un widget che genera la hero tramite JavaScript ne ritardano l'avvio. Se l'URL della foto non cambia, un preload con fetchpriority="high" nel tuo template ne anticipa l'avvio. Su un server lento, 103 Early Hints può avviare una foto che usa lo stesso file su ogni schermo prima dell'arrivo dell'HTML. In entrambi i casi serve uno sviluppatore.

L'immagine LCP parte ora insieme all'HTML?

Esegui di nuovo Lighthouse: tre controlli verdi e la tua foto come elemento LCP. In DevTools la richiesta della foto parte subito dopo l'HTML. Controlli superati, ma il LCP è ancora lento? Analizza le altre parti del LCP: un server lento (time to first byte), una foto che impiega troppo tempo a scaricarsi (load duration), o fogli di stile e script che ritardano il paint (render delay). Per i visitatori reali, monitora il load delay su smartphone in CoreDash; Search Console impiega fino a 28 giorni.

Una Core Web Vitals power hour serve per la foto che questa guida non può raggiungere: quella inserita da un page builder, da uno slider o da un'app priva di impostazioni dedicate, o una foto che supera tutti e tre i controlli mentre il LCP su smartphone resta lento. La seguiamo lungo la traccia della tua pagina, dall'HTML allo schermo, e individuiamo cosa la frena.