Guides

Chaque métrique de performance répond à une question, et elle ne vaut que ce que vaut la question. Le First Contentful Paint en pose une que tout visiteur se pose sans y penser : combien de temps est-ce que je regarde du vide ? Pas combien de temps avant que la page soit utilisable, pas combien de temps avant que la grande image arrive, juste combien de temps avant que quoi que ce soit apparaisse.

Cela fait du FCP le premier signal honnête qu'une page peut donner. Ce n'est pas non plus un Core Web Vital, pour des raisons qu'il vaut la peine de comprendre, et cela change le poids qu'il mérite dans vos priorités.

Ce que le FCP mesure vraiment

Le FCP mesure le temps écoulé entre le début de la navigation vers la page et le moment où une partie quelconque du contenu de la page est rendue à l'écran. Le mot contenu a ici une définition précise plutôt qu'intuitive : le texte, les images y compris les images de fond, les éléments SVG et les éléments canvas qui ne sont pas d'un blanc vide.

La distinction qui compte est celle entre First Paint et First Contentful Paint. Le First Paint se déclenche dès que le navigateur change un pixel, ce qui inclut peindre une couleur de fond par-dessus la page précédente. À cet instant, rien n'a été communiqué. Le FCP attend quelque chose qu'une personne pourrait réellement lire ou regarder.

Parce que le FCP est le premier contenu, il est par définition antérieur ou égal au Largest Contentful Paint. Sur une page dont le plus grand élément est aussi le premier, les deux valent le même nombre. Sur une page qui affiche un titre tout de suite et une image d'en-tête trois secondes plus tard, ils sont très éloignés, et c'est cet écart qui est la partie intéressante de la lecture.

Les seuils, et le Core Web Vital qu'il n'est pas

Google publie trois paliers pour le FCP, mesurés au 75e centile des chargements de page et séparés par type d'appareil : bon à 1,8 seconde ou moins, à améliorer entre 1,8 et 3 secondes, mauvais au-delà de 3 secondes. Mobile et ordinateur sont notés séparément, ce qui compte parce qu'un même site se retrouve régulièrement dans des paliers différents sur chacun.

• Total Blocking Time - 30 %
• Largest Contentful Paint - 25 %
• Cumulative Layout Shift - 25 %
• First Contentful Paint - 10 %
• Speed Index - 10 %

Le FCP n'est pas un Core Web Vital. Les Core Web Vitals sont le LCP, l'INP et le CLS, et ce sont ces trois-là qui alimentent les signaux d'expérience de page de Google. Le FCP se tient à côté comme métrique de diagnostic : rapporté par PageSpeed Insights et le Chrome User Experience Report, pondéré dans le score de performance Lighthouse, mais pas membre de l'ensemble qui touche au classement.

Ce n'est pas une raison de l'ignorer. C'est une raison de l'utiliser pour ce qu'il fait bien, à savoir vous dire si votre problème commence avant le rendu ou pendant. Dans le score de performance de Lighthouse 10, les poids se répartissent ainsi :

Ce qui le retarde vraiment

Le premier composant du FCP est le temps jusqu'au premier octet. Rien ne peut être peint avant que le premier octet de HTML n'arrive : un serveur lent, une requête lente ou une origine lointaine posent sous le FCP un plancher qu'aucun travail front-end ne relèvera. Si le TTFB est de 1,5 seconde, un FCP sous 1,8 est quasiment impossible.

Le deuxième, ce sont les ressources bloquantes pour le rendu. Une feuille de style dans le head doit être téléchargée et analysée avant que le navigateur ne peigne, parce que peindre avec les mauvais styles puis repeindre est pire qu'attendre. Les scripts synchrones dans le head bloquent purement et simplement l'analyse. Chacun est un aller-retour sérialisé inséré entre l'arrivée du HTML et l'apparition de quoi que ce soit.

Le troisième, ce sont les polices web, et c'est celui qu'on oublie. Une police déclarée avec font-display: block accorde au navigateur une période pendant laquelle le texte dans cette police est rendu invisible pendant que le fichier se télécharge. Un texte invisible n'est pas du contenu, donc le FCP l'attend. Passer à font-display: swap peint immédiatement une police de repli et bascule sur la vraie à son arrivée, ce qui échange un décalage visible contre un premier affichage de mots plus tôt.

Le mesurer soi-même

Sur le terrain, le FCP vient du Chrome User Experience Report, c'est-à-dire ce que PageSpeed Insights affiche dans sa section du haut pour de vrais utilisateurs sur de vraies connexions. C'est ce chiffre qu'il faut croire, parce qu'il reflète les appareils et les réseaux qu'ont réellement vos visiteurs plutôt que la machine sur laquelle vous testez.

Dans le navigateur, un PerformanceObserver qui écoute le type d'entrée paint rapporte à la fois first-paint et first-contentful-paint. Lire les deux est plus utile que lire l'un des deux. Un grand écart entre eux signifie que le navigateur avait des pixels à pousser et a choisi une couleur de fond d'abord, ce qui est la signature d'une feuille de style ou d'une police qui s'interpose entre votre HTML et votre lecteur.

FCP ou LCP : lequel corriger en premier

Si le FCP et le LCP sont tous deux mauvais, corrigez la cause commune et les deux bougent. Le TTFB, le CSS bloquant et les polices bloquantes se situent en amont des deux métriques : le travail passé là n'est jamais perdu. Si le FCP est bon et le LCP mauvais, le problème est propre à votre plus grand élément, en général une image d'en-tête non optimisée ou découverte trop tard par le scanner de préchargement.

Le motif à savoir reconnaître est l'inverse : un FCP mauvais avec un LCP acceptable. Cela veut dire que le navigateur est resté inactif avant de peindre quoi que ce soit puis a rattrapé vite, ce qui est presque toujours une ressource bloquante dans le head et non un problème de poids. C'est aussi la moins chère des trois situations à corriger.