Largest Contentful Paint

Un aspetto importante da considerare è che il calcolo del LCP include diversi fattori che avvengono prima del caricamento effettivo dell’elemento, come il tempo impiegato per abbandonare la pagina precedente, i tempi di connessione, eventuali reindirizzamenti e il Time To First Byte (TTFB). Tutti questi componenti possono influenzare notevolmente le misurazioni, soprattutto quando vengono rilevate in ambienti reali rispetto a test effettuati in laboratorio.

Per garantire una buona esperienza utente, è consigliabile che il LCP si mantenga al di sotto dei 2,5 secondi. Questo obiettivo dovrebbe essere raggiunto nel 75° percentile delle visite, considerando sia i dispositivi mobili che quelli desktop, per offrire performance soddisfacenti alla maggior parte degli utenti.

In sintesi:

• Buono: ≤ 2,5 secondi
• Da migliorare: tra 2,5 e 4 secondi
• Scarso: > 4 secondi

Per maggiori dettagli sul ragionamento che porta a queste soglie, puoi consultare l’articolo sulle metriche Core Web Vitals.

Quali tipi di elementi influiscono sul LCP?

Secondo quanto definito dalle specifiche dell’API LCP, gli elementi considerati per questa metrica includono:

• Immagini img, incluse GIF e PNG animati (si considera il primo frame visibile)
• Immagini image contenute in un
• Video video (può contare il tempo di visualizzazione del frame iniziale o dell’immagine poster)
• Immagini di sfondo definite tramite url() nel CSS
• Blocchi di testo contenenti nodi testuali o elementi inline rilevanti

È importante notare che, per semplificare il calcolo e ridurre le ambiguità, l’elenco degli elementi eleggibili è volutamente ristretto. Con l’evoluzione degli standard, è possibile che vengano inclusi altri tipi di contenuto, ad esempio un supporto più esteso per SVG complessi.

Cosa viene escluso nelle misurazioni LCP?

Per evitare che vengano conteggiati elementi non significativi, i browser (in particolare quelli basati su Chromium) applicano delle euristiche per escludere:

• Elementi completamente trasparenti (opacità 0)
• Elementi che coprono interamente lo schermo e sembrano più uno sfondo che contenuto
• Immagini segnaposto o a bassa entropia, spesso poco rilevanti per l’utente

Queste regole aiutano a concentrare la misurazione su ciò che davvero conta per l’esperienza dell’utente.

Va anche detto che le euristiche di LCP sono diverse da quelle utilizzate per altre metriche come il First Contentful Paint (FCP). Quest’ultimo prende in esame il primo elemento visibile, indipendentemente dalla sua importanza, mentre il LCP si focalizza sul contenuto principale. Proprio per questo, LCP è considerata una metrica più selettiva e indicativa della qualità percepita.

Quando si misura il Largest Contentful Paint, le dimensioni prese in considerazione per l’elemento coinvolto si basano sull’area effettivamente visibile all’utente all’interno del viewport. Se una parte dell’elemento risulta fuori dallo schermo, nascosta o tagliata (overflow), quella porzione non viene conteggiata nella misurazione.

Nel caso delle immagini, se queste sono state ridimensionate rispetto alla loro dimensione originale (intrinseca), viene presa in considerazione la dimensione minore tra quella visibile e quella intrinseca.

Per quanto riguarda i blocchi di testo, il valore LCP considera il rettangolo più compatto che riesce a contenere tutti i nodi testuali visibili, ignorando spazi extra non occupati.

In tutti i casi, vengono esclusi margini, bordi e padding CSS dal calcolo della dimensione.

Durante il caricamento di una pagina web, il contenuto può comparire in momenti diversi. Questo significa che l’elemento più grande visibile può cambiare nel tempo, man mano che la pagina viene completata. Per tener conto di questi cambiamenti, il browser registra più volte il valore del Largest Contentful Paint, ogni volta che un nuovo elemento supera il precedente per dimensioni.

Il primo valore LCP viene segnalato non appena il browser mostra il primo frame visibile, indicando inizialmente l’elemento di maggiori dimensioni tra quelli già caricati (ad esempio un paragrafo tag p o un titolo h1). Tuttavia, se successivamente viene visualizzata un’immagine più grande (come una hero image), il browser aggiorna la misurazione con un nuovo valore LCP associato a quell’elemento img.

Un elemento viene considerato valido per il LCP solo se è già stato completamente renderizzato e risulta visibile all’utente. Le immagini ancora in fase di caricamento e i testi che utilizzano font web bloccati (durante il cosiddetto “font block period”) non vengono conteggiati finché non sono pienamente visibili. In questi casi, un elemento più piccolo potrebbe temporaneamente essere classificato come il più grande, finché non viene completato il rendering dell’elemento corretto.

La metrica viene aggiornata anche se vengono aggiunti nuovi elementi al DOM successivamente al primo caricamento. Se uno di questi risulta più grande rispetto a quelli precedenti, viene generata una nuova registrazione. Viceversa, se l’elemento più grande viene rimosso dal DOM o nascosto, continua a essere considerato il più grande finché non ne appare uno più grande visibile.

È importante sapere che il browser interrompe il tracciamento del LCP non appena l’utente interagisce con la pagina – ad esempio toccando, scorrendo o premendo un tasto – perché queste azioni possono modificare la porzione visibile del contenuto, influenzando così il contesto del caricamento.

In passato, per ragioni legate alla sicurezza, i browser non esponevano il momento esatto del rendering delle immagini provenienti da origini diverse (cross-origin), a meno che queste non specificassero l’intestazione HTTP Timing-Allow-Origin. In questi casi, veniva reso disponibile solo il tempo di caricamento, già accessibile tramite altre API web.

Il tempo di caricamento si riferisce al momento in cui la risorsa è completamente scaricata dal server. Tuttavia, tra il termine del download e la visualizzazione effettiva sullo schermo può intercorrere un breve intervallo, poiché il browser ha bisogno di elaborare la risorsa prima di mostrarla. In alcuni casi, ad esempio se la risorsa è precaricata o se ci sono ritardi nel rendering, questo intervallo può essere più significativo.

Questa differenza può generare confusione: ad esempio, può sembrare che il valore LCP venga registrato prima del First Contentful Paint (FCP). In realtà non succede, ma può sembrare così a causa del fatto che il timestamp fornito dalle API web riflette il caricamento e non il rendering.

A partire dalla fine del 2024, questo comportamento è stato aggiornato. Dalla versione 133 di Chrome, viene fornita una stima del tempo di rendering anche in assenza dell’intestazione Timing-Allow-Origin, sebbene con una precisione leggermente inferiore rispetto a quando l’intestazione è presente.

Per evitare un impatto negativo sulle prestazioni del browser, il meccanismo che misura il Largest Contentful Paint (LCP) non tiene conto di eventuali cambiamenti successivi alla posizione o alle dimensioni degli elementi. In altre parole, il browser considera solo la posizione e la grandezza iniziale dell’elemento nel momento in cui appare nell’area visibile della pagina (viewport).

Questo approccio ha due importanti conseguenze:

• Un’immagine inizialmente fuori dallo schermo, che viene visualizzata solo dopo uno scroll o un’animazione, non sarà considerata nel calcolo del LCP, anche se risulta essere l’elemento più grande.
• Un elemento che compare subito nel viewport, ma viene spinto verso il basso da modifiche al layout (ad esempio da contenuti che si caricano sopra), mantiene comunque il suo stato originario e resta valido come candidato LCP, anche se poi esce dall’area visibile.

Questa logica serve a ridurre il carico computazionale e garantire che la metrica LCP sia stabile e rappresentativa del primo impatto visivo percepito dall’utente.

Esempio 1 – Elemento inizialmente visibile poi spostato

<!DOCTYPE html>
<html lang="it">
<head> <meta charset="UTF-8"> <title>Esempio LCP - Elemento iniziale visibile</title> <style> body { margin: 0; font-family: sans-serif; } .hero { font-size: 3rem; background: #eee; padding: 100px; text-align: center; } .top-banner { background: orange; height: 100px; width: 100%; position: absolute; top: -100px; animation: slideDown 2s forwards; } @keyframes slideDown { to { top: 0; } } </style>
</head>
<body> <div class="top-banner"> Banner pubblicitario </div> <div class="hero"> Benvenuto nel nostro sito </div>
</body>
</html>

Esempio 2 – Elemento inizialmente fuori dallo schermo

<!DOCTYPE html>
<html lang="it">
<head> <meta charset="UTF-8"> <title>Esempio LCP - Elemento fuori schermo</title> <style> body { margin: 0; font-family: sans-serif; } .spacer { height: 1500px; } .large-image { width: 100%; max-width: 1000px; margin: 0 auto; } </style>
</head>
<body> <div class="spacer"> <!-- Spazio iniziale --> </div> <img src="https://via.placeholder.com/1000x600" class="large-image" alt="Immagine grande">
</body>
</html>

Il LCP può essere analizzato sia in ambienti di sviluppo che direttamente nel contesto reale degli utenti (dati sul campo). Per farlo, è possibile utilizzare una serie di strumenti già disponibili.

Strumenti per la misurazione sul campo:

• Chrome User Experience Report (CrUX): raccoglie dati anonimi sulle prestazioni reali degli utenti.
• PageSpeed Insights: mostra i dati CrUX e suggerimenti per l’ottimizzazione.
• Google Search Console (rapporti Core Web Vitals): offre una panoramica delle prestazioni aggregate del tuo sito.
• Libreria JavaScript web-vitals: consente di raccogliere metriche direttamente dal browser.

Strumenti per l’analisi in fase di sviluppo sito web:

• Chrome DevTools: utile per l’analisi dettagliata durante lo sviluppo.
• Lighthouse: effettua audit delle pagine web e segnala problemi di performance.
• PageSpeed Insights: oltre ai dati sul campo, esegue anche test di laboratorio.
• WebPageTest: offre visualizzazioni avanzate e replay video del caricamento.

È possibile monitorare il LCP anche direttamente via JavaScript, utilizzando l’API PerformanceObserver. Ecco un esempio di codice:

Il valore LCP può essere influenzato da diversi fattori lungo tutta la catena del caricamento della pagina. Ecco i principali:

Misurare il LCP tramite API può introdurre differenze rispetto alla metrica vista nei report ufficiali. Ecco alcune situazioni particolari:

• Se una pagina viene aperta in background, l’API può comunque generare voci, ma queste non vanno considerate nei calcoli.
• Se la pagina passa in background dopo il caricamento, nuove voci possono ancora essere inviate, ma andrebbero escluse per coerenza.
• In caso di navigazione tramite cronologia (avanti/indietro), l’API non registra nulla, ma la metrica dovrebbe comunque includere quelle visite.
• L’API non rileva contenuti all’interno di iframe, mentre la metrica ufficiale sì.
• In presenza di pagine precaricate, l’API parte dal momento iniziale della navigazione, ma il LCP andrebbe conteggiato solo dall’attivazione dell’utente.

E se l’elemento più grande non fosse quello più importante?

Capita che l’elemento considerato “più grande” dal browser non sia quello davvero rilevante dal punto di vista dell’utente. In questi casi, puoi usare l’API Element Timing per misurare i tempi di rendering di specifici elementi personalizzati.
Per evitare complicazioni, è consigliato usare la libreria web-vitals, che gestisce automaticamente molte di queste eccezioni:

1. Eliminare il ritardo nel caricamento della risorsa LCP

Uno dei primi fattori da ottimizzare per migliorare il Largest Contentful Paint (LCP) è assicurarsi che la risorsa coinvolta (spesso un’immagine o un font) venga avviata nel caricamento il prima possibile.

Obiettivo: avvio del caricamento subito dopo il TTFB
Idealmente, la richiesta della risorsa LCP dovrebbe partire immediatamente dopo il Time To First Byte (TTFB). Tuttavia, in molti casi si verifica un ritardo dovuto a parsing HTML, blocchi CSS o altre dipendenze non ottimizzate.

Come riferimento, la risorsa LCP dovrebbe iniziare il caricamento nello stesso istante della prima risorsa richiesta dalla pagina. Se ciò non avviene, è molto probabile che vi sia un margine di miglioramento nell’ottimizzazione.

Quando il browser scopre la risorsa LCP

Il browser può iniziare a scaricare una risorsa solo dopo averla rilevata nel flusso HTML. Questo processo dipende dal preload scanner del browser e da come la risorsa è referenziata. I casi ottimali includono:

• Un tag img con attributi src o srcset presenti direttamente nel markup iniziale.
• Un’immagine di background caricata in modo esplicito tramite link rel=”preload”.
• Un font web necessario per un nodo di testo visibile, anch’esso precaricato tramite preload.

Esempio di preload corretto:

<link rel="stylesheet" href="/styles/main.css"> <link rel="preload" as="image" href="/images/lcp.webp" type="image/webp" fetchpriority="high">

Casi problematici da evitare

Ci sono situazioni in cui la risorsa LCP non è visibile al preload scanner e viene quindi caricata in ritardo. Esempi comuni includono:

• Tag img aggiunto dinamicamente via JavaScript.
• Lazy loading tramite data-src, data-srcset o tecniche di progressive enhancement.
• Background image CSS non precaricati.

In questi scenari, il browser deve attendere l’elaborazione di script o CSS prima di iniziare il download, generando un ritardo critico nel percorso di rendering.

Strategia consigliata: rendi la risorsa LCP immediatamente visibile al browser

Se la risorsa non è contenuta direttamente nell’HTML iniziale, va precaricata con priorità elevata. L’esempio seguente mostra un preload esplicito per un’immagine LCP:

<link rel="preload" fetchpriority="high" as="image" href="/path/to/hero-image.webp" type="image/webp">

Il caricamento tempestivo della risorsa LCP è una delle azioni più impattanti per migliorare la metrica. Ottimizza visibilità e priorità per garantire che la richiesta parta subito, riducendo al minimo ogni blocco nella catena critica di caricamento.

2. Ridurre il ritardo di rendering dell’elemento LCP

Anche se la risorsa LCP viene caricata rapidamente, non è detto che venga visualizzata immediatamente. Diverse condizioni possono impedire al browser di eseguire il rendering dell’elemento, anche se i byte sono già arrivati.

Cause comuni del rendering ritardato:

• CSS bloccante presente nell’ head, non ancora scaricato o processato.
• Script sincroni che bloccano la costruzione del DOM.
• L’elemento LCP non è ancora stato inserito nel DOM (es. generato via JavaScript).
• L’elemento è nascosto temporaneamente (es. per test A/B, effetti fade-in, slider non visibili).
• Il main thread è occupato da esecuzioni JS pesanti o layout complessi.

Per ridurre questo tipo di ritardi, dobbiamo intervenire su CSS, JavaScript e manipolazioni DOM.

Ottimizzare il caricamento degli stili CSS

I fogli di stile sono render-blocking per impostazione predefinita. Se uno stile è molto grande, potrebbe impiegare più tempo della risorsa LCP a caricarsi e impedirne la visualizzazione.
Soluzioni possibili:

• Inline critical CSS per ridurre richieste HTTP.
• Minimizzazione e compressione dei CSS.
• Rimozione del CSS non utilizzato con strumenti come Coverage di Chrome DevTools.
• Lazy loading del CSS non critico.

Esempio di inserimento in linea di un foglio di stile critico:

<style> /* Critical CSS */ .hero-banner { background-color: #fff; height: 100vh; } </style>

Quando non conviene fare inline CSS

Se lo stile è molto voluminoso, non è consigliato inserirlo inline, poiché impedirebbe al browser di sfruttare la cache nei caricamenti successivi. In questi casi è preferibile ottimizzare il file CSS esterno e assicurarne un caricamento anticipato e veloce.

Minimizzare il blocco del rendering causato da JavaScript

Gli script sincroni (script senza async o defer) bloccano l’analisi e il rendering dell’HTML. Questo può posticipare l’inserimento e la visualizzazione dell’elemento LCP.
Da evitare:

<head> <script src="/path/to/main.js"></script> </head>

<head> <script async src="/path/to/main.js"></script> </head>

<head> <script> // Inline JS molto leggero document.documentElement.classList.add('js-enabled'); </script> </head>

Usa il Server-Side Rendering (SSR) o Static Site Generation (SSG)

Uno dei modi più efficaci per ridurre il ritardo di rendering è generare il contenuto lato server, così che l’elemento LCP sia già presente nel documento HTML e non richieda JS per comparire.

Vantaggi principali:

• L’elemento LCP è già nel DOM all’arrivo dell’HTML.
• Nessuna attesa per l’esecuzione di JavaScript o per il popolamento dinamico.

Suddividere le attività lunghe (Long Tasks)

Un’altra fonte di ritardo nel rendering dell’elemento LCP è l’occupazione del main thread da parte di script pesanti o parsing di file JS voluminosi. Questo può impedire al browser di eseguire il rendering anche se tutte le risorse sono pronte.
Strumenti consigliati:

• Chrome DevTools → Performance → Main Thread
• Lighthouse → Avoid long main-thread tasks

Se individui attività JS superiori a 50ms, valuta la suddivisione in chunk asincroni, il code splitting o l’utilizzo di requestIdleCallback.

Garantire il caricamento della risorsa LCP non basta: è essenziale assicurarsi che l’elemento sia effettivamente renderizzato appena possibile. Ottimizzare CSS, JavaScript e DOM è cruciale per eliminare ogni ritardo non necessario nel processo di visualizzazione.

3. Ridurre la durata del caricamento della risorsa LCP (Resource Load Duration)

Anche se la risorsa LCP viene richiesta rapidamente e il suo rendering non è bloccato, la velocità con cui i byte arrivano al dispositivo dell’utente è determinante. Questo tempo dipende da fattori come dimensione della risorsa, latenza di rete, congestione della connessione e caching.

Obiettivo: minimizzare il tempo di trasferimento dati

La Resource Load Duration rappresenta il tempo compreso tra l’inizio e la fine del download della risorsa LCP. Ecco le quattro leve principali su cui agire:

• Ridurre la dimensione effettiva della risorsa
• Minimizzare la distanza (in senso di latenza) tra server e utente
• Limitare la concorrenza sulla banda
• Eliminare del tutto il download tramite meccanismi di cache

Ridurre la dimensione della risorsa

La LCP è solitamente un’immagine o, meno spesso, un font web. Ridurre il suo peso è una delle ottimizzazioni più dirette.
Tecniche consigliate:

• Usa formati immagine moderni (WebP, AVIF)
• Comprimi le immagini (lossless o lossy, secondo contesto)
• Scala correttamente le dimensioni in base al container
• Esegui il subsetting dei font per includere solo i glifi necessari
• Applica compressione GZIP o Brotli lato server

Ridurre la latenza con una CDN

Per accelerare la consegna della risorsa, avvicina fisicamente i dati all’utente utilizzando una Content Delivery Network (CDN).

I vantaggi sono doppi:

• Riduzione della latenza grazie alla prossimità dei nodi
• Ottimizzazione automatica delle immagini lato edge (ridimensionamento, compressione, webp fallback)

Limitare la concorrenza per la banda

Quando troppe risorse competono per la stessa larghezza di banda, anche la LCP può subire ritardi, nonostante la priorità elevata.

Soluzioni:

• Usa fetchpriority=”high” solo su 1–2 asset fondamentali
• Posticipa immagini secondarie (fetchpriority=”low”)
• Rimuovi richieste non necessarie all’avvio

Esempio di immagine secondaria con priorità bassa:

<img fetchpriority="low" src="/img/carousel-slide-3.webp" alt="Slide 3">

Eliminare completamente la rete: usa la cache

Il miglior caricamento è nessun caricamento!
Se configuri correttamente gli header di caching (es. cache-control: max-age=31536000, immutable), le richieste successive non dovranno scaricare nuovamente la risorsa.
Altre strategie utili:

• Preload persistente via Service Worker
• Cache del browser + fingerprinting del filename (/ img/ hero.abc123. webp)
• Preload nel primo paint + long term cache nei successivi

Inserire piccole immagini inline

Se la risorsa LCP è molto leggera (es. icona SVG o img base64), puoi inlinearla nel documento per eliminare la richiesta di rete.

<img src="data:image/webp;base64,UklGRiIAAABXRUJQVlA4TCEAAA..." alt="Inline image">

• Non cacheabile tra le visite
• Decodifica più pesante per il browser
• Usare solo per immagini < 1–2 KB

La Resource Load Duration può sembrare marginale rispetto ad altre componenti dell’LCP, ma in pagine con connessioni lente o molte richieste simultanee può fare la differenza. Investire nell’ottimizzazione delle dimensioni, della latenza e della competizione per la banda può portare a guadagni tangibili in page speed.

4. Ridurre il Time To First Byte (TTFB)

Il TTFB rappresenta il tempo che intercorre tra la richiesta dell’utente e la ricezione del primo byte del documento HTML. È il punto di partenza per tutte le metriche core web vitals, compreso LCP.
TTFB elevato = tutto il resto è in ritardo
Un TTFB lento rallenta:

• Il parsing dell’HTML
• La scoperta delle risorse (LCP compresa)
• Il caricamento e il rendering iniziale

Le cause più comuni di TTFB alto

• Troppi reindirizzamenti
• Tempi di elaborazione lato server elevati
• CDN o edge server non configurati correttamente
• Cache mancante o inefficace
• Query al database pesanti o non ottimizzate
• Contenuti generati dinamicamente anche per utenti anonimi

Best practice per abbassare il TTFB

Elimina reindirizzamenti superflui
Ogni 301 o 302 aggiunge round-trip network time. Evita catene come:
http → www → https → canonical URL finale
Configura le regole di riscrittura per portare il visitatore direttamente alla versione finale della pagina.
Implementa una cache a più livelli

• Edge cache (CDN): per rispondere più vicino all’utente
• Reverse proxy (es. Varnish): per alleggerire l’app server
• OpCode cache (es. OPcache per PHP): per evitare la recompilazione
• Application cache (es. Redis, Memcached): per risposte dinamiche

Attiva la cache anche per HTML dinamico
Se servite contenuti simili per la maggior parte dei visitatori (es. homepage, blog, categorie), abilita la cache HTML anche per utenti non loggati.

cache-control: public, max-age=300, s-maxage=600

• Ottimizza query SQL con indici e caching
• Usa tecniche come Static Site Generation (SSG) quando possibile
• Ottimizza il routing lato backend: meno logica, meno delay

Sfrutta i CDN per servire direttamente l’HTML
Con alcune architetture (es. JAMstack, Next.js, Nuxt), puoi usare CDN come Cloudflare, Fastly o Netlify per distribuire direttamente il documento HTML.
Strumenti per misurare il TTFB

• Chrome DevTools → Network → colonna TTFB
• Lighthouse → Audit TTFB (in ms)
• WebPageTest → dettagli rete
• Google Search Console (esperienza su pagina)

TTFB e campagne ADV
Un TTFB elevato impatta in modo critico sulle landing page di Google Ads, poiché:

• Riduce il quality score
• Aumenta il bounce rate
• Penalizza LCP e FCP

Il TTFB è l’unico sottocomponente LCP che non dipende dal frontend, ma dalla risposta iniziale del server. Migliorarlo significa agire su caching, configurazione CDN, query DB e routing logico. È un’ottimizzazione ad alto impatto, soprattutto per pagine ad alto traffico o promosse tramite ADV.

5. Monitorare il Largest Contentful Paint con JavaScript

Per analizzare le performance reali e ottimizzare in modo mirato, è utile tracciare i singoli sottocomponenti che compongono l’LCP:

• Time to First Byte (TTFB)
• Resource Load Delay
• Resource Load Duration
• Element Render Delay

Questi dati possono essere raccolti con JavaScript, usando le API di performance native del browser.
API coinvolte

• PerformanceObserver
• PerformanceNavigationTiming
• PerformanceResourceTiming
• PerformanceMeasure

Codice completo per la misurazione avanzata LCP

Questo script traccia e stampa nella console i dettagli di ogni sottoparte dell’LCP, inclusa la durata e la percentuale rispetto all’LCP totale.

const LCP_SUBPARTS = [ 'Time to first byte', 'Resource load delay', 'Resource load duration', 'Element render delay', ]; new PerformanceObserver((list) => { const lcpEntry = list.getEntries().at(-1); const navEntry = performance.getEntriesByType('navigation')[0]; const lcpResEntry = performance .getEntriesByType('resource') .filter((e) => e.name === lcpEntry.url)[0]; // Ignora elementi non immagine (es. testo), opzionale if (!lcpEntry.url) return; const ttfb = navEntry.responseStart; const lcpRequestStart = Math.max( ttfb, lcpResEntry ? lcpResEntry.requestStart || lcpResEntry.startTime : 0 ); const lcpResponseEnd = Math.max( lcpRequestStart, lcpResEntry ? lcpResEntry.responseEnd : 0 ); const lcpRenderTime = Math.max( lcpResponseEnd, lcpEntry ? lcpEntry.startTime : 0 ); // Pulisce eventuali misurazioni precedenti LCP_SUBPARTS.forEach((part) => performance.clearMeasures(part)); const lcpSubpartMeasures = [ performance.measure(LCP_SUBPARTS[0], { start: 0, end: ttfb }), performance.measure(LCP_SUBPARTS[1], { start: ttfb, end: lcpRequestStart }), performance.measure(LCP_SUBPARTS[2], { start: lcpRequestStart, end: lcpResponseEnd }), performance.measure(LCP_SUBPARTS[3], { start: lcpResponseEnd, end: lcpRenderTime }), ]; console.log('LCP value: ', lcpRenderTime); console.log('LCP element: ', lcpEntry.element, lcpEntry.url); console.table( lcpSubpartMeasures.map((measure) => ({ 'LCP subpart': measure.name, 'Time (ms)': measure.duration, '% of LCP': `${Math.round((1000 * measure.duration) / lcpRenderTime) / 10}%`, })) ); }).observe({ type: 'largest-contentful-paint', buffered: true });

• Il codice funziona solo per immagini con CORS abilitato o header Timing-Allow-Origin.
• Se l’elemento LCP è testuale (e non immagini), alcuni dati potrebbero mancare.
• La libreria web-vitals include già questa logica nativamente.
• Puoi inviare i dati raccolti a strumenti RUM personalizzati, come Google Analytics 4, DataDog, New Relic, ecc.

Analisi visuale in DevTools

Una volta attivato il codice, puoi aprire Chrome DevTools → Performance tab, eseguire una registrazione e osservare:

• Traccia temporale dettagliata nel canale “Timings”
• Sovrapposizione con “Main Thread” e “Network”
• Misurazioni User Timing leggibili e correlate tra loro

Il monitoraggio avanzato dell’LCP ti permette di spacchettare ogni fase del caricamento visivo e di capire dove intervenire. Se gestisci un sito ad alto traffico, avere questi dati in tempo reale ti dà un enorme vantaggio per ottimizzare, testare e prevenire regressioni di performance.