First Contentful Paint

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 caricamento rapido o lento. Il FCP misura la differenza di tempo tra la richiesta della pagina e quando il primo contenuto significativo viene renderizzato sullo schermo per la prima volta.

Cosa ti dice esattamente però? Ti dice che il 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 del FCP, puoi essere sicuro che un visitatore vede effettivamente "qualcosa" sullo schermo.

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

1. First:  Per First, ovviamente, intendiamo il primo momento esatto in cui qualcosa di sostanziale appare sul tuo 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 l'immagine di sfondo), SVG o 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 richiesto prima che qualsiasi cosa possa essere aggiunta sullo schermo.

Qual è un buon punteggio First Contentful Paint?

Un punteggio FCP buono è qualsiasi cosa tra 0 e 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 superare i Core Web Vitals per il Largest Contentful Paint almeno il 75% dei tuoi visitatori deve avere un punteggio FCP 'buono'.

Come sempre con i Core Web Vitals, un punteggio First Contentful Paint più veloce è migliore di uno più grande. 

Come si misura il First Contentful Paint (FCP)?

Il FCP viene misurato da Google raccogliendo dati da utenti reali. Questi dati vengono archiviati nel dataset CrUX. Questi dati sono disponibili pubblicamente tramite l'API CrUX o Google BigQuery. Il 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, l'API CrUX 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 attraverso interazioni reali degli utenti. Il vantaggio del RUM Tracking è che non devi aspettare 28 giorni per dati aggiornati e i dati possono essere interrogati e analizzati in modo molto più dettagliato.

Misurare il FCP in Lighthouse

1. Apri la pagina – in Chrome – di cui vuoi misurare il FCP. Assicurati di farlo in incognito in modo che i plugin non ti disturbino e possibilmente rallentino il FCP della tua pagina.
2. Fai clic con il pulsante destro del mouse sulla pagina e seleziona Ispeziona elemento. In questo modo apri la console per sviluppatori di Chrome.
3. Nella parte superiore della console, vedrai la scheda Lighthouse. Fai clic su di essa. Quindi in Categorie, scegli Performance (lascia gli altri vuoti) e scegli Mobile sotto Dispositivo.
4. Ora fai clic su Genera rapporto. Lighthouse creerà un rapporto sulla velocità della tua pagina. Nell'angolo in alto a sinistra del rapporto, vedrai qual è il FCP della tua pagina.

Questo è uno screenshot del rapporto Lighthouse per questa pagina. Il FCP di questa pagina su un dispositivo mobile è di 0,8 secondi! Non male vero?

Misurare il FCP con uno strumento online

Puoi anche misurare il FCP con una serie di strumenti online. I più conosciuti sono GTMetrix, pingdom e pagespeed.web.dev. Questi strumenti sono facili da usare e forniranno alcuni dati sul LCP in circostanze di laboratorio specifiche.

Migliorare il First Contentful Paint

Ora che sai cos'è il First Contentful Paint, possiamo metterci al lavoro per renderlo più veloce. L'idea alla base di un FCP veloce è in realtà abbastanza semplice: assicurarsi che un browser possa iniziare a renderizzare immediatamente. Tutto ciò che può causare ritardi nella renderizzazione comporterà 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. Resource load delay - Il tempo tra il TTFB e quando il browser inizia a caricare la risorsa FCP
   
3. Resource load time - Il tempo necessario per caricare la risorsa FCP stessa.
   
4. Element render delay - Il tempo tra quando la risorsa FCP ha terminato il caricamento fino a quando l'elemento LCP è completamente renderizzato
   

Consiglio sulla velocità: Puoi facilmente eliminare i passaggi 2 e 3 assicurandoti che l'elemento LCP non richieda una risorsa di rete. In caso di elemento di testo, considera l'uso di font-display:swap. In caso di piccolo elemento immagine, considera di posizionare l'immagine inline.

Questo ci lascia solo con il Time to First Byte e l'Element Render delay da ottimizzare.

Di seguito sono riportate 14 soluzioni che uso spesso per migliorare il FCP. Ma fai attenzione, usare una soluzione nel posto sbagliato può effettivamente creare ritardi. Ecco perché è meglio consultare un esperto di velocità della pagina 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 il multitasking e l'impatto di 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 viene spesso misurata come il time to first byte (TTFB). È importante rendere questo il più veloce possibile. Spesso lo fai abilitando la cache lato server.

Quando si tratta di time to first byte, più basso è sempre meglio. 

Puoi facilmente misurare tu stesso il time to first byte. Si fa come segue:

1. Usa la scorciatoia Ctrl-Shift-I per aprire la console per sviluppatori di Google Chrome.
   
2. Nella parte superiore della console, vedrai una scheda Network. Fai clic su di essa.
3. Ricarica la pagina tramite Ctrl-R.
   
4. Ora vedrai tutte le richieste di rete che Chrome ha inviato al tuo server.
5. Fai clic sulla richiesta di rete superiore, che è la richiesta per la tua pagina stessa.
6. Ora otterrai maggiori informazioni su questa richiesta di rete.  Fai clic sulla scheda timing nella parte superiore di queste informazioni per vedere qual è il TTFB per la tua pagina.

2. HTTP/3

HTTP/3 è la terza versione del protocollo HTTP. HTTP/3 risolve molti dei problemi riscontrati nei vecchi protocolli 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ù rapida e meno problemi da interruzioni di rete minori.

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à adatto per il protocollo HTTP/3 più veloce.

Puoi verificare tu stesso 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. Fai clic con il pulsante destro del mouse sul lettore della tabella e seleziona Protocollo. Ora ricarica la pagina per vedere quale protocollo sta utilizzando il tuo sito.

3. Browser Caching

La connessione di rete è spesso un anello 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 archiviate dal browser del visitatore. Ogni volta che il visitatore ha bisogno di uno di questi file di nuovo, vengono fuori dalla cache del browser in pochissimo tempo. Di conseguenza, il browser può iniziare a renderizzare molto più velocemente e velocizzare il FCP.

4. Compressione

La velocità della rete è in quasi tutti i casi un anello debole. Per un buon First Contentful Paint, è così 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 di attesa su una risorsa di rete. La compressione, a mio parere, è una tecnica che non sta ricevendo 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 far andare le cose un po' più velocemente.

Ci sono due tecniche di compressione popolari: Gzip e Brotli. Gzip è la tecnica di compressione più utilizzata ma Brotli sta rapidamente recuperando. Brotli è stato creato da Google stesso e ha risultati dal 15 al 20% migliori 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 viene archiviato sul server. Questo è spesso un modo molto più intelligente di comprimere, ma viene usato raramente.

5. Web-font anticipati con resource hints

I resource hints 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 a renderizzare prima.

Ma fai attenzione con i resource hints, 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. Attraverso il link preload, scarichi una risorsa di rete di cui avrai bisogno più tardi. Questa è spesso un'ottima idea con font, script critici e immagini sulla 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>

6. Precaricare la 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 che pensi ti serviranno più tardi – quando ti aspetti che qualcuno faccia clic sul link della pagina successiva, ad esempio.

7. Evitare i redirect

Un errore comune è avere una catena di reindirizzamento troppo lunga. Lascia che ti spieghi: Il tuo sito probabilmente funziona tramite una connessione sicura. Quando un visitatore digita il tuo sito, senza aggiungere https, verrà reindirizzato alla versione non protetta 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, con conseguente punteggio First Contentful Paint scarso. Ogni passaggio intermedio costa tempo extra, che può accumularsi rapidamente. Quindi, assicurati sempre di arrivare alla pagina giusta entro un reindirizzamento.

8. Minimizzare il CSS

Un file CSS esterno è sempre render-blocking. Ciò significa che un browser normalmente non può iniziare a visualizzare il contenuto fino a quando 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ì tanto tempo per il download del foglio di stile.

Ridurre le dimensioni del CSS con shortcode

Uno dei modi per ridurre le dimensioni del CSS è utilizzare 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 ulteriormente le dimensioni del CSS unendo i selettori con una virgola,  rimuovendo invii e spazi e scrivendo codici colore più brevi.

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}

9. Critical CSS

Possiamo portare il CSS un passo avanti utilizzando il critical CSS. Il critical CSS è un must per un sito web veloce e un First Contentful Paint veloce.

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

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

10. 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 venga costruito il render tree. Senza il render tree, un browser non può mettere nulla sullo schermo – questo include il FCP.

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

Async JavaScript

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

Aggiungendo l'attributo async a un tag script, la costruzione della pagina non viene più bloccata mentre JavaScript viene scaricato. L'attributo async indica che il download e la costruzione del render tree possono avvenire contemporaneamente.

Una volta che lo script viene eseguito, la pagina viene 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à sulla pagina.

Defer JavaScript

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

L'attributo defer funziona più o meno allo stesso modo dell'attributo async. Aggiungendo l'attributo defer a un tag script, anche lo script può 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 in molti casi il First Contentful Paint è già sullo schermo.

11. Non affidarsi a 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 di First Contentful Paint. Poiché non hai controllo sul server dove sono ospitati i file, non sai quanto velocemente verranno inviati. Inoltre, non puoi utilizzare la connessione esistente al server web. Deve essere stabilita una nuova connessione a un nuovo server – e questo richiede tempo.

Risorse esterne bloccanti

Nessuna risorsa esterna

12. Usare il formato font giusto

I font meritano particolare attenzione quando si tratta di First Contentful Paint. Su 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 hanno ricevuto più attenzione e ci sono più formati di font nuovi e più veloci. Il formato di font più veloce al momento è woff2, seguito da woff. Woff2 è supportato da ogni browser moderno. 

Puoi specificare l'ordine preferito del tuo web font nella dichiarazione CSS font-face. Lo fai come segue:

 @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');
}

13. Font display:swap

Quando si utilizzano 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. 

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

Senza font-display:swap

Con font-display:swap

Leggi il nostro articolo completo  Assicurati che il testo rimanga visibile durante il caricamento del webfont

14. Minimizzare 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 utilizzata per costruire il render tree. Dal render tree un browser inizia a renderizzare; alla fine la pagina web appare sullo schermo. 

Quanti nodi DOM (elementi HTML) hai e quanto sono profondi questi nodi DOM nella struttura ad albero determina quanto sia 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 del FCP.

Risolvi questo problema:

• Caricamento lazy 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 style, 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 elementi ripetuti come immagini (pinterest) o grandi tabelle di dati, lo scroll infinito può accelerare significativamente la tua pagina.
• Evita l'interazione DOM con JavaScript
  Fai particolare attenzione con JavaScript quando hai un gran numero di nodi DOM sulla tua pagina. Un comando come può quindi caricare un gran numero di nodi DOM, aumentando l'uso della memoria.
• Evita dichiarazioni CSS complicate
  Fai particolare attenzione con comandi CSS complicati con un gran numero di nodi DOM. Ad esempio, dovresti controllare lo stato last-child per ogni elemento div sulla tua pagina.
• Usa web workers per risparmiare il thread principale del tuo browser
  I web workers sono JavaScript che possono essere eseguiti in parallelo con la tua pagina web. Puoi dare a questi web workers comandi che vengono eseguiti in background. Quando il web worker ha eseguito il comando, lo passa alla pagina originale. Il vantaggio è che puoi ancora eseguire JavaScript complessi senza che la pagina si blocchi.