First Contentful Paint (FCP): cos'è, come misurarlo e correggerlo

Correggere il First Contentful Paint

Il First Contentful Paint (FCP) è il momento in cui un browser disegna il primo elemento significativo su una pagina affinché il visitatore possa vederlo. In altre parole, è il momento in cui un browser renderizza qualcosa per la prima volta sullo schermo. In quanto tale, l'FCP è un buon modo per misurare la velocità di caricamento percepita della pagina.

Puoi migliorare l'FCP assicurandoti che un browser possa iniziare il rendering senza alcun ritardo. Di seguito imparerai cos'è l'FCP, come misurarlo e 15 tecniche comprovate per renderlo più veloce.

Cos'è il First Contentful Paint (FCP)?

Il First Contentful Paint (FCP) è un modo per misurare la velocità di caricamento della pagina. Non puoi riassumere la velocità della pagina come un punto nel tempo; ci sono in realtà diversi momenti durante il processo di caricamento in cui un visitatore potrebbe percepire il sito come veloce o lento nel caricamento. L'FCP misura la differenza di tempo tra la richiesta della pagina e il momento in cui il primo contenuto significativo viene renderizzato sullo schermo per la prima volta.

Cosa ti dice esattamente? Ti dice che l'FCP è principalmente una "metrica incentrata sull'utente" perché dice qualcosa sulla velocità di caricamento che un visitatore sperimenta. Dice qualcosa sull'esperienza utente. Al momento dell'FCP, puoi essere sicuro che un visitatore vede effettivamente "qualcosa" sullo schermo.

Analizziamo le parole: 'First', 'Contentful' e 'Paint'.

1. First: Con First, ovviamente, intendiamo il primo momento esatto in cui qualcosa di sostanziale appare nel browser.
2. Contentful: Con contentful intendiamo un elemento HTML con contenuto. Quindi non un elemento di layout come un elemento vuoto o un colore di sfondo, ma piuttosto del testo, un'immagine (inclusa un'immagine di sfondo), un SVG o un canvas.
3. Paint: Paint significa (più o meno) che il browser è pronto a mettere qualcosa sullo schermo. Questo sembra semplice ma in realtà è il compito più complicato del browser. Per mettere qualcosa sullo schermo, un browser deve essere pronto a calcolare tutte le caratteristiche di un elemento. Di seguito è riportato un esempio del processo di rendering necessario prima che qualcosa possa essere aggiunto sullo schermo.

FCP vs LCP: qual è la differenza?

FCP e LCP (Largest Contentful Paint) misurano entrambi le prestazioni di caricamento, ma catturano momenti diversi nella timeline di caricamento della pagina. Comprendere la differenza ti aiuta a dare la giusta priorità al tuo lavoro di ottimizzazione.

In pratica, l'FCP si attiva spesso ben prima dell'LCP. Ad esempio, una pagina potrebbe renderizzare un titolo (FCP) entro 400ms ma attendere altri 2 secondi per il caricamento dell'immagine hero (LCP). Se il tuo FCP è lento, anche il tuo LCP sarà quasi certamente lento, perché l'FCP cattura il primissimo collo di bottiglia nella pipeline di rendering. Leggi di più nella nostra guida completa sull'LCP.

Qual è un buon punteggio First Contentful Paint?

Un punteggio FCP buono è qualsiasi valore inferiore a 1,8 secondi. Se il tuo punteggio FCP è tra 1,8 e 3 secondi necessita di miglioramento. Qualsiasi punteggio FCP superiore a 3 secondi è considerato scarso. Per raggiungere la soglia raccomandata per il First Contentful Paint, almeno il 75% dei tuoi visitatori deve avere un punteggio FCP "buono".

Come sempre con le metriche di prestazione, un punteggio First Contentful Paint più veloce è migliore di uno più lento.

Come misuri il tuo First Contentful Paint (FCP)?

L'FCP viene misurato da Google raccogliendo dati da utenti reali. Quei dati sono memorizzati nel dataset CrUX. Quei dati sono pubblicamente disponibili tramite la CrUX API o Google BigQuery. L'FCP può anche essere misurato tramite i cosiddetti test di laboratorio. Il test di laboratorio più comune si chiama Lighthouse.

Ottenere il First Contentful Paint dal dataset CrUX

Il First Contentful Paint può essere letto dal dataset CrUX tramite pagespeed.web.dev, la CrUX API o tramite Google BigQuery.

Misurare il First Contentful Paint tramite Real User Monitoring (RUM)

RUM Tracking sta per Real User Monitoring. Con il Real User Monitoring puoi tracciare il First Contentful Paint tramite interazioni di utenti reali. Il vantaggio del RUM Tracking è che non devi aspettare 28 giorni per dati aggiornati e i dati possono essere interrogati e analizzati con molto più dettaglio.

Misurare l'FCP in Lighthouse

1. Apri la pagina (in Chrome) di cui vuoi misurare l'FCP. Assicurati di farlo in modalità incognito così i plugin non interferiranno e non rallenteranno potenzialmente l'FCP della tua pagina.
2. Clicca con il tasto destro sulla pagina e seleziona Ispeziona Elemento. In questo modo apri la console sviluppatori di Chrome.
3. In cima alla console, vedrai la scheda Lighthouse. Cliccaci. Poi sotto Categorie, scegli Performance (lascia le altre vuote) e scegli Mobile sotto Dispositivo.
4. Ora clicca su Genera Report. Lighthouse creerà un report sulla velocità della tua pagina. Nell'angolo in alto a sinistra del report, vedrai qual è l'FCP della tua pagina.

Questa è una schermata del report Lighthouse per questa pagina. L'FCP di questa pagina su un dispositivo mobile è di 0,8 secondi! Non male, vero?

Misurare l'FCP con uno strumento online

Puoi anche misurare l'FCP con diversi strumenti online. I più conosciuti sono GTMetrix, pingdom e pagespeed.web.dev. Questi strumenti sono facili da usare e forniranno alcuni dati sull'FCP in condizioni di laboratorio specifiche.

Cosa mostrano i dati FCP reali

I dati di CoreDash mostrano che l'FCP segue da vicino il TTFB: l'FCP p75 è di 392ms complessivi, con desktop a 372ms e mobile a 692ms (1,9 volte più lento). Il delta tra FCP e TTFB è di soli 248ms su desktop e 376ms su mobile, indicando che il tempo di blocco del rendering rappresenta una porzione relativamente piccola dell'FCP su un sito ben ottimizzato.

A livello globale, secondo la 2025 Web Almanac, il 70% delle pagine desktop raggiunge un buon FCP, mentre solo il 55% delle pagine mobile lo fa. Entrambi sono migliorati rispetto al 2024, con il mobile che ha guadagnato 4 punti percentuali, suggerendo che gli sviluppatori web stanno affrontando sempre di più le risorse che bloccano il rendering.

La stretta correlazione tra FCP e TTFB significa che migliorare il tuo Time to First Byte è spesso il modo singolarmente più efficace per migliorare il tuo First Contentful Paint. Su questo sito, l'FCP è solo circa 250ms sopra il TTFB, il che significa che la maggior parte del tempo FCP è spesa in attesa che il server risponda piuttosto che in lavoro di blocco del rendering.

Migliorare il First Contentful Paint

È ora di rendere l'FCP più veloce. L'idea alla base di un FCP veloce è in realtà piuttosto semplice: assicurarsi che un browser possa iniziare il rendering immediatamente. Qualsiasi cosa che possa causare un ritardo nel rendering risulterà in un punteggio FCP scarso.

Proprio come con il Largest Contentful Paint, il First Contentful Paint può essere suddiviso in 2 o 4 categorie:

1. Time to First Byte (TTFB): Il tempo da quando il browser inizia a caricare la pagina fino a quando riceve il primo byte dell'HTML.
2. Ritardo nel caricamento della risorsa: Il tempo tra il TTFB e quando il browser inizia a caricare la risorsa FCP.
3. Tempo di caricamento della risorsa: Il tempo necessario per caricare la risorsa FCP stessa.
4. Ritardo nel rendering dell'elemento: Il tempo tra il completamento del caricamento della risorsa FCP e il rendering completo dell'elemento FCP.

Suggerimento velocità: Puoi facilmente eliminare i passaggi 2 e 3 assicurandoti che l'elemento FCP non richieda una risorsa di rete. Nel caso di un elemento di testo, considera l'uso di font-display:swap. Nel caso di un piccolo elemento immagine, considera di inserire l'immagine inline.

Questo ci lascia solo il Time to First Byte e il Ritardo nel rendering dell'elemento da ottimizzare.

Di seguito sono riportate 14 soluzioni che uso spesso per migliorare l'FCP. Ma fai attenzione, usare una soluzione nel posto sbagliato può in realtà creare ritardi. Ecco perché è meglio consultare un esperto di pagespeed prima di iniziare da solo.

1. Risposta rapida del server (TTFB)

Il TTFB (il tempo tra la richiesta e il primo byte che il server invia) è sempre il primo passo nel processo di rendering. Da quel momento in poi, il tuo browser inizia a fare multitasking e l'impatto delle ulteriori ottimizzazioni inizia a diminuire. Il codice HTML è l'unica richiesta che influisce direttamente su tutte le metriche di velocità.

La velocità con cui il codice HTML viene inviato dal server è spesso misurata come il Time to First Byte (TTFB). È importante renderlo il più rapido possibile. Spesso lo si fa abilitando il caching lato server.

Quando si tratta di Time to First Byte, più basso è sempre meglio.

Puoi facilmente misurare il Time to First Byte da solo. Si fa nel seguente modo:

1. Usa la scorciatoia Ctrl-Shift-I per aprire la console sviluppatori di Google Chrome.
2. In cima alla console, vedrai una scheda Network. Cliccaci.
3. Ricarica la pagina tramite Ctrl-R.
4. Vedrai ora tutte le richieste di rete che Chrome ha inviato al tuo server.
5. Clicca sulla prima richiesta di rete, che è la richiesta per la pagina stessa.
6. Ora otterrai maggiori informazioni su questa richiesta di rete. Clicca sulla scheda timing in cima a queste informazioni per vedere qual è il TTFB della tua pagina.

2. HTTP/3

HTTP/3 è la terza versione del protocollo HTTP. HTTP/3 risolve molti dei problemi riscontrati nei protocolli più vecchi HTTP/1.1 e HTTP/2. Ad esempio, da HTTP/2, puoi inviare più file contemporaneamente attraverso la stessa connessione. HTTP/3 fornisce una connessione iniziale più veloce e meno problemi dovuti a piccole interruzioni di rete.

Senza entrare troppo nei dettagli, HTTP/3 consente un significativo guadagno di velocità, soprattutto su una rete più lenta come una rete mobile. Il tuo amministratore di rete può dirti se il tuo server web è già predisposto per il protocollo HTTP/3 più veloce.

Puoi verificare da solo se il tuo sito web sta già utilizzando il protocollo HTTP/3 più veloce. Usa la scorciatoia Ctrl-Shift-I per aprire l'ispettore di rete di Google Chrome. Clicca con il tasto destro sull'intestazione della tabella e seleziona Protocol. Ora ricarica la pagina per vedere quale protocollo sta usando il tuo sito.

3. 103 Early Hints

103 Early Hints è un codice di stato HTTP relativamente nuovo che permette a un server di inviare header di risposta preliminari prima che la risposta finale sia pronta. Questo è particolarmente utile quando il tuo server ha bisogno di tempo per generare l'HTML (ad esempio, interrogando un database o eseguendo logica lato server). Invece di far aspettare il browser inattivo, il server invia una risposta 103 con hint di preload e preconnect così il browser può iniziare a recuperare risorse critiche immediatamente.

Questo migliora direttamente l'FCP perché il browser può iniziare a scaricare font, fogli di stile e altre risorse critiche per il rendering prima ancora che l'HTML arrivi. L'impatto è più significativo sulle pagine con un TTFB elevato.

HTTP/1.1 103 Early Hints
Link: </static/font/outfit.woff2>; rel=preload; as=font; type=font/woff2; crossorigin
Link: </static/css/critical.css>; rel=preload; as=style

HTTP/1.1 200 OK
Content-Type: text/html
...

Non tutti i provider di hosting supportano ancora i 103 Early Hints. Cloudflare ha il supporto integrato per Early Hints, e Apache e Nginx possono essere configurati per inviarli. Leggi di più nella nostra guida completa ai 103 Early Hints.

4. Caching del browser

La connessione di rete è spesso un punto debole quando si tratta di velocità della pagina. Non sarebbe molto più facile saltare completamente la rete?

Quando un visitatore è già stato sul tuo sito, puoi indicare se e per quanto tempo le risorse di rete (ad esempio un foglio di stile) possono essere memorizzate dal browser del visitatore. Ogni volta che il visitatore ha di nuovo bisogno di uno di questi file, spuntano dalla cache del browser in un attimo. Di conseguenza, il browser può iniziare il rendering molto più velocemente e accelerare l'FCP.

5. Compressione

La velocità di rete è in quasi tutti i casi un punto debole. Per un buon First Contentful Paint, è molto importante che i file vengano inviati attraverso la rete il più velocemente possibile. La compressione riduce il numero di byte che devono essere inviati dal server; meno byte significa meno tempo in attesa di una risorsa di rete. La compressione, a mio parere, è una tecnica che non riceve l'attenzione che merita. Sfortunatamente, troppi webmaster "attivano la compressione" e poi non ci danno più un'occhiata. E questo è un peccato perché è solo un modo facile per rendere le cose un po' più veloci.

Ci sono due tecniche di compressione popolari: Gzip e Brotli. Gzip è la tecnica di compressione più utilizzata ma Brotli sta recuperando rapidamente. Brotli è stato creato da Google stesso e ha risultati migliori del 15-20% quando si tratta di file HTML, JavaScript o CSS. Brotli è, quindi, ideale per il web.

C'è anche una differenza tra compressione dinamica e compressione statica. Con la compressione dinamica comprimi il file appena prima di inviarlo attraverso il tuo server web; con la compressione statica, il file compresso è memorizzato sul server. Questo è spesso un modo molto più intelligente di comprimere, ma viene usato raramente.

6. Web font precoci con resource hint

I resource hint avviano un download o una connessione di rete prima che il browser lo faccia da solo. Alcune risorse di rete, come i web font o le immagini, vengono scaricate solo dopo che il browser è sicuro di doverle visualizzare.

Se sei sicuro di aver bisogno di una risorsa per renderizzare la parte visibile del sito, è quasi sempre una buona idea includere un "resource hint". Questo assicurerà che il browser inizi a scaricare o connettersi alla risorsa immediatamente. Di conseguenza, la risorsa è disponibile prima e il browser può iniziare il rendering prima.

Ma fai attenzione con i resource hint. Se li usi in modo errato, possono effettivamente rallentare la tua pagina.

Download anticipato con "preloading"

<link rel="preload" href="/static/font/opensans600.woff2" as="font" type="font/woff2" crossorigin>

Il link preload è uno degli strumenti più potenti nell'arsenale della velocità della pagina. Tramite il link preload, scarichi una risorsa di rete di cui avrai bisogno più tardi. Questo è spesso un'ottima idea con i font, gli script critici e le immagini nella parte visibile del sito.

Connettersi in anticipo con preconnect

Il link preconnect si connette già a un server. Questo è utile quando ospiti file su un server di terze parti come un CDN o Google Analytics.

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

Ancora meglio del preconnect a Google Fonts è ospitare autonomamente i tuoi Google Fonts. Questo elimina completamente la connessione di terze parti e ti dà il pieno controllo su caching e consegna.

7. Prefetch della pagina successiva con prefetch

<link rel="prefetch" href="/page2.html">

Con prefetch, puoi recuperare risorse a bassa priorità. Questo è un modo utile per recuperare risorse di cui pensi di aver bisogno più tardi, ad esempio quando ti aspetti che qualcuno clicchi sul link della pagina successiva.

8. Evita i redirect

Un errore comune è avere una catena di redirect troppo lunga. Ti spiego: il tuo sito probabilmente funziona tramite una connessione sicura. Quando un visitatore digita il tuo sito senza aggiungere https, il visitatore verrà reindirizzato alla versione non sicura del tuo sito web. Tuttavia, se tutto è configurato correttamente, il visitatore verrà reindirizzato al sito web sicuro. Puoi vedere questo nell'esempio verde qui sotto.

Ma a volte il reindirizzamento avviene tramite uno o più passaggi intermedi, come mostrato nell'esempio rosso. Sono questi passaggi intermedi che causano il rallentamento del sito web, risultando in un punteggio First Contentful Paint scarso. Ogni passaggio intermedio costa tempo extra, che può accumularsi rapidamente. Quindi, assicurati sempre di arrivare alla pagina giusta con un solo redirect.

9. Minimizza il CSS

Un file CSS esterno blocca sempre il rendering. Ciò significa che un browser normalmente non può iniziare a visualizzare il contenuto finché tutti i fogli di stile non sono stati scaricati e analizzati. Pertanto, è meglio mantenere i fogli di stile il più piccoli possibile. In questo modo non devi aspettare così a lungo che il foglio di stile venga scaricato. Per una guida più completa, leggi il nostro articolo su come correggere e rimuovere il CSS inutilizzato.

Ridurre le dimensioni del CSS con shortcode

Uno dei modi per ridurre le dimensioni del CSS è usare gli shortcode. Questi sono one-liner che ti permettono di scrivere le proprietà più importanti di un selettore CSS in una riga.

body{
    font-style: normal;
    font-weight: 400;
    font-stretch: normal;
    font-size: 0.94rem;
    line-height: 1.6;
    font-family: "Segoe UI", "Segoe UI", system-ui, -apple-system, sans-serif;
}

Puoi anche scriverlo come:

body{font: 400 .94rem/1.6 Segoe UI,Segoe UI,system-ui,-apple-system, sans-serif;}

Ridurre ulteriormente le dimensioni del CSS

È possibile ridurre ancora di più le dimensioni del CSS unendo i selettori con una virgola, rimuovendo gli a capo e gli spazi e scrivendo codici colore più corti.

h1{
  color : #000000;
}
h2{
  color : #000000;
}
h3{
  color : #000000;
}
h4{
  color : #000000;
}
h5{
  color : #000000;
}

Potrebbe essere abbreviato come

h1,h2,h3,h4,h5{color:#000}

10. CSS Critico

Possiamo fare un passo avanti con il CSS usando il CSS critico. Il CSS critico è un must per un sito web veloce e un First Contentful Paint veloce.

Il CSS critico è una raccolta di tutti i selettori (come body, p, h1 ecc.) necessari per mostrare la parte visibile della pagina. Non mettere questo CSS critico in un foglio di stile separato; aggiungilo invece direttamente nel <head> della pagina. In questo modo non devi scaricare un nuovo file e il browser può iniziare il rendering alla velocità della luce. Questo rende l'FCP più veloce. Il CSS di cui non hai bisogno direttamente per la parte visibile della pagina viene caricato dopo che il primo ciclo di rendering è completato. Per il tuo visitatore, la pagina è già pronta; nessuno noterà i nuovi stili che vengono ancora aggiunti in background.

Il CSS critico può essere facilmente generato con il nostro strumento CSS critico. Basta incollare l'URL della tua pagina web nello strumento e faremo il resto per te!

Esempio di CSS critico inline

<head>
  <style>
    /* Critical CSS: only what is needed for above-the-fold content */
    body{font:400 1rem/1.6 system-ui,sans-serif;margin:0}
    h1{font-size:2rem;margin:.5em 0}
    .hero{padding:2rem;background:#f5f5f5}
  </style>
  <!-- Non-critical CSS loaded asynchronously -->
  <link rel="preload" href="/css/full.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
  <noscript><link rel="stylesheet" href="/css/full.css"></noscript>
</head>

11. Differire il caricamento di JavaScript

Una delle ragioni più comuni per un First Contentful Paint lento è JavaScript. A seconda di come usi JavaScript, può bloccare il rendering della pagina. Normalmente JavaScript viene scaricato ed eseguito prima che l'albero di rendering sia costruito. Senza l'albero di rendering, un browser non può mettere nulla sullo schermo, e questo include l'FCP. Per una panoramica completa delle tecniche di differimento, leggi 14 metodi per differire JavaScript.

Possiamo aggirare questo problema posticipando JavaScript. Puoi farlo in tre modi.

JavaScript Async

<script async src="async.js"></script>

Aggiungendo l'attributo async a un tag script, la costruzione della pagina non viene più bloccata durante il download di JavaScript. L'attributo async indica che il download e la costruzione dell'albero di rendering possono avvenire contemporaneamente.

Una volta che lo script viene eseguito, la pagina è bloccata. Nella maggior parte dei casi, grazie all'attributo async, il browser ha avuto abbastanza tempo per costruire una parte importante della pagina, con il First Contentful Paint già visualizzato.

JavaScript Defer

<script defer src="deferred.js"></script>

L'attributo defer funziona più o meno allo stesso modo dell'attributo async. Aggiungendo l'attributo defer a un tag script, lo script può anche essere scaricato contemporaneamente alla costruzione della pagina. Dopo che tutti gli script sono stati scaricati, vengono eseguiti nell'ordine in cui sono stati trovati nel codice HTML. Questo può anche bloccare la visualizzazione della pagina ma nella maggior parte dei casi il First Contentful Paint è già sullo schermo.

12. Non fare affidamento sulle risorse esterne

Le risorse esterne, come font esterni, immagini esterne, fogli di stile esterni o script esterni, sono un potenziale collo di bottiglia quando si tratta del First Contentful Paint. Poiché non hai il controllo del server dove i file sono ospitati, non sai quanto velocemente verranno inviati. Inoltre, non puoi usare la connessione esistente al server web. Una nuova connessione a un nuovo server deve essere stabilita, e questo richiede tempo.

Una delle risorse esterne più comuni sul web è Google Fonts. Ospitare autonomamente i tuoi Google Fonts elimina un'intera connessione di terze parti e ti dà il pieno controllo su caching, compressione e comportamento font-display.

Risorse esterne bloccanti

Nessuna risorsa esterna

13. Usa il formato font corretto

I font meritano un'attenzione extra quando si tratta del First Contentful Paint. In circa il 99% delle pagine che esaminiamo, l'elemento FCP è una riga di testo. Quando usi web font esterni, devi prima scaricare questi font da un server, il che ovviamente richiede tempo.

Recentemente, i web font stanno ricevendo più attenzione e ci sono più formati font nuovi e più veloci. Il formato font più veloce al momento è woff2, seguito da woff. Woff2 è supportato da tutti i browser moderni.

Puoi specificare l'ordine preferito del tuo web font nella dichiarazione CSS font-face. Lo fai nel seguente modo:

 @font-face {
   font-family: 'myFont';
   font-weight: 400;
   font-style: normal;
   font-display: swap;
   unicode-range: U+000-5FF
   src: local('myFont'),
        url('/fonts/myFont.woff2') format('woff2'),
        url('/fonts/myFont.woff') format('woff');
}

14. Font-display: swap

Quando si usano i web font, il comportamento predefinito di questi font è di non mostrare il testo sulla pagina finché il font non è caricato. Questo è solitamente direttamente a spese del First Contentful Paint. Leggi la nostra guida completa su come assicurarsi che il testo rimanga visibile durante il caricamento del webfont.

Puoi risolvere questo usando la dichiarazione font-display:swap. Con questa puoi scegliere di mostrare il testo sulla pagina comunque, in un font che il browser conosce, mentre il webfont viene caricato in background.

Senza font-display:swap

Con font-display:swap

font-display: swap vs optional

Ci sono due strategie font-display comuni per l'ottimizzazione dell'FCP:

/* swap: Shows fallback font immediately, swaps when webfont loads */
@font-face {
  font-family: 'MyFont';
  font-display: swap;
  src: url('/fonts/myfont.woff2') format('woff2');
}

/* optional: Shows fallback font, only uses webfont if already cached */
@font-face {
  font-family: 'MyFont';
  font-display: optional;
  src: url('/fonts/myfont.woff2') format('woff2');
}

Usare font-display: swap garantisce l'FCP più veloce possibile perché il testo viene renderizzato immediatamente nel font di fallback. Usare font-display: optional evita completamente il flash di testo non stilizzato (FOUT) alla prima visita, ma il webfont verrà visualizzato solo se è già nella cache del browser. Per la maggior parte dei siti, swap è la scelta migliore per l'FCP.

15. Minimizza le dimensioni del DOM

Una pagina web è composta da HTML. La prima cosa che fa un browser è convertire l'HTML in nodi DOM. Questa è una struttura ad albero di elementi HTML che viene successivamente usata per costruire l'albero di rendering. Dall'albero di rendering un browser inizia il rendering; alla fine la pagina web appare sullo schermo.

Quanti nodi DOM (elementi HTML) hai e quanto profondi sono questi nodi DOM nella struttura ad albero determina quanto è complicato per un browser costruire la tua pagina. Anche CSS e JavaScript richiedono più tempo per essere analizzati quando hai troppi nodi DOM. Questo, di nuovo, è tutto direttamente a spese dell'FCP.

Risolvi questo con:

• Lazy load di parti della tua pagina web
  Per velocizzare la visualizzazione iniziale, considera di caricare parti del tuo sito web, come il footer, tramite AJAX in un momento successivo.
• Usa content-visibility
  La proprietà CSS content-visibility dice a un browser di saltare stile, layout e paint durante il rendering. Lo fa appena prima che l'elemento diventi visibile.
• Dividi pagine grandi in più pagine
  Il numero di nodi DOM può essere ridotto dividendo pagine grandi in più pagine.
• Implementa lo scroll infinito
  Lo scroll infinito è fondamentalmente lazy loading: quando scorri attraverso elementi ripetuti come immagini (Pinterest) o grandi tabelle di dati, lo scroll infinito può velocizzare significativamente la tua pagina.
• Evita l'interazione JavaScript con il DOM
  Fai particolare attenzione con JavaScript quando hai un grande numero di nodi DOM sulla tua pagina. Un comando come querySelectorAll può allora caricare un grande numero di nodi DOM, aumentando l'uso della memoria.
• Evita dichiarazioni CSS complicate
  Fai particolare attenzione con i comandi CSS complicati con un grande numero di nodi DOM. Ad esempio, controllare lo stato last-child per ogni elemento div sulla tua pagina può essere costoso.
• Usa i web worker per alleggerire il main thread del tuo browser
  I web worker sono JavaScript che possono essere eseguiti in parallelo con la tua pagina web. Puoi dare a questi web worker comandi che vengono eseguiti in background. Quando il web worker ha eseguito il comando, lo passa alla pagina originale. Il vantaggio è che puoi comunque eseguire JavaScript complesso senza che la pagina si blocchi.

Guide di ottimizzazione correlate

Migliorare l'FCP richiede lavoro su più aree. Ecco le nostre guide più rilevanti:

• Ospitare autonomamente Google Fonts: Elimina una connessione di terze parti e ottieni il pieno controllo sulla consegna dei font.
• Assicurarsi che il testo rimanga visibile durante il caricamento del webfont: Usa font-display per garantire un rendering rapido del testo.
• 14 metodi per differire JavaScript: Ogni tecnica per impedire a JavaScript di bloccare il tuo FCP.
• Correggere e rimuovere il CSS inutilizzato: Riduci al minimo il CSS che blocca il rendering.
• 103 Early Hints: Lascia che il browser inizi a recuperare risorse prima che l'HTML arrivi.
• Guida al Largest Contentful Paint (LCP): FCP e LCP condividono molte strategie di ottimizzazione. Se il tuo FCP è lento, lo sarà anche il tuo LCP.
• Guida al Time to First Byte (TTFB): Il TTFB è il singolo contributo più grande all'FCP. Inizia da qui se la risposta del tuo server è lenta.