First Contentful Paint (FCP)
Le First Contentful Paint (FCP) mesure le temps nécessaire pour que le premier élément de contenu (texte, image, SVG ou canevas non blanc) s'affiche à l'écran après que l'utilisateur a demandé une page. C'est le moment où les utilisateurs voient le premier signe que « cette page répond ».
Le First Contentful Paint (FCP) mesure le temps nécessaire pour que le premier élément de contenu (texte, image, SVG ou canevas non blanc) s'affiche à l'écran après que l'utilisateur a demandé une page. C'est le moment où les utilisateurs voient le premier signe que « cette page répond ».
Pourquoi c'est important
Les utilisateurs qui fixent un écran vide rebondissent vite. Les recherches du Nielsen Norman Group montrent que l'attention chute fortement dès que la première réponse visuelle dépasse 1 seconde. Le FCP n'est pas un Core Web Vital officiel aujourd'hui, mais il est un composant clé du score de performance Lighthouse et un indicateur avancé du LCP. Si le FCP est lent, le LCP ne pourra jamais être bon.
Seuils
| Évaluation | FCP |
|---|---|
| Bon | ≤ 1,8 s |
| À améliorer | 1,8 à 3,0 s |
| Médiocre | > 3,0 s |
Mesuré au 75e centile (p75) des données d'utilisateurs réels issues du Chrome User Experience Report.
TTFB → FCP → LCP → INP
Le chargement d'une page est une chronologie de métriques séquentielles.
- TTFB : temps jusqu'à ce que le serveur envoie le premier octet
- FCP : temps jusqu'à ce que le premier contenu soit affiché
- LCP : temps jusqu'à ce que le plus grand élément de contenu soit affiché
- INP : temps jusqu'à ce qu'une interaction de l'utilisateur réponde visuellement
L'ordre compte : si le TTFB est lent, le FCP ne peut pas être rapide, et le LCP ne peut pas l'être non plus. Le travail de performance doit commencer « par le haut ».
Ce qui ralentit le FCP
TTFB lent : un serveur lent ralentit le FCP d'autant.
Ressources bloquant le rendu : le CSS externe et le JS synchrone dans la balise <head> doivent être téléchargés et exécutés avant que le navigateur puisse afficher. S'ils sont trop nombreux ou trop volumineux, le FCP se bloque.
Grande taille du DOM : des milliers d'éléments dans le HTML initial coûtent du temps d'analyse et de mise en page.
Chargement des polices web : les polices personnalisées non encore chargées provoquent le FOIT (flash de texte invisible), donnant l'impression d'un FCP retardé.
Rendu côté client (CSR) : les applications React et Vue qui n'affichent le contenu qu'après avoir téléchargé et exécuté le bundle JS repoussent considérablement le FCP.
Comment optimiser
Améliorez le TTFB : CDN, mise en cache côté serveur et optimisation de la base de données, les fondations.
Éliminez les ressources bloquant le rendu : utilisez async et defer pour différer le JS. Intégrez le CSS critique en ligne et chargez le reste de manière asynchrone.
Rendu côté serveur (SSR) : utilisez des frameworks comme Next.js, Astro ou Remix pour pré-générer le HTML sur le serveur.
Optimisation des polices : font-display: swap affiche immédiatement un texte de repli pendant le chargement des polices personnalisées. Utilisez preload uniquement pour les polices critiques.
Réduisez les bundles JS : le tree shaking, le code splitting et la suppression des bibliothèques inutilisées réduisent tous le bundle initial.
Optimisation des images : faites un <link rel="preload"> de l'image principale et diffusez en WebP ou AVIF.
Outils de mesure
- PageSpeed Insights : données de terrain CrUX + données de laboratoire
- Lighthouse : diagnostics au niveau de la page
- Chrome DevTools → Performance : le FCP sur la chronologie
- Bibliothèque JS web-vitals : collectez des données d'utilisateurs réels sur votre propre site
Sources: