Ottimizzare l'LCP Element Render Delay

Dal download alla visualizzazione: impara come migliorare la parte del ritardo di rendering dell'elemento del Largest Contentful Paint.

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-03-03
  1. It
  2. Core Web Vitals
  3. Largest contentful paint
  4. Element render delay

Questa guida fa parte della sezione Largest Contentful Paint (LCP) del nostro centro risorse Core Web Vitals. L'Element Render Delay è la fase finale nella sequenza temporale dell'LCP, che rappresenta il divario tra il completamento del download della risorsa LCP e la sua visibilità sullo schermo (painted).

Ottimizzare l'LCP Element Render Delay

Delle quattro fasi del LCP, l'Element Render Delay è la più incompresa. I team ottimizzano il TTFB, eliminano il Resource Load Delay e comprimono gli asset per abbreviare la Resource Load Duration. Vedono terminare la cascata di rete (network waterfall) e presumono che il lavoro sia finito. Si sbagliano.

L'Element Render Delay è il tempo che intercorre dal termine del download della risorsa LCP fino a quando l'elemento non viene completamente visualizzato sullo schermo dell'utente. Questo non è un problema di rete; è un problema del main thread. Un render delay elevato significa che il browser possiede l'immagine o il font, ma è troppo occupato con altre attività per disegnarlo. Questo ritardo è una tassa diretta sul tuo punteggio LCP, e a volte aggiunge 200ms o più dopo che tutte le richieste di rete sono state completate.

Definizione Precisa: Il Problema dell'Ultimo Miglio

L'Element Render Delay inizia nel momento in cui l'ultimo byte della risorsa LCP (ad es. un file immagine o un web font) arriva al browser. Termina quando l'elemento LCP è visibilmente disegnato (painted) sullo schermo. È, letteralmente, l'ultimo passo.

Per gli elementi LCP basati su testo che utilizzano un font di sistema, questo ritardo è spesso zero, poiché non è necessaria alcuna risorsa esterna. Tuttavia, per la stragrande maggioranza dei siti in cui l'elemento LCP è un'immagine o utilizza un web font personalizzato, questa fase è spesso il collo di bottiglia principale. Il browser trascorre questo tempo in attività legate alla CPU: tradurre i bit scaricati in pixel visibili.

Il 'Perché': Una Catena di Montaggio Bloccata

Per risolvere il render delay, devi capire come un browser disegna una pagina. È un processo a più stadi spesso chiamato Critical Rendering Path. Pensalo come una catena di montaggio in una fabbrica:

  1. Costruzione dei Progetti (DOM & CSSOM): Il browser analizza (parse) l'HTML per costruire il Document Object Model (DOM) e il CSS per costruire il CSS Object Model (CSSOM). Questi sono i progetti per il contenuto della pagina e il suo stile.
  2. Combinazione dei Progetti (Render Tree): Il DOM e il CSSOM sono combinati in un Render Tree, che contiene solo i nodi necessari per visualizzare la pagina. Elementi come <head> o quelli con display: none; vengono omessi.
  3. Calcolo della Geometria (Layout): Il browser calcola le dimensioni esatte e la posizione di ogni elemento nel render tree. Questa fase è nota anche come "reflow".
  4. Colorazione dei Pixel (Paint): Il browser riempie i pixel per ogni elemento, considerando testo, colori, immagini, bordi e ombre.
  5. Assemblaggio dei Livelli (Composite): La pagina viene disegnata su diversi livelli (layers), che vengono poi assemblati nell'ordine corretto per creare l'immagine finale sullo schermo.

L'Element Render Delay è il tempo consumato da queste fasi finali: Layout, Paint e Composite. L'intera catena di montaggio è gestita da un singolo lavoratore: il main thread. Se quel lavoratore è occupato ad eseguire una lunga attività JavaScript o ad analizzare un enorme file CSS, la catena di montaggio si ferma. L'immagine LCP potrebbe essere arrivata, ma è ferma nella banchina di carico in attesa che il main thread si liberi per elaborarla e disegnarla.

Come Individuare l'Element Render Delay

La diagnosi di questo problema segue un rigoroso processo in due fasi. Non saltare il primo passaggio.

Fase 1: Convalida con i Dati sul Campo (RUM)
Prima di aprire i DevTools, devi confermare che l'Element Render Delay sia un problema reale per i tuoi utenti effettivi. Uno strumento di Real User Monitoring (RUM) professionale come il mio, CoreDash, è essenziale. Questo suddividerà l'LCP del tuo sito nelle sue quattro sottoparti. Se i tuoi dati RUM mostrano un Element Render Delay significativo al 75° percentile, hai un problema convalidato e ad alto impatto da risolvere.

Fase 2: Diagnosi con DevTools
Una volta che il RUM ha identificato le pagine con problemi, utilizza il pannello Performance dei Chrome DevTools per analizzare la causa.

  1. Vai alla scheda Performance e abilita la casella di controllo "Web Vitals".
  2. Fai clic sul pulsante "Record and reload page".
  3. Nella traccia "Timings", fai clic sul marcatore LCP. La scheda "Summary" in basso mostrerà la durata precisa di ciascuna delle quattro fasi dell'LCP. Prendi nota del valore dell'Element render delay.
  4. Ora, esamina la traccia Main nella sequenza temporale (timeline). Cerca attività lunghe (blocchi gialli con angoli rossi) che si verificano tra la fine della richiesta di rete della risorsa LCP e il marcatore del tempo LCP. Queste attività sono la causa diretta del tuo ritardo. Passaci sopra con il mouse per identificare gli script responsabili.

Cause Comuni e Soluzioni ad Alto Impatto

Un Element Render Delay elevato è quasi sempre causato da un main thread bloccato.

Causa: CSS Render-Blocking

Il Problema: Per impostazione predefinita, il CSS blocca la renderizzazione (render-blocking). Il browser non disegnerà alcun pixel finché non avrà scaricato e analizzato tutti i file CSS collegati nell'<head>. Un foglio di stile grande e complesso può occupare il main thread per centinaia di millisecondi, ritardando l'inizio delle fasi di layout e paint. Questo problema viene aggravato quando i siti caricano più fogli di stile, ognuno dei quali richiede una richiesta di rete separata e un ciclo di analisi. Per strategie dettagliate su come ridurre il payload CSS, consulta la nostra guida su come rimuovere il CSS inutilizzato.

La Soluzione: Rendi il tuo CSS piccolo, pulito e memorizzabile nella cache.

  • Rimuovi il CSS Inutilizzato: Questa è la singola ottimizzazione con il maggiore impatto. Su siti di grandi dimensioni, il CSS inutilizzato può rappresentare il 70% o più della dimensione totale del foglio di stile. Strumenti come PurgeCSS possono scansionare il tuo HTML e JavaScript per identificare i selettori inutilizzati. Rimuovere regole inutili riduce sia il tempo di download che il tempo di analisi (parse) sul main thread.
  • Punta a fogli di stile piccoli e memorizzabili in cache: Il punto di equilibrio ideale per un file CSS è di circa 10-15kB (compresso). Se è più piccolo di così, rischi di suddividere in troppe richieste parallele, ognuna con il proprio sovraccarico di connessione (connection overhead). Se è più grande, il tempo di blocco aumenta, in particolare sulle reti mobili lente. Un singolo foglio di stile ben strutturato in quella gamma si scarica rapidamente, viene analizzato velocemente e viene memorizzato nella cache dal browser per le visite successive.
  • Incorpora il CSS (inline) solo come ultima risorsa: L'inlining del critical CSS all'interno di un blocco <style> elimina la richiesta di rete per il primo caricamento della pagina, ma a un costo: il CSS inlined non può essere memorizzato nella cache del browser. Ogni visitatore di ritorno lo scarica di nuovo con ogni pagina. Per la maggior parte dei siti con utenti di ritorno, un piccolo foglio di stile esterno memorizzato nella cache dal browser è la scelta migliore. L'inlining ha senso solo per le landing page con pochissimi visitatori di ritorno.

Quantificare l'impatto del CSS: Per misurare quanto il tuo CSS contribuisce al render delay, apri la scheda Coverage nei Chrome DevTools (Ctrl+Shift+P, quindi digita "Coverage"). Carica la pagina e osserva la percentuale di byte inutilizzati nei tuoi file CSS. Un'alta percentuale di CSS inutilizzato è un chiaro segnale che la pulizia ridurrà l'Element Render Delay.

Causa: Attività JavaScript Lunghe

Il Problema: Questa è la causa più comune. Un'esecuzione pesante di JavaScript, sia da framework, script di analisi, strumenti di A/B testing o codice scarsamente ottimizzato, può monopolizzare il main thread. Una singola attività di lunga durata può bloccare il rendering per centinaia di millisecondi, aggiungendosi direttamente all'Element Render Delay. Google definisce una long task come qualsiasi attività che richieda più di 50ms e le attività che superano i 200ms sono considerate criticamente lunghe. Per una raccolta completa di strategie per il deferimento del JavaScript, consulta il nostro articolo su 14 metodi per differire JavaScript.

La Soluzione: Suddividi il lavoro.

  • Cedi il controllo (yield) al Main Thread: Le long task devono essere suddivise in frammenti più piccoli. Questo può essere fatto restituendo periodicamente il controllo al browser utilizzando setTimeout(..., 0) o la più recente API scheduler.yield(). Questo consente al browser di eseguire aggiornamenti di rendering tra un'attività e l'altra.
  • Ottimizza e Differisci gli script di Terze Parti: Controlla ogni script di terze parti. Se non sono essenziali per il rendering iniziale, caricali con l'attributo defer o inseriscili dopo il caricamento della pagina. Gli script per i test A/B sono particolarmente problematici poiché spesso bloccano il rendering di proposito.
  • Usa requestAnimationFrame per gli aggiornamenti visivi: Se il JavaScript deve eseguire manipolazioni del DOM durante il caricamento della pagina, racchiudi il lavoro in requestAnimationFrame. Questo programma l'esecuzione del lavoro appena prima del paint successivo, assicurando al browser l'opportunità di eseguire il rendering dei fotogrammi tra un'operazione JavaScript e l'altra.

Identificare le Long Tasks in DevTools

Nel pannello Performance dei Chrome DevTools, le long task appaiono come blocchi gialli con un triangolo rosso nell'angolo in alto a destra nella traccia "Main". Per identificare quali script sono responsabili:

  1. Registra il caricamento di una pagina nel pannello Performance.
  2. Individua il marcatore LCP nella traccia Timings.
  3. Esamina la traccia Main per identificare le long task che si verificano tra il completamento della richiesta di rete della risorsa LCP e il marcatore LCP.
  4. Clicca su queste attività per visualizzare lo stack di chiamate nel pannello Summary. Lo stack di chiamate rivelerà il file sorgente e la funzione responsabile della long task.

Le cause più comuni legate a terze parti

In base alla mia esperienza reale di consulenza, gli script di terze parti più comuni che causano l'Element Render Delay includono:

  • Strumenti di A/B testing (Optimizely, VWO, AB Tasty): Spesso questi bloccano il rendering intenzionalmente per prevenire lo sfarfallio (flicker) del contenuto tra le varianti. Spostare la decisione dell'esperimento lato server (server-side testing) elimina completamente questo problema.
  • Tag manager con tag sincroni: Un tag manager configurato con tag sincroni (non-async) può iniettare script che bloccano il rendering. Controlla il tuo container per assicurarti che tutti i tag siano impostati per l'attivazione dopo il DOM ready o il window load.
  • Piattaforme di gestione del consenso (Consent management platforms): I banner di consenso sui cookie che bloccano il rendering fino a quando non viene presa una decisione possono ritardare l'LCP. Usa un'implementazione asincrona che non blocchi il critical rendering path.
  • Chat widget: I widget di live chat spesso eseguono codice di inizializzazione pesante al caricamento della pagina. Differisci il caricamento finché la pagina non è interattiva, oppure caricali all'interazione dell'utente (ad es. clic).

Causa: Client-Side Rendering (CSR)

Il Problema: Con il puro client-side rendering, l'elemento LCP spesso non esiste nell'HTML iniziale. Il JavaScript deve prima essere eseguito per creare il DOM, inserire l'elemento LCP, e solo allora il browser può finalmente eseguirne il rendering. Questo intero processo è un unico gigantesco render delay.

La Soluzione: Esegui il rendering sul server. Non c'è altro modo. Usa il Server-Side Rendering (SSR) o la Static Site Generation (SSG) per garantire che l'elemento LCP sia presente nel documento HTML iniziale inviato dal server. Questo elimina l'intera fase di rendering guidata da JavaScript come fonte di ritardo.

Causa: Contenuto Nascosto da Altro Codice

Il Problema: A volte l'elemento LCP è presente nel DOM ma è nascosto dai CSS (ad es. opacity: 0) o da uno script, come un'animazione "reveal on scroll" o uno strumento di test A/B che sta ancora decidendo quale variante mostrare. L'elemento è scaricato e pronto, ma non può essere disegnato perché non è ancora visibile.

La Soluzione: Assicurati una visibilità immediata. Per l'elemento LCP, non utilizzare animazioni in ingresso (entry animations) o alcuna logica che lo nasconda al caricamento iniziale. L'elemento dovrebbe essere visibile nel DOM e stilizzato per essere visibile fin dal primo paint. Configura gli strumenti di A/B testing per l'esecuzione in modo asincrono o assicurati che abbiano un impatto minimo sulla visibilità dell'elemento LCP.

Causa: Dimensioni Eccessive del DOM

Il Problema: Un DOM di grandi dimensioni (più di 1.500 nodi) aumenta il costo di ogni operazione di rendering. Ogni calcolo del layout, ricalcolo dello stile e operazione di paint deve elaborare più nodi, impiegando più tempo nel main thread. Anche se il tuo CSS e JavaScript sono ben ottimizzati, un DOM troppo gonfio (bloated) aggiunge render delay per puro volume. Per strategie dettagliate su come ridurre le dimensioni del DOM, consulta la nostra guida su come evitare un DOM di dimensioni eccessive.

La Soluzione: Riduci il numero di nodi DOM che partecipano al render iniziale.

  • Semplifica la struttura HTML: Rimuovi gli elementi contenitore (wrapper elements) non necessari. Appiattisci strutture profondamente annidate. Usa CSS Grid o Flexbox al posto di elementi <div> aggiuntivi per il layout.
  • Virtualizza gli elenchi lunghi: Per pagine con centinaia di elementi in lista (griglie di prodotti, tabelle di dati), utilizza librerie di virtualizzazione che eseguono il rendering solo degli elementi attualmente visibili nel viewport.
  • Lazy-render per i contenuti below-fold: Usa content-visibility: auto (spiegato di seguito) per saltare interamente la renderizzazione delle sezioni off-screen.

Tattiche Avanzate: Assumere il Pieno Controllo del Rendering

Applicazioni complesse richiedono un maggiore controllo sul main thread.

Sbloccare le Prestazioni con content-visibility

La proprietà CSS content-visibility è progettata per le pagine di grandi dimensioni. Impostando content-visibility: auto; sulle sezioni della pagina che si trovano below the fold (nella parte inferiore non visibile della pagina), stai dicendo al browser che può saltare le operazioni di layout, paint e composite per quel contenuto fino a quando non sta per entrare nel viewport. Questo riduce il carico di lavoro di rendering iniziale, liberando il main thread in modo da disegnare prima l'elemento LCP.

Il segreto è abbinare content-visibility: auto a contain-intrinsic-size, che fornisce una dimensione segnaposto per il contenuto nascosto. Senza di questo, il comportamento della barra di scorrimento diventa irregolare perché il browser non conosce l'altezza delle sezioni nascoste.

/* Applica alle sezioni below-the-fold */
.below-fold-section {
  content-visibility: auto;
  contain-intrinsic-size: auto 500px; /* Altezza stimata della sezione */
}

/* Esempio: Una lunga pagina di articolo */
.article-comments {
  content-visibility: auto;
  contain-intrinsic-size: auto 800px;
}

.related-products {
  content-visibility: auto;
  contain-intrinsic-size: auto 600px;
}

.site-footer {
  content-visibility: auto;
  contain-intrinsic-size: auto 300px;
}

Impatto sulle prestazioni: Secondo un post sul blog di Chrome Developers, l'applicazione di content-visibility: auto alle sezioni below-fold della pagina di un blog ha ridotto il tempo di rendering fino a 7 volte. Il browser salta completamente il layout, il paint e il composite per queste sezioni, liberando il main thread affinché si concentri sul contenuto above-fold, compreso l'elemento LCP. Il supporto del browser copre tutti i browser moderni: Chromium, Firefox e Safari 18+.

Scaricare il Lavoro tramite i Web Workers

I Web Workers ti consentono di eseguire JavaScript in un background thread, completamente separato dal main thread. Qualsiasi calcolo pesante eseguito in un Worker non può bloccare il rendering. Questo sito, corewebvitals.io, utilizza un Web Worker per l'elaborazione dei dati analitici e il vantaggio in termini di prestazioni è reale: il main thread resta libero di disegnare senza interruzioni.

Detto ciò, i Web Workers non rappresentano un pattern comune sulla maggior parte dei siti web. Richiedono un file JavaScript separato, comunicazione tramite postMessage e non hanno accesso al DOM. Gran parte delle piattaforme CMS e dei site builders non offre un supporto integrato per essi, rendendone difficile l'implementazione senza uno sviluppo personalizzato. Se hai le capacità tecniche per usarli, rappresentano uno dei modi più efficaci per mantenere libero il main thread. Ma per gran parte dei team, le altre ottimizzazioni illustrate in questa pagina avranno un impatto pratico ben maggiore.

// main.js: Crea un worker e invia i dati per l'elaborazione
const worker = new Worker('/js/analytics-worker.js');

// Scarica l'elaborazione analitica pesante sul worker thread
worker.postMessage({
  type: 'process-events',
  events: collectedEvents
});

// Ricevi i risultati senza bloccare il main thread
worker.onmessage = (event) => {
  console.log('Analisi elaborate:', event.data.summary);
};

// analytics-worker.js: Viene eseguito in un background thread
self.onmessage = (event) => {
  if (event.data.type === 'process-events') {
    // Il calcolo pesante avviene qui, fuori dal main thread
    const summary = processEvents(event.data.events);
    self.postMessage({ summary });
  }
};

Impatto nel Mondo Reale

  • Caso 1: Il Collo di Bottiglia del CSS Render-Blocking: DebugBear ha analizzato un sito in cui un file CSS di grandi dimensioni creava un notevole render delay. L'immagine LCP veniva scaricata, ma il browser era bloccato ad analizzare il CSS. Semplicemente includendo inline il CSS critico, il browser ha potuto disegnare il contenuto della pagina, compreso l'elemento LCP, quasi immediatamente dopo l'analisi dell'HTML, eliminando di fatto il render delay causato dal foglio di stile.
  • Caso 2: La Penalità degli A/B Testing: Un importante sito di e-commerce ha scoperto che il proprio LCP era frenato da uno script di test A/B asincrono. Sebbene l'immagine LCP venisse scaricata rapidamente, lo script bloccava il main thread mentre determinava quale immagine del prodotto mostrare. Spostare il test A/B in modo che venisse eseguito dopo il caricamento iniziale della pagina per gli elementi non critici ha migliorato immediatamente l'LCP di oltre 400 ms, tutti recuperati dall'Element Render Delay.

Checklist: Come Eliminare l'Element Render Delay

Un Element Render Delay elevato indica un main thread congestionato. Le soluzioni consistono nell'eliminare tale congestione affinché il browser possa eseguire il paint.

  1. Convalida tramite RUM: Utilizza dati di utenti reali per confermare che l'Element Render Delay sia il principale collo di bottiglia del tuo LCP prima di iniziare l'ottimizzazione.
  2. Rimuovi il CSS Inutilizzato: Verifica e rimuovi le regole CSS che non vengono mai applicate. Questa è la singola ottimizzazione CSS con l'impatto più elevato. Usa strumenti come PurgeCSS o la scheda Coverage nei DevTools.
  3. Mantieni i fogli di stile piccoli e in cache: Punta a circa 10-15kB (compresso) per file CSS. Abbastanza piccolo da scaricarsi rapidamente, ma abbastanza grande da evitare un eccessivo numero di richieste parallele. Lascia che il browser li memorizzi in cache per i visitatori di ritorno.
  4. Suddividi le Attività JavaScript Lunghe: Nessun singolo script dovrebbe essere eseguito per più di 50 ms. Cedi il controllo al main thread per consentire gli aggiornamenti di rendering.
  5. Controlla e Differisci gli Script di Terze Parti: Chiediti: questo script di terze parti è davvero indispensabile nella pagina? Differisci tutto ciò che non è essenziale per il primo disegno (initial paint).
  6. Usa SSR o SSG: Non affidarti al JavaScript lato client per visualizzare l'elemento LCP. Invia l'HTML già completamente formato dal server.
  7. Garantisci la Visibilità Immediata dell'LCP: Rimuovi animazioni, script o stili che nascondono l'elemento LCP al caricamento della pagina.
  8. Usa content-visibility: auto: Per pagine lunghe, chiedi al browser di non eseguire il rendering dei contenuti fuori schermo così da liberare il main thread per disegnare la porzione visibile (above-fold).
  9. Riduci la Dimensione del DOM: Appiattisci il codice HTML molto nidificato, rimuovi i wrapper superflui e virtualizza le liste lunghe in modo da ridurre il costo delle operazioni di layout e paint.

Passi Successivi: Continua a Ottimizzare l'LCP

L'Element Render Delay è la fase finale. Per coprirle tutte e quattro, continua con:

  • Correggere e Identificare i Problemi LCP: La metodologia di diagnosi completa per trovare e risolvere tutti i problemi LCP usando i dati dal campo e i tool da laboratorio.
  • Ottimizza l'Immagine LCP: Selezione dei formati immagine, immagini responsive, preload, ed errori ricorrenti di ottimizzazione delle immagini.
  • Resource Load Delay: Assicurati che il browser rintracci la risorsa LCP il prima possibile. Questo rappresenta sovente il maggiore ostacolo per l'LCP.
  • Resource Load Duration: Riduci le tempistiche di download per mezzo di compressioni, formati più recenti, configurazioni CDN e l'ottimizzazione del traffico di rete.

I have done this before at your scale.

Complex platforms, large dev teams, legacy code. I join your team as a specialist, run the performance track, and hand it back in a state you can maintain.

Discuss Your Situation
Ottimizzare l'LCP Element Render DelayCore Web Vitals Ottimizzare l'LCP Element Render Delay