Il First Contentful Paint (FCP) misura quanto tempo passa dall’inizio della navigazione al momento in cui il browser mostra il primo contenuto della pagina: per esempio un testo, un’immagine, un SVG o un elemento canvas non vuoto.
È una metrica semplice da leggere, ma facile da interpretare male. Un FCP lento non ti dice automaticamente cosa rallenta il sito: il ritardo può essere già presente prima che arrivi l’HTML, oppure nascere dopo per CSS, JavaScript, font e altre risorse necessarie al primo rendering.
Secondo la documentazione web.dev sul First Contentful Paint, un FCP entro 1,8 secondi rientra nella fascia buona; tra 1,8 e 3 secondi è da migliorare, mentre oltre 3 secondi è considerato scarso. Per valutare l’esperienza reale il riferimento è il 75° percentile, separando mobile e desktop.
C’è poi un chiarimento importante: FCP non è un Core Web Vital. I tre Core Web Vitals correnti sono LCP, INP e CLS. FCP rimane però molto utile per capire cosa succede nelle prime fasi del caricamento. Se vuoi inquadrare queste metriche nel loro insieme, trovi la distinzione completa nella nostra guida ai Core Web Vitals.
Il modo più utile di lavorare su FCP è quindi questo:
FCP lento → individua dove si accumula il ritardo → identifica la causa → intervieni → misura di nuovo.
Non partire dal plugin, dall’hosting o dalla prima raccomandazione colorata di rosso che appare in PageSpeed Insights.
Cos’è il First Contentful Paint e cosa misura davvero
FCP registra il primo momento in cui appare sullo schermo qualcosa che può essere considerato contenuto.
La definizione ufficiale comprende testo, immagini — incluse le immagini di background — elementi SVG e canvas non bianchi. Non occorre che la pagina sia completa, né che sia già visibile il suo elemento principale.
Immagina una pagina con questa sequenza:
- il browser apre l’URL;
- attende la risposta;
- riceve e analizza l’HTML;
- scarica alcune risorse necessarie;
- compare il titolo;
- qualche istante dopo appare la grande immagine hero;
- il resto della pagina continua a caricarsi.
Se il titolo è il primo contenuto renderizzato, FCP si verifica al punto 5. La grande immagine potrebbe determinare invece il Largest Contentful Paint.
Questo spiega perché FCP è soprattutto una metrica di inizio della visualizzazione, non di completamento della pagina.
Quali elementi contano per FCP
Un contentful paint deve mostrare qualcosa che abbia un valore visivo maggiore del semplice sfondo della pagina.
Tra gli elementi che possono determinare FCP troviamo:
- testo;
- immagini normali;
- immagini di background;
- SVG;
- contenuto disegnato in un
canvas.
Il colore di fondo che passa da bianco a grigio non equivale quindi necessariamente alla comparsa di contenuto utile. Il punto centrale è quando l’utente inizia finalmente a vedere qualcosa appartenente alla pagina.
Questa distinzione è importante perché un sito può iniziare tecnicamente a “disegnare pixel” molto presto e lasciare comunque l’utente davanti a una schermata priva di contenuto.
First Paint e First Contentful Paint non sono la stessa cosa
First Paint (FP) indica il momento in cui il browser disegna per la prima volta qualcosa di visivamente diverso dallo stato iniziale.
First Contentful Paint restringe il concetto al primo contenuto vero e proprio.
La Paint Timing API documentata da MDN distingue infatti first-paint da first-contentful-paint: il secondo corrisponde alla comparsa del primo contenuto testuale o visuale del DOM.
Per una diagnosi orientata all’utente FCP è generalmente più significativo, perché risponde a una domanda concreta:
“Quando ho iniziato a vedere il contenuto della pagina?”
Non risponde però alla domanda successiva:
“Quando ho visto il contenuto principale che stavo aspettando?”
Per quella serve LCP.
Qual è un buon valore FCP
Le fasce utilizzate da PageSpeed Insights sono:
| First Contentful Paint | Valutazione |
|---|---|
| ≤ 1,8 s | Buono |
| > 1,8 s e ≤ 3 s | Da migliorare |
| > 3 s | Scarso |
Nei dati real-user non conviene leggere il valore come la media aritmetica di tutte le visite. PageSpeed Insights mostra il 75° percentile: in pratica il riferimento cerca di verificare che almeno una larga maggioranza delle esperienze rientri nella fascia desiderata.
Questo evita di giudicare il sito soltanto dal tuo computer.
Un FCP di 900 ms ottenuto una volta su fibra, desktop potente e cache calda non dimostra che gli utenti mobile stiano vivendo la stessa esperienza.
FCP, LCP, TTFB e Core Web Vitals: metriche diverse della stessa sequenza
FCP acquista molto più significato quando smetti di guardarlo isolatamente e lo inserisci nella sequenza di caricamento.
Una rappresentazione volutamente semplificata è:
navigazione → rete/redirect → TTFB → HTML → risorse necessarie al rendering → FCP → contenuto principale → LCP
Non tutte le pagine seguono esattamente lo stesso percorso, ma questo modello aiuta a capire dove cercare.
First Contentful Paint vs Largest Contentful Paint
La differenza più importante è questa:
FCP misura il primo contenuto. LCP cerca di rappresentare la comparsa del contenuto principale.
Una pagina può quindi avere:
- FCP rapido e LCP rapido;
- FCP rapido e LCP lento;
- FCP lento e LCP ancora più lento.
Supponiamo che una pagina mostri il titolo dopo 800 ms, ma che la grande immagine hero venga renderizzata dopo 4 secondi.
L’FCP può essere ottimo, mentre LCP è problematico.
Viceversa, se il browser rimane completamente vuoto per 2,5 secondi prima di mostrare qualsiasi elemento, è già evidente un problema nella parte iniziale della pipeline.
Per l’analisi specifica del contenuto principale puoi approfondire la nostra guida al Largest Contentful Paint.
Le due metriche vanno quindi lette insieme quando la relazione aiuta la diagnosi, non ottimizzate come due punteggi indipendenti.
Perché il TTFB condiziona il momento del primo rendering
Prima di renderizzare il contenuto della risposta, il browser deve arrivare al punto in cui quella risposta comincia a essere disponibile.
Il Time to First Byte precede FCP. Inoltre FCP misurato sul campo può includere tempo legato alla navigazione precedente, setup della connessione, redirect e TTFB.
Questo produce una distinzione diagnostica molto utile.
Se hai:
TTFB 1,8 s → FCP 2,1 s
gran parte dell’attesa si sta probabilmente accumulando prima o attorno alla risposta iniziale. Ridurre 20 KB di CSS potrebbe non essere la prima priorità.
Se invece hai:
TTFB 300 ms → FCP 2,8 s
esiste un intervallo molto più ampio dopo l’arrivo iniziale della risposta. Qui ha senso guardare con maggiore attenzione il percorso di rendering: CSS, script, font, dipendenze e modalità con cui viene prodotto il contenuto iniziale.
Questa non è una formula matematica universale, ma un modo efficace per restringere il campo della diagnosi.
Per approfondire la fase precedente al rendering trovi la nostra guida al Time to First Byte.
FCP è un Core Web Vital?
No.
Ad agosto 2026 i Core Web Vitals indicati dalla documentazione Google sono:
- LCP, per il caricamento;
- INP, per la reattività;
- CLS, per la stabilità visiva.
First Contentful Paint non appartiene a questo trio.
La confusione nasce perché PageSpeed Insights e Lighthouse mostrano diverse metriche nello stesso report. Vederle vicine non significa che abbiano tutte lo stesso ruolo.
PageSpeed Insights include FCP sia tra i dati real-user disponibili da CrUX sia nelle metriche del test di laboratorio Lighthouse, ma il Core Web Vitals assessment viene determinato dalle metriche correnti LCP, INP e CLS.
First Contentful Paint e SEO: cosa Google conferma e cosa no
Qui conviene separare i livelli.
GOOGLE_CONFIRMED: Google utilizza i Core Web Vitals nei propri sistemi di ranking e raccomanda di raggiungere una buona esperienza di pagina. I Core Web Vitals correnti sono LCP, INP e CLS.
NON CONFERMATO: Google non documenta FCP come un ranking factor autonomo con una relazione diretta del tipo “riduci FCP di X millisecondi e guadagni Y posizioni”.
Quindi non ha senso scrivere:
FCP sotto 1,8 secondi = ranking migliore.
Ha invece senso dire:
un FCP problematico può indicare un caricamento iniziale inefficiente; comprenderne la causa aiuta a migliorare l’esperienza e può far emergere problemi che coinvolgono anche metriche più direttamente rilevanti nel quadro Core Web Vitals.
La distinzione evita di trasformare una metrica diagnostica in una promessa SEO che Google non ha fatto.
Come misurare correttamente il First Contentful Paint
Il valore FCP diventa utile soltanto quando sai da dove proviene.
Un numero raccolto dagli utenti reali e uno ottenuto da una simulazione Lighthouse non stanno descrivendo necessariamente la stessa esperienza.
PageSpeed Insights: FCP nei field data e nel test Lighthouse
PageSpeed Insights riunisce due livelli distinti.
Il primo è costituito dai field data, cioè dati real-user provenienti dal Chrome User Experience Report.
Il secondo deriva da Lighthouse, che carica la pagina in un ambiente simulato e produce metriche e indicazioni diagnostiche.
La documentazione ufficiale di PageSpeed Insights conferma che i dati CrUX mostrano FCP su una finestra mobile dei 28 giorni precedenti, mentre il laboratorio esegue una nuova simulazione sulla pagina analizzata.
I due dati rispondono quindi a domande differenti:
| Dato | Domanda principale |
|---|---|
| Field FCP | Cosa hanno sperimentato gli utenti reali? |
| Lab FCP | Cosa succede in questa simulazione controllata? |
È perfettamente possibile che non coincidano.
Perché FCP lab e FCP degli utenti reali possono essere diversi
Nel mondo reale cambiano:
- dispositivo;
- potenza della CPU;
- rete;
- località;
- cache;
- stato della connessione;
- eventuali redirect;
- contenuto personalizzato;
- condizioni dell’infrastruttura.
Il laboratorio restringe invece queste variabili per rendere il test più riproducibile.
Per questo un miglioramento nel lab è un buon segnale tecnico, ma non equivale immediatamente a un miglioramento del dato CrUX.
Se oggi riduci FCP attraverso una modifica CSS, il nuovo test Lighthouse può accorgersene subito. Il dato real-user continuerà invece a rappresentare una finestra di esperienze che comprende anche giorni precedenti alla modifica.
Controlla se stai leggendo dati URL o origin
C’è un altro dettaglio che può cambiare completamente l’interpretazione.
CrUX richiede un campione sufficiente di esperienze reali. Se la singola pagina non dispone di dati sufficienti, PageSpeed Insights può mostrare dati a livello di origin, cioè riferiti al sito nel suo insieme. Se manca anche quel campione, la sezione real-user può non essere disponibile.
Quindi, prima di concludere:
“Questa pagina ha FCP 2,6 secondi”
controlla se il dato appartiene realmente a quella URL.
Se stai leggendo l’origin, la formulazione corretta è più simile a:
“Gli utenti dell’origin mostrano questo FCP aggregato.”
Una homepage pesante e un articolo semplice possono avere comportamenti diversi anche se appartengono allo stesso dominio.
Lighthouse, DevTools, GTmetrix e WebPageTest: quale usare
Non serve scegliere un unico strumento per tutto.
PageSpeed Insights è un buon punto di partenza perché combina field data e laboratorio.
Lighthouse è utile per ottenere una simulazione ripetibile e individuare gli Insights collegati alla pagina. Se vuoi approfondirne il funzionamento separatamente, trovi la nostra guida a Google Lighthouse.
Chrome DevTools diventa molto utile quando vuoi osservare timeline, richieste, dipendenze e attività di rendering.
GTmetrix può offrire un’ulteriore lettura del caricamento e del waterfall; abbiamo spiegato come usarlo nella guida a GTmetrix.
Per indagini più controllate su località, rete e waterfall puoi invece ricorrere a WebPageTest.
Il punto non è raccogliere cinque valori di FCP e farne la media. È utilizzare lo strumento che permette di rispondere alla domanda successiva:
perché il primo contenuto arriva tardi?
Misurare FCP in JavaScript
Per un monitoraggio personalizzato puoi utilizzare la Paint Timing API.
Un esempio minimale con PerformanceObserver è:
const observer = new PerformanceObserver((list) => {
const fcp = list
.getEntries()
.find((entry) => entry.name === 'first-contentful-paint');
if (fcp) {
console.log(`FCP: ${fcp.startTime} ms`);
}
});
observer.observe({
type: 'paint',
buffered: true
});
La documentazione MDN espone first-contentful-paint attraverso PerformancePaintTiming; web.dev segnala però che una misurazione FCP completa presenta alcuni casi particolari, come pagine in background, back/forward cache, prerendering e iframe cross-origin. Per una raccolta real-user più robusta Google consiglia di considerare la libreria web-vitals, che gestisce varie di queste differenze.
Per un controllo occasionale non è necessario implementare JavaScript personalizzato. Diventa interessante quando vuoi costruire un sistema RUM e analizzare FCP insieme ad altre metriche per segmenti di utenti reali.
Perché il First Contentful Paint è lento
Un FCP alto è il risultato finale. La causa può trovarsi in punti molto diversi della pipeline.
Per questo “riduci FCP” non è ancora una diagnosi.
Il documento HTML arriva tardi
Il primo scenario è quello più semplice da isolare.
Se passa molto tempo prima che il browser inizi a ricevere la risposta iniziale, FCP parte già in svantaggio.
Tra le aree da verificare possono esserci:
- redirect;
- latenza di rete;
- elaborazione backend;
- cache;
- CDN;
- database;
- applicazione;
- infrastruttura.
Non significa automaticamente “hosting lento”. Il TTFB osservato sul campo comprende più parti della navigazione e va interpretato nel contesto del modo in cui il sito serve il contenuto.
Se il problema è qui, ottimizzare un font o ridurre un piccolo file CSS potrebbe spostare poco il risultato complessivo.
CSS che blocca il primo rendering
Una volta ricevuto l’HTML, il browser deve capire come rappresentare la pagina.
Gli stylesheet necessari nel percorso iniziale possono diventare render-blocking: prima del primo paint il browser deve avere informazioni sufficienti per costruire correttamente ciò che deve disegnare.
Il problema diventa evidente quando vengono caricati molti stili non necessari alla prima viewport oppure quando un grande bundle CSS contiene regole utilizzate soltanto molto più avanti nella pagina.
La documentazione Chrome indica come strategie possibili il rinvio delle richieste non necessarie al first paint, l’inlining selettivo di piccole risorse critiche e la riduzione del CSS o degli script alla parte effettivamente necessaria.
Attenzione però: “inline tutto il CSS” non è una regola generale.
Chrome stesso segnala che l’inlining è una tecnica avanzata e può introdurre problemi. L’obiettivo è ridurre il percorso critico, non trasformare ogni foglio di stile in HTML inline.
JavaScript può ritardare la comparsa del contenuto
JavaScript può incidere su FCP in modi differenti.
Un primo caso riguarda script che interferiscono con il percorso di parsing e rendering.
Un secondo caso è ancora più importante: il contenuto iniziale potrebbe non esistere realmente finché JavaScript non lo costruisce.
Pensa a una pagina che invia rapidamente un HTML quasi vuoto e delega al browser il rendering dell’interfaccia. Un TTFB molto basso non basta: il browser deve ancora scaricare, analizzare ed eseguire il codice necessario prima che il primo contenuto compaia.
Web.dev sottolinea proprio che un sito server-rendered con un TTFB leggermente superiore può comunque mostrare FCP e LCP migliori rispetto a un’esperienza fortemente client-rendered.
Quindi:
TTFB buono + FCP lento + contenuto dipendente da JavaScript
è un pattern molto diverso da:
TTFB lento + HTML già pronto per il rendering.
I web font possono ritardare il primo testo
I font sono un’altra causa da controllare quando il primo contenuto visibile è testuale.
Un font può essere scoperto tardi perché la dichiarazione @font-face si trova dentro uno stylesheet esterno; deve poi essere richiesto, scaricato e infine utilizzato per il rendering.
La guida web.dev sull’ottimizzazione dei web font segnala esplicitamente che file di font grandi possono peggiorare FCP e che font-display modifica il comportamento con cui il testo viene mostrato durante il caricamento del carattere.
Con font-display: swap, per esempio, il browser può mostrare immediatamente un font di fallback e sostituirlo successivamente con quello definitivo.
Questo può aiutare a non mantenere invisibile il testo, ma introduce un altro tema: se fallback e web font hanno metriche molto diverse, lo swap può essere visivamente evidente.
L’ottimizzazione quindi non consiste semplicemente nel “mettere swap ovunque”. Devi valutare rapidità di comparsa, coerenza tipografica e stabilità del layout.
Immagini e altre risorse: quando incidono davvero su FCP
Le immagini normali non vanno trattate automaticamente come CSS render-blocking.
Possono però diventare importanti se il primo contenuto disponibile è proprio un’immagine oppure se il rendering iniziale dipende da un’immagine di background CSS scoperta in ritardo.
Lo stesso principio vale per risorse di terze parti.
Se il primo blocco visibile dipende da un servizio esterno, un widget, uno script o una risorsa cross-origin, stai introducendo ulteriori connessioni e dipendenze prima del contenuto.
Il problema quindi non è il numero assoluto di richieste. La domanda migliore è:
quali richieste sono realmente necessarie prima del primo paint?
Come migliorare FCP in base alla causa reale
Prima di modificare il sito, metti in relazione almeno TTFB, FCP e LCP.
Una matrice diagnostica iniziale può essere questa:
| Pattern | Area da investigare per prima |
|---|---|
| TTFB alto + FCP alto | Navigazione, backend, cache, infrastruttura |
| TTFB buono + FCP alto | Critical rendering path, CSS, JS, font |
| FCP buono + LCP alto | Risorsa/contenuto principale e rendering LCP |
| Lab scarso + field buono | Condizioni della simulazione e variabilità |
| Lab buono + field scarso | Problema real-user, segmentazione utenti/rete/device |
| FCP lento solo su alcune pagine | Template e dipendenze specifiche della pagina |
| FCP lento in quasi tutto il sito | Risorse o infrastruttura condivise |
Non è una tabella di causalità automatica. Serve a decidere dove guardare per primo.
Riduci il TTFB quando è davvero il collo di bottiglia
Se quasi tutto il ritardo avviene prima di FCP e TTFB ne occupa una quota importante, intervieni prima sulla fase iniziale.
Su WordPress significa verificare, a seconda del caso:
- cache pagina;
- elaborazione PHP;
- query lente;
- chiamate esterne;
- plugin;
- tema;
- risorse server;
- CDN;
- redirect;
- località e rete.
Non cambiare hosting soltanto perché FCP è rosso.
Prima verifica se l’attesa nasce davvero prima della risposta.
Riduci le risorse CSS che impediscono il primo paint
Se il server risponde rapidamente ma il browser resta fermo prima di mostrare contenuto, analizza le richieste render-blocking.
Nelle versioni correnti di Lighthouse il vecchio audit “Eliminate render-blocking resources” è stato spostato, da Lighthouse 13, nel nuovo Insight Render-blocking requests. L’Insight identifica richieste che impediscono il primo rendering e suggerisce di rinviare ciò che non serve subito, ridurre il contenuto non necessario e valutare l’inlining delle sole risorse critiche appropriate.
La logica pratica è:
CSS necessario subito → rendilo disponibile rapidamente
CSS non necessario subito → evita che blocchi inutilmente il rendering iniziale
Su un sito WordPress la difficoltà è che tema, page builder e plugin possono aggiungere stili globali anche quando la singola pagina ne usa solo una parte.
Non eliminare però CSS soltanto perché Coverage lo mostra inutilizzato durante un singolo caricamento: stati interattivi, breakpoint e componenti non attivati in quel test possono richiederlo successivamente.
Evita che il contenuto iniziale dipenda inutilmente da JavaScript
Prima di rinviare uno script chiediti cosa succede se viene eseguito più tardi.
Per codice non critico puoi valutare strategie come defer, caricamento posticipato o eliminazione di componenti non utilizzati.
Ma c’è una differenza fra:
JavaScript non necessario al primo rendering
e
JavaScript che costruisce il primo contenuto.
Nel secondo caso non puoi limitarti a differirlo senza ripensare il modo in cui quella parte viene renderizzata.
Su WordPress questo problema compare spesso quando animazioni, page builder, slider, cookie tool, widget, tracking e integrazioni di terze parti entrano tutti nella fase iniziale.
Il criterio non deve essere “meno JavaScript possibile”, ma:
meno lavoro non necessario prima che l’utente possa vedere il contenuto.
Ottimizza caricamento e rendering dei font
Se il testo iniziale aspetta i font, controlla:
- quanti font e pesi stai caricando;
- quando vengono scoperti;
- dimensione dei file;
font-display;- caricamento da origin esterni;
- necessità reale dei diversi variant.
Se utilizzi Google Fonts, può essere utile anche approfondire la nostra guida a Google Fonts.
Il preload può anticipare la scoperta di un font realmente critico, ma non va applicato indiscriminatamente. web.dev avverte che un uso eccessivo di preload può sottrarre banda ad altre risorse importanti. Per i font preloaded è inoltre necessario gestire correttamente crossorigin.
Usa preload e preconnect soltanto quando risolvono una dipendenza reale
preconnect e preload non sono interruttori “turbo”.
preconnect permette di avviare in anticipo la connessione verso un origin esterno che servirà presto.
preload chiede al browser di iniziare prima il download di una specifica risorsa importante e scoperta tardivamente.
La guida web.dev ai resource hints raccomanda di riservare preconnect agli origin realmente critici e preload alle risorse critiche che altrimenti verrebbero scoperte tardi. Un uso eccessivo può provocare contesa di banda e peggiorare, anziché migliorare, il caricamento.
In pratica:
preload di tutto ≠ pagina più veloce.
Stai assegnando priorità. Se tutto diventa prioritario, hai smesso di stabilire priorità.
Elimina redirect e dipendenze iniziali evitabili
Ogni passaggio prima del documento finale può consumare tempo che si riflette anche su FCP.
Questo vale per redirect evitabili, ma anche per catene di dipendenze.
Se l’HTML deve prima caricare un CSS, quel CSS deve scoprire un altro CSS e solo dopo viene scoperto il font necessario al primo titolo, hai creato una catena.
Ottimizzare FCP significa spesso accorciare questa sequenza, non semplicemente ridurre la dimensione complessiva della pagina.
Una pagina può trasferire molti dati dopo FCP senza ritardare il primo contenuto. Al contrario, una piccola risorsa collocata nel punto sbagliato della catena può impedire al browser di renderizzare per molto più tempo del previsto.
First Contentful Paint su WordPress: cosa controllare prima dei plugin
Su WordPress è facile trasformare la diagnosi in una lista di plugin di performance.
È quasi sempre il percorso sbagliato.
Un plugin di cache o ottimizzazione può essere utilissimo se la sua funzione corrisponde alla causa del ritardo. Può anche creare conflitti o spostare il problema se viene configurato senza sapere quale dipendenza stai cercando di eliminare.
Cache e backend quando il ritardo nasce prima dell’HTML
Se TTFB è elevato, inizia dal percorso che produce la risposta.
Per una pagina WordPress dinamica possono entrare in gioco PHP, database, plugin, tema, richieste remote e cache.
La page cache può ridurre molto il lavoro necessario per produrre pagine che possono essere servite già generate, ma non risolve ogni causa possibile: un redirect remoto, una rete problematica o una CDN configurata male non diventano automaticamente veloci perché hai attivato una cache applicativa.
Parti sempre dal timing osservato.
Tema, page builder e CSS del contenuto iniziale
Un tema o page builder può caricare grandi stylesheet condivisi tra molti componenti.
Questo non significa automaticamente che il builder sia “lento”. Devi verificare cosa viene effettivamente richiesto prima del primo paint sulla pagina problematica.
Controlla soprattutto:
- CSS globale;
- CSS del template;
- fogli di stile dei widget;
- icon set;
- animazioni iniziali;
- componenti che non compaiono nella prima viewport.
La domanda utile è:
questa risorsa deve davvero bloccare il rendering del primo contenuto?
JavaScript di plugin e servizi di terze parti
Analytics, advertising, consent management, chat, mappe, video embed, social widget e altri servizi possono aggiungere lavoro nella fase iniziale.
Non devi rimuoverli a priori.
Devi capire quando servono.
Se una chat è visibile solo dopo che l’utente clicca un pulsante, può non essere necessario caricare tutto il relativo JavaScript prima che compaia il titolo dell’articolo.
Se invece un consent manager deve intervenire prima dell’attivazione di determinate risorse per ragioni di conformità, il problema non si risolve semplicemente differendolo: serve una configurazione tecnicamente e legalmente corretta.
Performance e funzionalità vanno ottimizzate insieme.
Font e risorse esterne
WordPress non gestisce i font in un unico modo.
Il tema può caricarli localmente, un page builder può aggiungerne altri, un plugin può introdurre un diverso icon font e qualche componente esterno può aprire ulteriori connessioni.
Prima di aggiungere preconnect o preload, costruisci l’inventario.
È molto più utile scoprire che il primo titolo dipende da un unico font scoperto tardi che precaricare cinque famiglie tipografiche “per sicurezza”.
Quando un plugin di performance può aiutare
Un plugin di ottimizzazione ha senso quando sai cosa deve fare.
Per esempio:
- page cache → se l’elaborazione dinamica contribuisce al TTFB;
- rimozione/riduzione CSS non utilizzato → se CSS non necessario blocca il rendering;
- delay/defer JavaScript → se script non critici entrano troppo presto;
- gestione font → se discovery e rendering dei caratteri ritardano il contenuto;
- CDN/cache asset → se la distribuzione delle risorse è parte del problema.
Il plugin è quindi l’implementazione dell’intervento, non la diagnosi.
La sequenza corretta rimane:
misura → individua il collo di bottiglia → scegli l’intervento → configura → verifica.
Come verificare se l’ottimizzazione FCP ha funzionato
Una modifica non è conclusa perché PageSpeed Insights diventa verde una volta.
Devi verificare che il risultato sia ripetibile e che non abbia peggiorato qualcos’altro.
Ripeti il test nelle stesse condizioni
Per confrontare prima e dopo, cerca di mantenere stabili:
- dispositivo simulato;
- modalità mobile/desktop;
- rete;
- località;
- stato della cache quando controllabile;
- URL;
- strumento.
Esegui più misurazioni.
Le performance web presentano variabilità naturale, quindi il confronto fra un singolo “prima” e un singolo “dopo” può essere fuorviante. PageSpeed Insights stesso segnala che hardware, rete e contesa di risorse possono provocare variazioni tra le esecuzioni.
Confronta FCP con TTFB e LCP
Supponiamo che tu riesca a portare:
FCP da 2,8 s a 1,4 s
È un miglioramento rilevante del momento in cui appare il primo contenuto.
Ma se LCP rimane a 5 secondi, il lavoro non è necessariamente finito.
Ora la pagina comunica prima che sta caricando, ma l’utente continua ad aspettare a lungo il contenuto principale.
Lo scenario opposto è altrettanto interessante.
Se FCP rimane mediocre perché il primo contenuto è volutamente complesso ma LCP, interattività e user experience complessiva sono buoni, non devi distruggere il design soltanto per inseguire qualche decimo nel punteggio.
La metrica deve aiutarti a prendere una decisione migliore, non sostituire la decisione.
Aspetta i field data prima di giudicare l’esperienza reale
Il test di laboratorio permette di controllare immediatamente l’effetto tecnico.
I dati CrUX no.
PageSpeed Insights usa una finestra mobile dei 28 giorni per l’esperienza real-user. Di conseguenza il dato cambia progressivamente man mano che nuove visite sostituiscono quelle più vecchie nella finestra.
Il workflow più affidabile è quindi:
field data segnalano il problema → laboratorio identifica la causa → modifica → laboratorio verifica → field data confermano nel tempo.
Errori comuni quando si ottimizza First Contentful Paint
Alcuni errori ricorrono perché si parte dal numero anziché dal meccanismo.
Considerare FCP un Core Web Vital. Non lo è. Rimane una metrica utile, ma ha un ruolo differente.
Interpretare FCP come ranking factor autonomo. Google documenta LCP, INP e CLS come Core Web Vitals; non esiste una regola pubblica “FCP sotto 1,8 s = più ranking”.
Cambiare hosting senza aver controllato TTFB. Se il server risponde in 250 ms e il primo contenuto compare dopo 3 secondi, il collo di bottiglia potrebbe trovarsi soprattutto altrove.
Precaricare tutto. Preload assegna priorità e consuma banda; un uso indiscriminato può creare nuove competizioni tra risorse.
Rinviare JavaScript alla cieca. Uno script può essere non critico oppure può costruire il contenuto che stai cercando di mostrare. Le due situazioni richiedono interventi differenti.
Ottimizzare soltanto le immagini. Un’immagine enorme può essere un problema, soprattutto per LCP, ma FCP può essere ritardato prima ancora che l’immagine entri realmente in gioco.
Installare più plugin di performance contemporaneamente. Se due strumenti modificano cache, CSS e JavaScript senza una strategia chiara, aumenta anche la difficoltà nel capire quale intervento abbia prodotto un miglioramento o una regressione.
Inseguire PageSpeed 100. Un Performance Score è un output di laboratorio. Non è un punteggio SEO e non sostituisce l’analisi dell’esperienza reale.
Conclusione
Il First Contentful Paint è il momento in cui una pagina smette di apparire vuota e inizia a mostrare contenuto. Proprio per questo è una buona spia delle prime fasi del caricamento, ma non è una diagnosi completa.
Se FCP è lento, il passo successivo non dovrebbe essere “quale plugin installo?”, ma:
dove viene consumato il tempo prima del primo paint?
Se l’attesa è già presente nel TTFB, guarda la fase precedente alla risposta. Se TTFB è buono e FCP rimane alto, sposta l’attenzione sul critical rendering path: CSS, JavaScript, font e dipendenze necessarie al contenuto iniziale.
Se invece FCP è buono ma LCP è lento, hai probabilmente superato il problema del primo segnale visivo e devi seguire il caricamento fino al contenuto principale.
È questo il valore reale di FCP: non darti un altro numero da rendere verde, ma aiutarti a restringere progressivamente il punto in cui la pagina sta facendo aspettare l’utente.