FCP
Le premier pixel de contenu affiché : ce que la métrique mesure, ce qu’elle ne prouve pas, et pourquoi elle ne fait pas partie des Core Web Vitals.
Le First Contentful Paint mesure le délai entre l’arrivée sur une page et l’affichage de son premier contenu. La documentation de Google le définit comme « le temps écoulé entre le moment où l’utilisateur a navigué vers la page et celui où une partie quelconque du contenu de la page est rendue à l’écran ». Le seuil de bonne performance est de 1,8 seconde au 75e centile des chargements. Le FCP n’est pas un Core Web Vital : il sert à diagnostiquer le LCP.
Qu’est-ce que le First Contentful Paint ?
C’est l’instant où l’écran cesse d’être blanc. Le FCP, ou premier affichage de contenu, marque le moment où le navigateur peint le premier élément issu du document : le titre, un paragraphe, une image, n’importe quoi qui prouve au visiteur que la page arrive. Avant lui, le visiteur regarde une page vide et ne sait pas si le serveur répond. Google en fait une métrique dite centrée utilisateur, au même titre que le TTFB qui la précède et le LCP qui la suit. Le sigle s’emploie tel quel en français, sans traduction stabilisée.
Ce que le FCP compte, et à partir de quel seuil
Quatre types d’éléments déclenchent la mesure, et pas un de plus. La documentation web.dev les énumère : le texte, les images y compris les images de fond, les éléments svg et les éléments canvas non blancs. Un fond de couleur ne compte pas. Un cadre vide non plus. Les seuils sont fixés à 1,8 seconde pour la mention « bon » et 3,0 secondes pour la mention « mauvais », l’intervalle entre les deux valant « à améliorer ». Google précise que ces seuils se lisent au 75e centile des chargements de page, segmentés entre mobile et ordinateur. Le centile compte autant que la valeur : un FCP moyen à 1,2 seconde peut masquer un quart de visiteurs au-dessus de trois secondes.
Pourquoi le FCP n’est pas un Core Web Vital
Les Core Web Vitals sont trois, et le FCP n’en fait pas partie. Google y range le LCP pour le chargement, l’INP pour l’interactivité et le CLS pour la stabilité visuelle. Le FCP appartient à la catégorie des autres Web Vitals, dont la documentation dit qu’ils sont « utiles pour diagnostiquer des problèmes de LCP ». C’est exactement son emploi : un LCP dégradé accompagné d’un FCP dégradé désigne le serveur ou les ressources bloquantes, un LCP dégradé avec un FCP correct désigne l’élément principal lui-même. Le FCP garde par ailleurs un poids propre dans Lighthouse, où il compte pour 10 % du score de performance en version 10, derrière le Total Blocking Time à 30 %, le LCP et le CLS à 25 % chacun.
FCP ou LCP : ce que chacun désigne
Le FCP dit que la page commence, le LCP dit qu’elle est lisible. La différence tient en une phrase de la documentation : le FCP marque le début du rendu, quand le LCP « vise à mesurer le moment où le contenu principal de la page a fini de charger ». Sur un même chargement, le FCP précède donc toujours le LCP, ou coïncide avec lui quand le premier élément peint est aussi le plus grand. Un site peut afficher un FCP de 0,9 seconde et rester inutilisable pendant quatre secondes, le temps qu’une image d’en-tête arrive. L’inverse n’existe pas. Cette hiérarchie explique pourquoi une page se corrige dans l’ordre : d’abord la réponse du serveur, ensuite le premier rendu, enfin l’élément principal.
Ce qui retarde le premier affichage
Tout ce qui s’interpose entre la requête et le premier pixel de texte. La documentation web.dev nomme les causes une par une, et elles se lisent comme un ordre de travail. En tête, les ressources bloquant le rendu : une feuille de style dans l’en-tête et un script JavaScript synchrone suspendent l’affichage tant qu’ils ne sont pas téléchargés et exécutés. Viennent ensuite le temps de réponse du serveur, mesuré par le TTFB, les redirections en chaîne, le CSS et le JavaScript inutilisés, et la charge réseau totale. La dernière cause est la plus souvent oubliée : les polices web. Lighthouse la signale explicitement, « un point particulièrement important pour le FCP est le temps de chargement des polices », parce qu’un texte prêt mais invisible pendant que la police arrive ne compte pas comme un affichage de contenu. Aucune de ces corrections ne touche au design de la page.
Où lire son FCP
Deux familles d’outils, et elles ne racontent pas la même histoire. Le Chrome UX Report publie le FCP parmi ses métriques, à côté du First Paint, du DOM Content Loaded et des trois Core Web Vitals : ce sont des chargements réels, agrégés depuis les navigateurs Chrome des visiteurs. Lighthouse et PageSpeed Insights produisent au contraire une valeur de laboratoire, obtenue sur une machine simulée avec un réseau bridé. La seconde ne remplace jamais la première. Un rapport de laboratoire sert à comparer deux versions d’une page dans les mêmes conditions, pas à décrire ce que vivent les visiteurs. Une mesure maison donne la troisième voie : le navigateur expose la valeur par l’API Paint Timing, qu’un PerformanceObserver lit en écoutant l’entrée de type paint nommée first-contentful-paint. Vos chargements, vos appareils, votre trafic. Attention au piège des seuils dans le rapport de laboratoire : Lighthouse note un FCP en vert jusqu’à 1,8 seconde sur mobile, mais jusqu’à 0,9 seconde seulement sur ordinateur, et le passe en rouge au-delà de 1,6 seconde. Le 1,8 seconde cité partout est le seuil de terrain, pas la note d’un audit sur ordinateur.
Afficher un titre en 800 millisecondes coûte peu : un peu de HTML et une police système suffisent. La page peut ensuite mettre trois secondes à devenir utilisable. Le FCP borne le pire, il ne garantit pas le meilleur : un mauvais FCP condamne le LCP, un bon FCP ne le sauve pas.
Cas mesuré sur un site en production
Mesure du 8 septembre 2026. Sur un site vitrine suivi par une collecte de performance maison, trente jours de mesures réelles ont été relevés page par page, en ne retenant que les pages disposant d’au moins cinq valeurs de chaque métrique. Huit pages passent ce filtre. Sur trois d’entre elles, le LCP au 75e centile tombe sous le FCP : 846 millisecondes de FCP contre 726 de LCP sur une fiche du lexique, 1 044 contre 752 sur sa page d’accueil thématique, 940 contre 509 sur un annuaire. L’ordre est impossible sur un chargement unique, puisque le plus grand élément peint ne peut pas apparaître avant le premier. L’explication est dans les compteurs : la même page a remonté 23 valeurs de FCP et 16 de LCP, 25 contre 17 pour la deuxième. Les deux centiles ne portent pas sur la même population de chargements, et rien n’oblige les huit chargements manquants au LCP à ressembler aux autres. La conclusion tenable est plus modeste que la lecture directe : on tient deux distributions distinctes, sur un échantillon encore petit.
Faire expliquer ce terme par une IA
Ouvre le moteur de ton choix avec un prompt pré-rempli sur ce terme.
Sources
- 1web.dev, First Contentful Paint (FCP) : définition, éléments comptés, seuils 1,8 s et 3,0 s au 75e centile
- 2web.dev, Web Vitals : les trois Core Web Vitals et les métriques de diagnostic
- 3Chrome for Developers, Lighthouse Performance Scoring : pondération des cinq métriques
- 4Chrome for Developers, CrUX Methodology : métriques publiées par le Chrome UX Report
- 5Chrome for Developers, audit Lighthouse First Contentful Paint : seuils mobile et ordinateur, temps de chargement des polices
Questions fréquentes
Le FCP est-il un critère de classement ?−
Non, pas directement. Les signaux d’expérience sur la page reposent sur les trois Core Web Vitals, dont le FCP ne fait pas partie. Il agit indirectement, puisqu’un FCP dégradé entraîne presque toujours un LCP dégradé.
Quelle différence entre First Paint et First Contentful Paint ?+
Le First Paint accepte n’importe quel pixel, y compris une simple couleur de fond. Le FCP exige un contenu : texte, image, svg ou canvas non blanc. Le Chrome UX Report publie les deux séparément.
Pourquoi mon FCP diffère-t-il entre PageSpeed Insights et mes propres mesures ?+
Parce que l’un simule et l’autre observe. PageSpeed Insights exécute un test de laboratoire sur un réseau bridé, quand une collecte de terrain agrège les chargements réels de vos visiteurs. Deux méthodes, deux valeurs, aucune des deux fausse.
Comment améliorer un mauvais FCP ?+
En attaquant ce qui précède le premier rendu : le temps de réponse du serveur, mesuré par le TTFB, puis les feuilles de style et scripts qui bloquent l’affichage, puis les polices web chargées depuis une origine tierce.
Quel FCP viser sur mobile ?+
Le même seuil de 1,8 seconde, mais mesuré sur la population mobile seule. Google demande explicitement de segmenter le 75e centile entre mobile et ordinateur, car une valeur commune masque le retard du mobile.
Damien Hernandez
Consultant SEO senior, 17 ans d’expérience (Accor, Louvre Hotels, Infopro Digital). Spécialiste SEO technique, analyse de logs et optimisation pour les moteurs génératifs (GEO).