Lingue

First Contentful Paint (FCP): guida

Cosa misura il First Contentful Paint, qual è un buon punteggio FCP, perché non è un Core Web Vital, in cosa differisce da First Paint e LCP e come correggere un FCP lento.

Prima pubblicazione: 26 giu 2026 · Ultimo aggiornamento: 3 ago 2026 · Advanced
Lingue
AIScritto daAI v2

First Contentful Paint (FCP) è il tempo che intercorre dall’inizio del caricamento di una pagina al primo rendering di una parte qualsiasi del suo contenuto — testo, immagine, SVG o canvas non bianco — al 75° percentile degli utenti reali un buon valore è ≤1,8 s. NON è un Core Web Vital: i segnali di ranking sono LCP, INP e CLS. FCP è una metrica diagnostica (di laboratorio e sul campo), un elemento costitutivo di LCP — avviene allo stesso tempo o prima di LCP — utile soprattutto per individuare risorse che bloccano il rendering e un TTFB lento. In Lighthouse 10 pesa il 10% del punteggio Performance. Per migliorarlo, elimina CSS/JS che bloccano il rendering, riduci il TTFB, inserisci il CSS critico inline, usa font-display: swap e preconnetti alle origini necessarie.

TL;DR — FCP è il tempo che va dall’inizio della navigazione al primo rendering di un contenuto qualsiasi della pagina (testo, immagine, <svg> o <canvas> non bianco). Non è un Core Web Vital: è una metrica diagnostica supplementare, di laboratorio e sul campo, e un elemento costitutivo di LCP (FCP si verifica allo stesso tempo o prima di LCP). Soglie sul campo (p75): Buono ≤1,8 s, da migliorare ≤3,0 s, scarso >3,0 s. In Lighthouse 10 vale il 10% del punteggio Performance. Poiché il cronometro dell’FCP parte dalla navigazione — includendo reindirizzamenti, configurazione della connessione e TTFB — i numeri di laboratorio (Lighthouse) e sul campo (CrUX) spesso divergono. Intervieni dove si trova il problema: prima CSS/JS che bloccano il rendering, poi TTFB, poi font.

Che cosa misura l’FCP (con precisione)

La definizione di Google, tratta dall’articolo di Philip Walton su web.dev, è la spina dorsale dell’accuratezza: “First Contentful Paint (FCP) measures the time from when the user first navigated to the page to when any part of the page’s content is rendered on the screen.” — «First Contentful Paint (FCP) misura il tempo dal momento in cui l’utente ha iniziato a navigare verso la pagina a quello in cui una parte qualsiasi del contenuto della pagina viene visualizzata sullo schermo». «Contento», secondo lo stesso documento, significa “text, images (including background images), <svg> elements, or non-white <canvas> elements.” — «testo, immagini (comprese le immagini di sfondo), elementi <svg> o elementi <canvas> non bianchi».

La parola che fa tutto il lavoro è qualsiasi. A FCP non importa che cosa venga visualizzato: un logo da 40 pixel vale quanto una grande immagine hero. È il segnale «c’è qualcosa sullo schermo?», proprio per questo è un indicatore precoce e non una metrica di completamento.

Evidence for this claim FCP measures from navigation until the first text, image, SVG, or non-white canvas content is rendered. Scope: Current web.dev FCP definition and qualifying content types. Confidence: high · Verified: web.dev: First Contentful Paint

Un dettaglio facile da trascurare cambia il modo in cui si legge il numero: il cronometro dell’FCP parte dalla navigazione, quindi include tutto ciò che accade prima ancora che il tuo HTML venga analizzato. Il Key Point di Google dice: “FCP includes any unload time from the previous page, connection set up time, redirect time, and Time To First Byte (TTFB) which can be significant when measured in the field.” — «L’FCP include il tempo di scaricamento della pagina precedente, il tempo di configurazione della connessione, il tempo dei reindirizzamenti e il Time To First Byte (TTFB), che può essere significativo quando viene misurato sul campo». Un server che impiega 1,5 s a rispondere ha già consumato gran parte del tuo budget di 1,8 s prima che il browser abbia elaborato un solo byte.

L’FCP NON è un Core Web Vital

Voglio essere diretto, perché la maggior parte delle pagine usa formule prudenti: l’FCP non è un Core Web Vital e non fa parte dei segnali di ranking di Google. I Core Web Vitals sono LCP, INP e CLS, e l’FCP non viene menzionato da nessuna parte nella pagina di Google sui Core Web Vitals per il ranking nella Ricerca.

Nella tassonomia di Google, l’FCP è un «Other Web Vital», una metrica supplementare utile per la diagnosi. web.dev lo spiega così: “the metrics Time to First Byte (TTFB) and First Contentful Paint (FCP) are both vital aspects of the loading experience, and are both useful in diagnosing issues with LCP (slow server response times or render-blocking resources, respectively).” — «le metriche Time to First Byte (TTFB) e First Contentful Paint (FCP) sono entrambe aspetti fondamentali dell’esperienza di caricamento ed entrambe sono utili per diagnosticare problemi con LCP (rispettivamente, tempi di risposta del server lenti o risorse che bloccano il rendering).»

Per gli stakeholder, quindi, l’inquadramento onesto ha due lati: dichiarali entrambi senza esitazioni:

  • L’FCP non influisce direttamente sul ranking. Non ottimizzare l’FCP «per la SEO».
  • L’FCP è un ottimo strumento diagnostico per LCP, che invece influisce sul ranking. Le risorse che bloccano il rendering si manifestano prima nell’FCP.

FCP e First Paint (FP) a confronto

Vengono confusi continuamente:

  • First Paint (FP) scatta quando il browser dipinge qualsiasi cosa, anche un semplice colore di sfondo privo di contenuto reale.
  • FCP scatta solo quando viene visualizzato un contenuto idoneo: testo, immagini (comprese quelle di sfondo), elementi <svg> o elementi <canvas> non bianchi. È un elenco specifico, definito dalla specifica, non una regola generica di «qualunque contenuto del DOM»; è importante mantenere questa precisione, perché un’immagine di sfondo conta anche se non è testo nel DOM.

Quindi FP ≤ FCP, sempre. Nella maggior parte delle pagine sono quasi identici, perché è raro dipingere un colore di sfondo senza contenuto sovrapposto. Quando esiste una differenza significativa, di solito significa che uno sfondo cosmetico è stato dipinto prima di qualsiasi contenuto reale. La Paint Timing API restituisce entrambe le voci first-paint e first-contentful-paint, ma vale la pena analizzare l’FCP: l’FP raramente fornisce indicazioni utili per intervenire.

FCP e LCP a confronto

L’altra coppia che viene spesso confusa:

  • FCP = quando viene dipinto un contenuto qualsiasi. Scatta presto. Potrebbe essere un piccolo logo o un link di navigazione.
  • LCP = quando viene visualizzato l’elemento più grande nel viewport. Scatta in corrispondenza o dopo l’FCP.

La formulazione di Google è: FCP misura quando viene dipinto un contenuto qualsiasi e LCP quando viene dipinto il contenuto principale, quindi LCP è pensato per essere più selettivo. Leggilo come «più selettivo», non come «certificato corretto»: nessuna delle due metriche dimostra che il contenuto principale effettivo della pagina sia completo o utile al visitatore. FCP conferma solo che è stato dipinto un contenuto idoneo; LCP conferma che lo è stato il candidato idoneo più grande. Una pagina può avere un FCP veloce (logo a 0,5 s) e un LCP lento (immagine hero a 4 s): quella differenza è di per sé una diagnosi utile. E se l’FCP è vicino all’LCP, spesso è un buon segno: significa che la prima cosa dipinta è anche la più grande, senza una pittura anticipata sprecata su elementi dell’interfaccia che non interessano all’utente.

Evidence for this claim FCP answers when any eligible content first appears, while LCP tracks the largest eligible viewport candidate; neither metric proves the page's main content is complete or useful. Scope: field and lab Confidence: high · Verified: First Contentful Paint (FCP)

Vale la pena conoscere una stranezza della misurazione: a causa delle restrizioni di sicurezza sulla temporizzazione delle immagini cross-origin, in rari casi l’API del browser può riportare LCP prima di FCP. È un artefatto di misurazione, non qualcosa che sia avvenuto fisicamente.

Soglie e motivo della differenza tra laboratorio e dati sul campo

Soglie sul campo (CrUX, p75): buono ≤1,8 s · da migliorare ≤3,0 s · scarso >3,0 s. La guida di Google è misurare al 75° percentile dei caricamenti di pagina, separando mobile e desktop.

Evidence for this claim A good FCP is 1.8 seconds or less at the 75th percentile; above 3 seconds is poor. Scope: Current web.dev FCP field thresholds. Confidence: high · Verified: web.dev: First Contentful Paint

Ma Lighthouse desktop usa soglie diverse e più severe: verde circa 0–0,9 s, arancione 0,9–1,6 s, rosso oltre 1,6 s, perché il laboratorio esegue Chrome in condizioni pulite e limitato artificialmente su un dispositivo simulato, non in condizioni reali. (Queste fasce, come i pesi del punteggio sotto, dipendono dalla versione di Lighthouse: qui si riflette la documentazione dell’audit attuale al momento della stesura.) Il punteggio FCP di Lighthouse è “a comparison of your page’s FCP time and FCP times for real websites, based on data from the HTTP Archive.” — «un confronto tra il tempo FCP della tua pagina e i tempi FCP di siti reali, basato sui dati dell’HTTP Archive».

Questa è la fonte più comune di confusione sull’FCP, quindi fissala bene:

La soglia «buona» di 1,8 s è quella sul campo (p75 di CrUX). La soglia «verde» del desktop Lighthouse è circa 0,9 s. Sono scale diverse per scopi diversi.

I numeri sul campo e in laboratorio divergono soprattutto perché campionano popolazioni diverse, non perché uno sia universalmente «più vero». Lighthouse esegue una singola sessione pulita su condizioni fisse di dispositivo e rete. I dati sul campo/CrUX aggregano dispositivi, reti, stati della cache e tipi di navigazione reali, compresi ripristini dalla cache indietro/avanti e pagine prerenderizzate, che non ricevono automaticamente un nuovo FCP come una navigazione normale: richiedono una gestione del ciclo di vita dedicata (la libreria web-vitals lo fa per te). Nella maggior parte dei siti il valore sul campo è più alto, perché gli utenti reali portano con sé catene di reindirizzamenti, il tempo di scaricamento della pagina precedente e connessioni fredde che un test di laboratorio salta; ma è una tendenza, non una regola. Prima di leggere la differenza laboratorio/campo come un problema, verifica di confrontare condizioni omogenee (stessa classe di dispositivo, stesse condizioni di rete). Usa i dati sul campo per il numero reale e Lighthouse per la diagnosi.

Dove si colloca l’FCP nel punteggio Lighthouse

In Lighthouse 10, la versione attuale al momento della stesura ma non un valore permanente, l’FCP vale il 10% del punteggio Performance. La ponderazione completa è:

MetricaPeso
Total Blocking Time (TBT)30%
Largest Contentful Paint (LCP)25%
Cumulative Layout Shift (CLS)25%
First Contentful Paint (FCP)10%
Speed Index10%

Il punteggio Performance è una media ponderata dei punteggi delle singole metriche e Google nota che i pesi cambiano nel tempo con l’evolversi della ricerca: l’FCP è rimasto al 10% da Lighthouse 8 a 10, ma verifica la versione in esecuzione prima di trattare «10%» come un valore senza tempo. In pratica, un FCP perfetto può spostare il punteggio Lighthouse solo fino a un certo punto; inoltre un FCP scarso spesso segnala anche un LCP scarso (condividono le cause profonde), ma è una sovrapposizione da verificare, non qualcosa che il punteggio garantisca.

Che cosa causa un FCP lento

In ordine approssimativo di priorità:

  1. Risorse che bloccano il rendering — il principale problema. CSS e JS sincrono nel <head> obbligano il browser ad aspettare: non può costruire CSSOM e albero di rendering, quindi non può dipingere nulla finché quei file non vengono scaricati e analizzati.
  2. TTFB elevato — l’FCP non può scattare prima che arrivino i byte. Un server lento è il primo domino e rientra dentro la misurazione FCP.
  3. Catene di reindirizzamenti — ogni reindirizzamento aggiunge un round trip completo prima del primo byte.
  4. Strategia di caricamento dei webfont — font-display: block (o nessuna regola) può lasciare il testo invisibile per circa 3 s. Anche se il rendering scatta tecnicamente su uno sfondo, l’utente non vede nulla di utile.

Come correggerlo

L’elenco completo, ma con un ordine di priorità che la documentazione non fornisce. Sono leve comuni, non universali: controlla prima il tuo trace o filmstrip per capire quale risorsa o fase stia davvero ritardando il tuo candidato FCP, prima di applicare correzioni (preconnect, preload o modifica di font-display) che potrebbero non valere per la tua pagina:

Fai prima queste cose (i guadagni maggiori):

  • Elimina CSS e JavaScript che bloccano il rendering. Inserisci direttamente nel <head> il CSS critico above the fold; carica il resto in modo asincrono; aggiungi async/defer agli script non critici. Riposizionare un tag <link> non serve: il browser non dipingerà finché tutto il CSS non sarà caricato e analizzato, indipendentemente dalla posizione del tag.
  • Riduci il TTFB (tempo di risposta del server). Cache, CDN, un’origine più veloce: tutto ciò che fa arrivare prima il primo byte riduce direttamente l’FCP.
  • Correggi il caricamento dei font. Usa font-display: swap (mostra subito il testo di fallback e sostituisce il webfont quando pronto) o font-display: optional (salta il webfont se non è già in cache). Evita font-display: block per il testo critico: è la scelta peggiore per l’FCP.

Poi sistema il resto:

  • Preconnetti alle origini necessarie con <link rel="preconnect">: instaurare presto connessioni verso origini di terze parti importanti può far risparmiare 100–500 ms.
  • Precarica le richieste chiave (<link rel="preload">) per un font critico o per l’immagine LCP.
  • Minifica il CSS, rimuovi il CSS inutilizzato e rimuovi il JavaScript inutilizzato: file più piccoli vengono analizzati più velocemente e sbloccano prima il rendering.
  • Evita più reindirizzamenti, payload di rete enormi, asset statici con una policy di cache inefficiente, un DOM eccessivamente grande e una profondità eccessiva delle richieste critiche. È l’igiene generale del payload che alimenta il primo rendering.

La catena diagnostica FCP → TTFB → LCP

Ecco come userei davvero l’FCP: è l’inquadramento a cui la documentazione accenna senza svilupparlo. Tratta le tre metriche di caricamento come un unico flusso di lavoro:

  1. FCP alto → controlla le risorse che bloccano il rendering (CSS/JS nel <head>). È la causa più comune e la vittoria più rapida.
  2. Controlla anche il TTFB: poiché l’FCP lo include, un server lento gonfia l’FCP prima ancora che una risorsa che blocca il rendering entri in gioco. La guida di web.dev dice che, poiché il TTFB precede sia FCP sia LCP, il server dovrebbe rispondere abbastanza rapidamente da far raggiungere a un buon FCP il 75° percentile degli utenti.
  3. Gli stessi problemi spesso si propagano nell’LCP, la metrica che è davvero un segnale di ranking, perché FCP e LCP condividono spesso le cause profonde. È una sovrapposizione da verificare, non una garanzia: LCP ha fattori propri (dimensioni, priorità e percorso di caricamento del suo elemento più grande), quindi risolvere le cause dell’FCP non promette di risolvere l’LCP. È il posto giusto da cui iniziare, non l’ultimo passaggio.

Questo è il valore dell’FCP per chi si occupa di SEO: una lettura precoce ed economica della salute del percorso di caricamento, prima che la misurazione più selettiva dell’LCP sia terminata.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.