Ottimizza il ritardo di rendering dell'elemento LCP

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

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-07-10
  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 sui Core Web Vitals. L'Element Render Delay è la fase finale nella sequenza temporale del LCP. Rappresenta il divario tra la fine del download della risorsa LCP e il momento in cui viene dipinta in modo visibile sullo schermo.

Ottimizza l'Element Render Delay del LCP

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

L'Element Render Delay è il tempo che intercorre tra la fine del download della risorsa LCP e la pittura completa dell'elemento sullo schermo dell'utente. Non è un problema di rete; è un problema del main thread. Un render delay elevato significa che il browser ha l'immagine o il font, ma è troppo occupato con altri task per poterlo disegnare. Questo ritardo è una tassa diretta sul tuo punteggio LCP. A volte aggiunge 200ms o più dopo il completamento di tutte le richieste di rete.

Definizione precisa: il problema dell'ultimo miglio

L'Element Render Delay inizia nel momento in cui l'ultimo byte della risorsa LCP (ad esempio, un file immagine o un web font) arriva al browser. Finisce quando l'elemento LCP viene dipinto in modo visibile sullo schermo. È, letteralmente, il passaggio finale.

Per gli elementi LCP basati su testo che usano un font di sistema, questo ritardo è spesso zero, poiché non serve alcuna risorsa esterna. Tuttavia, per la stragrande maggioranza dei siti in cui l'elemento LCP è un'immagine o usa un web font personalizzato, questa fase è spesso il collo di bottiglia più grande. Il browser spende questo tempo in task legati 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 in più fasi spesso chiamato Critical Rendering Path. Pensalo come la catena di montaggio di una fabbrica:

  1. Costruzione dei progetti (DOM e CSSOM): Il browser analizza 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 vengono combinati in un Render Tree. Questo contiene solo i nodi necessari per renderizzare la pagina. Elementi come <head> o quelli con display: none; vengono omessi.
  3. Calcolo della geometria (Layout): Il browser calcola la dimensione e la posizione esatte 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. Questi 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 solo lavoratore: il main thread. Se quel lavoratore è occupato a eseguire un long task JavaScript o ad analizzare un file CSS enorme, la catena di montaggio si ferma. L'immagine del LCP potrebbe essere arrivata, ma si trova sulla banchina di carico. Aspetta che il main thread si liberi per elaborarla e dipingerla.

Come individuare l'Element Render Delay

Diagnosticare questo problema segue un processo rigoroso in due fasi. Non saltare la prima fase.

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

Fase 2: Diagnostica con i DevTools
Una volta che i RUM hanno identificato le pagine problematiche, usa il pannello Performance dei Chrome DevTools per trovare la causa. La nostra guida Diagnosticare il LCP con il pannello Performance dei Chrome DevTools copre passo dopo passo la configurazione del throttling e il flusso di lavoro di registrazione. Nello specifico per il render delay:

  1. Registra un caricamento di pagina con il pulsante "Record and reload".
  2. Apri l'insight "LCP breakdown" nella barra laterale Insights e prendi nota del valore dell'Element render delay.
  3. Ora esamina la traccia Main nella timeline. Cerca i long task (blocchi gialli con angoli rossi) che si verificano tra la fine della richiesta di rete della risorsa LCP e il marcatore di tempo del LCP. Questi task 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: Di default, il CSS è render blocking. Il browser non dipingerà alcun pixel finché non avrà scaricato e analizzato tutti i file CSS linkati nell'<head>. Un foglio di stile grande e complesso può occupare il main thread per centinaia di millisecondi. Questo ritarda l'inizio delle fasi di layout e paint. Il problema si aggrava quando i siti caricano più fogli di stile, ognuno dei quali richiede una richiesta di rete e un ciclo di analisi separati. 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 in cache.

  • Rimuovi il CSS inutilizzato: Questa è la singola ottimizzazione a più alto 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 non utilizzati. Rimuovere le regole morte riduce sia il tempo di download che il tempo di analisi sul main thread.
  • Punta a fogli di stile piccoli e memorizzabili in cache: La dimensione ideale per un file CSS è di circa 10-15kB (compresso). Al di sotto, rischi di dividerlo in troppe richieste parallele, ciascuna con il suo overhead di connessione. Al di sopra, il tempo di blocco cresce, specialmente su reti mobili lente. Un singolo foglio di stile ben strutturato in quel range viene scaricato velocemente, analizzato velocemente e messo in cache dal browser per le visite successive.
  • Fai l'inline del CSS solo come ultima risorsa: Fare l'inline del CSS critico in un blocco <style> elimina la richiesta di rete per il primo caricamento della pagina. Ma ha un costo: il CSS inlined non può essere messo in cache dal browser. Ogni visitatore di ritorno lo riscarica con ogni pagina. Per la maggior parte dei siti con utenti di ritorno, la scelta migliore è un piccolo foglio di stile esterno che il browser mette in cache. 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 il tab Coverage dei Chrome DevTools (Ctrl+Shift+P, poi digita "Coverage"). Carica la pagina e guarda la percentuale di byte non utilizzati nei tuoi file CSS. Un'alta percentuale di CSS inutilizzato è un chiaro segnale che una pulizia ridurrà l'Element Render Delay.

Causa: Long task JavaScript

Il problema: Questa è la causa più comune. L'esecuzione pesante di JavaScript, che provenga da framework, script di analytics, strumenti di A/B testing o codice mal ottimizzato, può monopolizzare il main thread. Un singolo long task può bloccare il rendering per centinaia di millisecondi, sommandosi direttamente all'Element Render Delay. Google definisce un long task come qualsiasi task che richiede più di 50ms. I task che superano i 200ms sono considerati criticamente lunghi. Per una raccolta completa di strategie per differire JavaScript, vedi il nostro articolo su 14 metodi per differire JavaScript.

La soluzione: Suddividi il lavoro.

  • Fai yielding al main thread: I long task devono essere suddivisi in porzioni più piccole. Puoi farlo restituendo periodicamente il controllo al browser tramite il yielding, usando setTimeout(..., 0) o la più recente API scheduler.yield(). Questo permette al browser di eseguire aggiornamenti di rendering tra un task e l'altro.
  • Ottimizza e differisci le terze parti: Controlla ogni script di terze parti. Se non sono essenziali per il rendering iniziale, caricali con l'attributo defer o iniettali dopo il caricamento della pagina. Gli script per l'A/B testing sono particolarmente problematici poiché spesso bloccano il rendering in modo intenzionale (by design).
  • Usa requestAnimationFrame per gli aggiornamenti visivi: Se JavaScript deve eseguire manipolazioni del DOM durante il caricamento della pagina, avvolgi il lavoro in requestAnimationFrame. Questo programma l'esecuzione del lavoro appena prima del paint successivo, assicurando al browser l'opportunità di renderizzare i frame tra le operazioni JavaScript.

Identificare i long task nei DevTools

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

  1. Registra un caricamento di pagina nel pannello Performance.
  2. Individua il marcatore LCP nella traccia Timings.
  3. Esamina la traccia Main alla ricerca di long task che si verificano tra il completamento della richiesta di rete della risorsa LCP e il marcatore LCP.
  4. Clicca su questi task per vedere il call stack nel pannello Summary. Il call stack rivelerà il file sorgente e la funzione responsabile del long task.

I principali colpevoli tra le terze parti

In base all'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 bloccano il rendering intenzionalmente per prevenire lo sfarfallio del contenuto tra le varianti. Spostare la decisione dell'esperimento sul 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 render blocking. Controlla il tuo contenitore per assicurarti che tutti i tag siano impostati per scattare dopo il DOM ready o il window load.
  • Consent management platforms: I banner di consenso sui cookie che bloccano il rendering fino a quando non viene presa una decisione possono ritardare il LCP. Usa un'implementazione asincrona che non blocchi il critical rendering path.
  • Widget di chat: Gli script di live chat spesso eseguono codice di inizializzazione pesante al caricamento della pagina. Differisci il caricamento a quando la pagina è interattiva, o caricali in base all'interazione dell'utente (ad es., al clic).

Causa: Rendering lato client (CSR)

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

La soluzione: Renderizza sul server. Non c'è altra via. Usa il Server-Side Rendering (SSR) o la Static Site Generation (SSG) per assicurarti 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 è nel DOM ma è nascosto dal CSS (ad esempio, opacity: 0) o da uno script, come un'animazione "reveal on scroll" o uno strumento di A/B testing che sta ancora decidendo quale variante mostrare. L'elemento è scaricato e pronto, ma non può essere dipinto perché non è ancora visibile.

La soluzione: Assicurati una visibilità immediata. Per l'elemento LCP, non usare animazioni di ingresso o logiche che lo nascondono al caricamento iniziale. L'elemento deve essere visibile nel DOM e stilizzato per essere visibile fin dal primissimo paint. Configura gli strumenti di A/B testing per l'esecuzione asincrona o assicurati che abbiano un impatto minimo sulla visibilità dell'elemento LCP.

Causa: Dimensione eccessiva del DOM

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

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

  • Semplifica la struttura dell'HTML: Rimuovi gli elementi wrapper non necessari. Appiattisci le strutture profondamente nidificate. Usa CSS Grid o Flexbox invece di elementi <div> extra per il layout.
  • Virtualizza le liste lunghe: Per le pagine con centinaia di elementi in lista (griglie di prodotti, tabelle di dati), usa librerie di virtualizzazione che renderizzano solo gli elementi attualmente visibili nel viewport.
  • Lazy-renderizza i contenuti below-fold: Usa content-visibility: auto (trattato di seguito) per saltare interamente il rendering delle sezioni fuori schermo.

Tattiche avanzate: prendere il pieno controllo del rendering

Le applicazioni complesse necessitano di maggiore controllo sul main thread.

Sbloccare le performance con content-visibility

La proprietà CSS content-visibility è progettata per pagine di grandi dimensioni. Impostando content-visibility: auto; sulle sezioni della tua pagina che si trovano below the fold, comunichi al browser che può saltare il lavoro di layout, paint e composite per quel contenuto fino a quando non sta per entrare nel viewport. Questo taglia il carico di lavoro del rendering iniziale, liberando il main thread per dipingere prima l'elemento LCP.

La chiave è accoppiare content-visibility: auto con contain-intrinsic-size, che fornisce una dimensione segnaposto per il contenuto nascosto. Senza di essa, il comportamento della scrollbar diventa irregolare perché il browser non sa quanto sono alte le sezioni nascoste.

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

/* Esempio: Una pagina articolo lunga */
.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 performance: Secondo un post sul blog dei Chrome Developers, applicare content-visibility: auto alle sezioni below-fold di una pagina blog ha ridotto il tempo di rendering fino a 7 volte. Il browser salta del tutto il lavoro di layout, paint e composite per queste sezioni, liberando il main thread per concentrarsi sul contenuto above-fold, incluso l'elemento LCP. Il supporto copre tutti i browser moderni: Chromium, Firefox e Safari 18+.

Scaricare il lavoro con i Web Worker

I Web Worker ti permettono di eseguire JavaScript in un background thread, completamente fuori dal main thread. Qualsiasi calcolo pesante eseguito in un Worker non può bloccare il rendering. Questo sito, corewebvitals.io, usa un Web Worker per elaborare i suoi analytics, e il vantaggio in termini di performance è reale: il main thread resta libero di dipingere senza interruzioni.

Detto questo, i Web Worker non sono un pattern comune sulla maggior parte dei siti web. Richiedono un file JavaScript separato, la comunicazione tramite postMessage, e non hanno accesso al DOM. La maggior parte delle piattaforme CMS e dei site builder non offre supporto nativo per loro, rendendone difficile l'implementazione senza uno sviluppo personalizzato. Se hai le capacità tecniche per usarli, sono uno dei modi più efficaci per mantenere sgombro il main thread. Ma per la maggior parte dei team, le altre ottimizzazioni su questa pagina avranno un impatto pratico maggiore.

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

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

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

// analytics-worker.js: Esegue in un background thread
self.onmessage = (event) => {
  if (event.data.type === 'process-events') {
    // I calcoli pesanti avvengono 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 grosso file CSS creava un render delay notevole. L'immagine del LCP veniva scaricata, ma il browser era bloccato ad analizzare il CSS. Semplicemente facendo l'inlining del CSS critico, il browser è riuscito a dipingere il contenuto della pagina, incluso l'elemento LCP, quasi subito dopo l'analisi dell'HTML. Questo ha eliminato di fatto il render delay causato dal foglio di stile.
  • Caso 2: La penalità dell'A/B testing: Un importante sito di e-commerce ha scoperto che il proprio LCP era frenato da uno script di A/B testing sincrono. Anche se l'immagine LCP veniva scaricata rapidamente, lo script bloccava il main thread per determinare quale immagine di prodotto mostrare. Spostare il test A/B per l'esecuzione dopo il caricamento iniziale della pagina, per gli elementi non critici, ha migliorato immediatamente il loro LCP di oltre 400ms, 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 prevedono l'eliminazione di questa congestione in modo che il browser possa dipingere.

  1. Convalida con i RUM: Usa i dati reali degli utenti per confermare che l'Element Render Delay sia il collo di bottiglia principale del tuo LCP prima di iniziare a ottimizzare.
  2. Rimuovi il CSS inutilizzato: Controlla ed elimina le regole CSS che non vengono mai applicate. Questa è la singola ottimizzazione CSS a più alto impatto. Usa strumenti come PurgeCSS o il tab Coverage nei DevTools.
  3. Mantieni i fogli di stile piccoli e memorizzabili in cache: Punta a circa 10-15kB (compressi) per file CSS. Abbastanza piccoli per un download veloce, abbastanza grandi per evitare richieste parallele eccessive. Lascia che il browser li metta in cache per i visitatori di ritorno.
  4. Suddividi i long task JavaScript: Nessun singolo script dovrebbe essere eseguito per più di 50ms. Fai yielding al main thread per consentire gli aggiornamenti del rendering.
  5. Controlla e differisci gli script di terze parti: Chiediti: ogni script di terze parti si guadagna il suo posto sulla pagina? Differisci tutto ciò che non è essenziale per il paint iniziale.
  6. Usa SSR o SSG: Non fare affidamento su JavaScript lato client per renderizzare il tuo elemento LCP. Invia HTML completamente formato dal server.
  7. Assicurati una visibilità immediata del LCP: Rimuovi qualsiasi animazione, script o stile che nasconda l'elemento LCP al caricamento della pagina.
  8. Usa content-visibility: auto: Per le pagine lunghe, di' al browser di saltare il rendering del contenuto fuori schermo per liberare il main thread per la pittura above-fold.
  9. Riduci le dimensioni del DOM: Appiattisci l'HTML profondamente nidificato, rimuovi i wrapper non necessari e virtualizza le liste lunghe per ridurre il costo delle operazioni di layout e paint.

Prossimi passi: continuare a ottimizzare il LCP

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

  • Risolvere e identificare i problemi del LCP: La metodologia diagnostica completa per trovare e risolvere tutti i problemi del LCP utilizzando i field data e gli strumenti di laboratorio.
  • Ottimizzare l'immagine LCP: Selezione del formato dell'immagine, immagini responsive, preloading ed errori comuni di ottimizzazione delle immagini.
  • Resource Load Delay: Assicurati che il browser scopra la risorsa LCP il prima possibile. Questo è spesso il singolo collo di bottiglia del LCP più grande.
  • Resource Load Duration: Riduci il tempo di download tramite compressione, formati moderni, configurazione della CDN e ottimizzazione della rete.

Tempo reale. Non medie di 28 giorni.

CoreDash ti segmenta ogni metrica per route, device, browser e tipo di connessione.

Prova CoreDash
Ottimizza il ritardo di rendering dell'elemento LCP Core Web Vitals Ottimizza il ritardo di rendering dell'elemento LCP