First Contentful Paint (FCP) : ce que c'est, comment le mesurer et l'améliorer

Améliorer le First Contentful Paint

Le First Contentful Paint (FCP) est le moment où un navigateur dessine le premier élément significatif sur une page pour que le visiteur puisse le voir. En d'autres termes, c'est le moment où un navigateur affiche quelque chose à l'écran pour la première fois. En tant que tel, le FCP est un bon moyen de mesurer la vitesse de chargement perçue.

Vous pouvez améliorer le FCP en vous assurant qu'un navigateur peut commencer le rendu sans aucun délai. Ci-dessous, vous apprendrez ce qu'est le FCP, comment le mesurer et 15 techniques éprouvées pour le rendre plus rapide.

Qu'est-ce que le First Contentful Paint (FCP) ?

Le First Contentful Paint (FCP) est une façon de mesurer la vitesse de chargement des pages. Vous ne pouvez pas résumer la vitesse d'une page en un seul point dans le temps ; il y a en réalité plusieurs moments pendant le processus de chargement où un visiteur pourrait percevoir le site comme se chargeant rapidement ou lentement. Le FCP mesure la différence de temps entre la demande de la page et le moment où le premier contenu significatif est affiché à l'écran pour la première fois.

Qu'est-ce que cela vous dit exactement ? Cela vous dit que le FCP est principalement une « métrique centrée sur l'utilisateur » car il dit quelque chose sur la vitesse de chargement qu'un visiteur expérimente. Il dit quelque chose sur l'expérience utilisateur. Au moment du FCP, vous pouvez être sûr qu'un visiteur voit réellement « quelque chose » à l'écran.

Décomposons les mots : « First », « Contentful » et « Paint ».

1. First : Par First, nous entendons bien sûr le tout premier moment exact où quelque chose de substantiel apparaît dans votre navigateur.
2. Contentful : Par contentful, nous entendons un élément HTML avec du contenu. Donc pas un élément de mise en page comme un élément vide ou une couleur de fond, mais plutôt du texte, une image (y compris une image de fond), un SVG ou un canvas.
3. Paint : Paint signifie (plus ou moins) que le navigateur est prêt à afficher quelque chose à l'écran. Cela semble simple mais c'est en réalité la tâche la plus complexe du navigateur. Pour afficher quelque chose à l'écran, un navigateur doit être prêt à calculer toutes les caractéristiques d'un élément. Ci-dessous un exemple du processus de rendu nécessaire avant que quoi que ce soit puisse être ajouté à l'écran.

FCP vs LCP : quelle est la différence ?

Le FCP et le LCP (Largest Contentful Paint) mesurent tous deux les performances de chargement, mais ils capturent des moments différents dans la chronologie de chargement de la page. Comprendre la différence vous aide à prioriser correctement votre travail d'optimisation.

En pratique, le FCP se déclenche souvent bien avant le LCP. Par exemple, une page peut afficher un titre (FCP) en 400 ms mais attendre encore 2 secondes pour que l'image hero se charge (LCP). Si votre FCP est lent, votre LCP le sera presque certainement aussi, car le FCP capture le tout premier goulot d'étranglement dans le pipeline de rendu. En savoir plus dans notre guide complet du LCP.

Qu'est-ce qu'un bon score First Contentful Paint ?

Un bon score FCP est tout ce qui est inférieur à 1,8 seconde. Si votre score FCP est entre 1,8 et 3 secondes, il nécessite une amélioration. Tout score FCP supérieur à 3 secondes est considéré comme mauvais. Pour atteindre le seuil recommandé pour le First Contentful Paint, au moins 75 % de vos visiteurs doivent avoir un « bon » score FCP.

Comme toujours avec les métriques de performance, un score First Contentful Paint plus rapide est meilleur qu'un score plus lent.

Comment mesurer votre First Contentful Paint (FCP) ?

Le FCP est mesuré par Google en collectant des données d'utilisateurs réels. Ces données sont stockées dans le jeu de données CrUX. Ces données sont publiquement disponibles via l'API CrUX ou Google BigQuery. Le FCP peut aussi être mesuré via des tests dits de laboratoire. Le test de laboratoire le plus courant s'appelle Lighthouse.

Obtenir le First Contentful Paint du jeu de données CrUX

Le First Contentful Paint peut être lu depuis le jeu de données CrUX via pagespeed.web.dev, l'API CrUX ou via Google BigQuery.

Mesurer le First Contentful Paint avec le Real User Monitoring (RUM)

Le RUM Tracking signifie Real User Monitoring. Avec le Real User Monitoring, vous pouvez suivre le First Contentful Paint à travers les interactions d'utilisateurs réels. L'avantage du RUM Tracking est que vous n'avez pas à attendre 28 jours pour des données fraîches et les données peuvent être interrogées et analysées avec beaucoup plus de détails.

Mesurer le FCP dans Lighthouse

1. Ouvrez la page (dans Chrome) dont vous souhaitez mesurer le FCP. Assurez-vous de le faire en navigation privée pour que les extensions n'interfèrent pas et ne ralentissent pas le FCP de votre page.
2. Faites un clic droit sur la page et sélectionnez Inspecter l'élément. De cette façon, vous ouvrez la console de développement Chrome.
3. En haut de la console, vous verrez l'onglet Lighthouse. Cliquez dessus. Puis sous Catégories, choisissez Performance (laissez les autres vides) et choisissez Mobile sous Appareil.
4. Maintenant cliquez sur Générer le rapport. Lighthouse créera un rapport de vitesse de votre page. En haut à gauche du rapport, vous verrez quel est le FCP de votre page.

Ceci est une capture d'écran du rapport Lighthouse pour cette page. Le FCP de cette page sur un appareil mobile est de 0,8 seconde ! Pas mal, non ?

Mesurer le FCP avec un outil en ligne

Vous pouvez aussi mesurer le FCP avec plusieurs outils en ligne. Les plus connus sont GTMetrix, pingdom et pagespeed.web.dev. Ces outils sont faciles à utiliser et vous donneront des données sur le FCP dans des conditions de laboratoire spécifiques.

Ce que montrent les données FCP du monde réel

Les données CoreDash montrent que le FCP suit de près le TTFB : le FCP p75 est de 392 ms globalement, avec 372 ms sur desktop et 692 ms sur mobile (1,9x plus lent). Le delta FCP/TTFB n'est que de 248 ms sur desktop et 376 ms sur mobile, indiquant que le temps de blocage du rendu représente une part relativement faible du FCP sur un site bien optimisé.

À l'échelle mondiale, selon le 2025 Web Almanac, 70 % des pages desktop atteignent un bon FCP, tandis que seulement 55 % des pages mobiles y parviennent. Les deux se sont améliorés par rapport à 2024, le mobile gagnant 4 points de pourcentage, suggérant que les développeurs web s'attaquent de plus en plus aux ressources bloquant le rendu.

La forte corrélation entre FCP et TTFB signifie qu'améliorer votre Time to First Byte est souvent le moyen le plus efficace d'améliorer votre First Contentful Paint. Sur ce site, le FCP n'est qu'environ 250 ms au-dessus du TTFB, ce qui signifie que la majeure partie du temps FCP est passée à attendre la réponse du serveur plutôt qu'au travail de blocage du rendu.

Améliorer le First Contentful Paint

Il est temps de rendre le FCP plus rapide. L'idée derrière un FCP rapide est en fait assez simple : s'assurer qu'un navigateur peut commencer le rendu immédiatement. Tout ce qui peut retarder le rendu entraînera un mauvais score FCP.

Tout comme le Largest Contentful Paint, le First Contentful Paint peut être décomposé en 2 ou 4 catégories :

1. Time to First Byte (TTFB) : Le temps entre le moment où le navigateur commence à charger la page et celui où il reçoit le premier octet du HTML.
2. Resource load delay : Le temps entre le TTFB et le moment où le navigateur commence à charger la ressource FCP.
3. Resource load time : Le temps nécessaire pour charger la ressource FCP elle-même.
4. Element render delay : Le temps entre la fin du chargement de la ressource FCP et le rendu complet de l'élément FCP.

Astuce vitesse : Vous pouvez facilement éliminer les étapes 2 et 3 en vous assurant que l'élément FCP ne nécessite pas de ressource réseau. Dans le cas d'un élément textuel, envisagez d'utiliser font-display:swap. Dans le cas d'un petit élément image, envisagez de placer l'image en inline.

Il ne nous reste donc plus qu'à optimiser le Time to First Byte et le Element Render delay.

Ci-dessous, 14 solutions que j'utilise souvent pour améliorer le FCP. Mais attention, utiliser une solution au mauvais endroit peut en fait créer des retards. C'est pourquoi il est préférable de consulter un expert en vitesse de page avant de commencer vous-même.

1. Réponse serveur rapide (TTFB)

Le TTFB (le temps entre la requête et le premier octet envoyé par le serveur) est toujours la première étape du processus de rendu. À partir de ce point, votre navigateur commence le multitâche, et l'impact des optimisations suivantes commence à diminuer. Le code HTML est la seule requête qui affecte directement toutes les métriques de vitesse.

La vitesse à laquelle le code HTML est envoyé depuis le serveur est souvent mesurée comme le Time to First Byte (TTFB). Il est important de le rendre aussi rapide que possible. Souvent, vous faites cela en activant le cache côté serveur.

En ce qui concerne le Time to First Byte, plus bas c'est, mieux c'est.

Vous pouvez facilement mesurer le Time to First Byte vous-même. Voici comment procéder :

1. Utilisez le raccourci Ctrl-Shift-I pour ouvrir la console de développement de Google Chrome.
2. En haut de la console, vous verrez un onglet Network. Cliquez dessus.
3. Rechargez la page avec Ctrl-R.
4. Vous verrez maintenant toutes les requêtes réseau que Chrome a envoyées à votre serveur.
5. Cliquez sur la première requête réseau, qui est la requête pour votre page elle-même.
6. Vous obtiendrez alors plus d'informations sur cette requête réseau. Cliquez sur l'onglet timing en haut de ces informations pour voir quel est le TTFB de votre page.

2. HTTP/3

HTTP/3 est la troisième version du protocole HTTP. HTTP/3 résout de nombreux problèmes trouvés dans les anciens protocoles HTTP/1.1 et HTTP/2. Par exemple, depuis HTTP/2, vous pouvez envoyer plusieurs fichiers en même temps via la même connexion. HTTP/3 fournit une connexion initiale plus rapide et moins de problèmes liés aux interruptions réseau mineures.

Sans entrer dans trop de détails, HTTP/3 permet un gain de vitesse significatif, surtout sur un réseau plus lent comme un réseau mobile. Votre administrateur réseau peut vous dire si votre serveur web est déjà compatible avec le protocole HTTP/3 plus rapide.

Vous pouvez vérifier vous-même si votre site web utilise déjà le protocole HTTP/3 plus rapide. Utilisez le raccourci Ctrl-Shift-I pour ouvrir l'inspecteur réseau de Google Chrome. Faites un clic droit sur l'en-tête du tableau et sélectionnez Protocol. Maintenant rechargez la page pour voir quel protocole votre site utilise.

3. 103 Early Hints

103 Early Hints est un code de statut HTTP relativement nouveau qui permet à un serveur d'envoyer des en-têtes de réponse préliminaires avant que la réponse finale ne soit prête. C'est particulièrement utile quand votre serveur a besoin de temps pour générer le HTML (par exemple, interroger une base de données ou exécuter de la logique côté serveur). Au lieu de faire attendre le navigateur passivement, le serveur envoie une réponse 103 avec des hints preload et preconnect pour que le navigateur puisse commencer à récupérer les ressources critiques immédiatement.

Cela améliore directement le FCP car le navigateur peut commencer à télécharger les polices, les feuilles de style et d'autres ressources critiques pour le rendu avant même que le HTML n'arrive. L'impact est le plus significatif sur les pages avec un TTFB élevé.

HTTP/1.1 103 Early Hints
Link: </static/font/outfit.woff2>; rel=preload; as=font; type=font/woff2; crossorigin
Link: </static/css/critical.css>; rel=preload; as=style

HTTP/1.1 200 OK
Content-Type: text/html
...

Tous les hébergeurs ne prennent pas encore en charge les 103 Early Hints. Cloudflare a un support intégré pour les Early Hints, et Apache et Nginx peuvent être configurés pour les envoyer. En savoir plus dans notre guide complet des 103 Early Hints.

4. Cache navigateur

La connexion réseau est souvent le maillon faible en matière de vitesse de page. Ne serait-ce pas tellement plus simple de contourner complètement le réseau ?

Quand un visiteur est déjà venu sur votre site, vous pouvez indiquer si et pendant combien de temps les ressources réseau (par exemple une feuille de style) peuvent être stockées par le navigateur du visiteur. Chaque fois que le visiteur a à nouveau besoin d'un de ces fichiers, ils apparaissent instantanément depuis le cache du navigateur. En conséquence, le navigateur peut commencer le rendu beaucoup plus rapidement et accélérer le FCP.

5. Compression

La vitesse du réseau est dans presque tous les cas un maillon faible. Pour un bon First Contentful Paint, il est tellement important que les fichiers soient envoyés à travers le réseau aussi vite que possible. La compression réduit le nombre d'octets qui doivent être envoyés depuis le serveur ; moins d'octets signifie moins de temps d'attente pour une ressource réseau. La compression, à mon avis, est une technique qui ne reçoit pas l'attention qu'elle mérite. Malheureusement, trop de webmasters « activent la compression » puis n'y jettent plus un œil. Et c'est dommage car c'est juste un moyen facile de rendre les choses un peu plus rapides.

Il existe deux techniques de compression populaires : Gzip et Brotli. Gzip est la technique de compression la plus utilisée mais Brotli rattrape rapidement son retard. Brotli a été créé par Google lui-même et obtient des résultats 15 à 20 % meilleurs pour les fichiers HTML, JavaScript ou CSS. Brotli est donc idéal pour le web.

Il y a aussi une différence entre la compression dynamique et la compression statique. Avec la compression dynamique, vous compressez le fichier juste avant de l'envoyer via votre serveur web ; avec la compression statique, le fichier compressé est stocké sur le serveur. C'est souvent un moyen bien plus intelligent de compresser, mais il est rarement utilisé.

6. Polices web anticipées avec les resource hints

Les resource hints initient un téléchargement ou une connexion réseau avant que le navigateur ne le fasse de lui-même. Certaines ressources réseau, comme les polices web ou les images, ne sont téléchargées qu'après que le navigateur soit sûr qu'il doit les afficher.

Si vous êtes sûr d'avoir besoin d'une ressource pour afficher la partie visible du site, c'est presque toujours une bonne idée d'inclure un « resource hint ». Cela garantira que le navigateur commence à télécharger ou à se connecter à la ressource immédiatement. En conséquence, la ressource est disponible plus tôt et le navigateur peut commencer le rendu plus rapidement.

Mais attention avec les resource hints. Si vous les utilisez incorrectement, ils peuvent en fait ralentir votre page.

Téléchargement anticipé avec le « preloading »

<link rel="preload" href="/static/font/opensans600.woff2" as="font" type="font/woff2" crossorigin>

Le lien preload est l'un des outils les plus puissants de l'arsenal de vitesse de page. Grâce au lien preload, vous téléchargez une ressource réseau dont vous aurez besoin plus tard. C'est souvent une très bonne idée avec les polices, les scripts critiques et les images dans la partie visible du site.

Se connecter à l'avance avec preconnect

Le lien preconnect se connecte déjà à un serveur. C'est utile quand vous hébergez des fichiers sur un serveur tiers comme un CDN ou Google Analytics.

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

Encore mieux que de se préconnecter à Google Fonts : auto-héberger vos Google Fonts. Cela élimine entièrement la connexion tierce et vous donne un contrôle total sur le cache et la livraison.

7. Précharger la page suivante avec prefetch

<link rel="prefetch" href="/page2.html">

Avec prefetch, vous pouvez récupérer des ressources à basse priorité. C'est un moyen utile de récupérer des ressources dont vous pensez avoir besoin plus tard, par exemple quand vous vous attendez à ce que quelqu'un clique sur le lien de la page suivante.

8. Éviter les redirections

Une erreur courante est d'avoir une chaîne de redirections trop longue. Laissez-moi vous expliquer : votre site fonctionne probablement via une connexion sécurisée. Quand un visiteur tape l'adresse de votre site sans ajouter https, le visiteur sera redirigé vers la version non sécurisée de votre site web. Cependant, si tout est bien configuré, le visiteur sera redirigé vers le site sécurisé. Vous pouvez voir cela dans l'exemple vert ci-dessous.

Mais parfois la redirection passe par une ou plusieurs étapes intermédiaires, comme montré dans l'exemple rouge. Ce sont ces étapes intermédiaires qui ralentissent le site, entraînant un mauvais score First Contentful Paint. Chaque étape intermédiaire coûte du temps supplémentaire, qui peut s'accumuler rapidement. Donc, assurez-vous toujours d'arriver à la bonne page en une seule redirection.

9. Minimiser le CSS

Un fichier CSS externe bloque toujours le rendu. Cela signifie qu'un navigateur ne peut normalement pas commencer à afficher du contenu tant que toutes les feuilles de style n'ont pas été téléchargées et analysées. Il est donc préférable de garder les feuilles de style aussi petites que possible. Ainsi, vous n'avez pas à attendre aussi longtemps pour que la feuille de style soit téléchargée. Pour un guide plus complet, lisez notre article sur comment corriger et supprimer le CSS inutilisé.

Réduire la taille du CSS avec les raccourcis

L'une des façons de réduire la taille du CSS est d'utiliser des raccourcis. Ce sont des lignes uniques qui vous permettent d'écrire les propriétés les plus importantes d'un sélecteur CSS en une seule ligne.

body{
    font-style: normal;
    font-weight: 400;
    font-stretch: normal;
    font-size: 0.94rem;
    line-height: 1.6;
    font-family: "Segoe UI", "Segoe UI", system-ui, -apple-system, sans-serif;
}

Vous pouvez aussi l'écrire ainsi :

body{font: 400 .94rem/1.6 Segoe UI,Segoe UI,system-ui,-apple-system, sans-serif;}

Réduire davantage la taille du CSS

Il est possible de réduire encore plus la taille du CSS en fusionnant les sélecteurs avec une virgule, en supprimant les retours à la ligne et les espaces et en écrivant des codes couleur plus courts.

h1{
  color : #000000;
}
h2{
  color : #000000;
}
h3{
  color : #000000;
}
h4{
  color : #000000;
}
h5{
  color : #000000;
}

Pourrait être raccourci en

h1,h2,h3,h4,h5{color:#000}

10. Critical CSS

Nous pouvons aller plus loin avec le CSS en utilisant le critical CSS. Le critical CSS est indispensable pour un site web rapide et un First Contentful Paint rapide.

Le critical CSS est une collection de tous les sélecteurs (comme body, p, h1, etc.) dont vous avez besoin pour afficher la partie visible de la page. Ne mettez pas ce critical CSS dans une feuille de style séparée ; ajoutez-le plutôt directement dans le <head> de la page. Ainsi, vous n'avez pas à télécharger un nouveau fichier et le navigateur peut commencer le rendu à la vitesse de l'éclair. Cela donne un FCP plus rapide. Le CSS dont vous n'avez pas directement besoin pour la partie visible de la page est chargé après que le premier cycle de rendu est terminé. Pour votre visiteur, la page est déjà terminée ; personne ne remarquera les nouveaux styles encore ajoutés en arrière-plan.

Le critical CSS peut être facilement généré avec notre propre outil de critical CSS. Collez simplement l'URL de votre page web dans l'outil et nous ferons le reste pour vous !

Exemple de Critical CSS inline

<head>
  <style>
    /* Critical CSS: only what is needed for above-the-fold content */
    body{font:400 1rem/1.6 system-ui,sans-serif;margin:0}
    h1{font-size:2rem;margin:.5em 0}
    .hero{padding:2rem;background:#f5f5f5}
  </style>
  <!-- Non-critical CSS loaded asynchronously -->
  <link rel="preload" href="/css/full.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
  <noscript><link rel="stylesheet" href="/css/full.css"></noscript>
</head>

11. Différer le chargement de JavaScript

L'une des raisons les plus courantes d'un First Contentful Paint lent est JavaScript. Selon la façon dont vous utilisez JavaScript, il peut bloquer le rendu de la page. Normalement, JavaScript est téléchargé et exécuté avant que l'arbre de rendu ne soit construit. Sans l'arbre de rendu, un navigateur ne peut rien afficher à l'écran, et cela inclut le FCP. Pour un aperçu complet des techniques de report, lisez 14 méthodes pour différer JavaScript.

Nous pouvons contourner cela en reportant JavaScript. Vous pouvez le faire de trois façons.

JavaScript async

<script async src="async.js"></script>

En ajoutant l'attribut async à une balise script, la construction de la page n'est plus bloquée pendant le téléchargement de JavaScript. L'attribut async indique que le téléchargement et la construction de l'arbre de rendu peuvent se faire en même temps.

Une fois le script exécuté, la page est bloquée. Dans la plupart des cas, grâce à l'attribut async, le navigateur a eu suffisamment de temps pour construire une partie importante de la page, avec le First Contentful Paint déjà affiché.

JavaScript defer

<script defer src="deferred.js"></script>

L'attribut defer fonctionne plus ou moins de la même manière que l'attribut async. En ajoutant l'attribut defer à une balise script, le script peut aussi être téléchargé simultanément à la construction de la page. Après que tous les scripts sont téléchargés, ils sont exécutés dans l'ordre dans lequel ils ont été trouvés dans le code HTML. Cela peut aussi bloquer l'affichage de la page mais dans la plupart des cas, le First Contentful Paint est déjà à l'écran.

12. Ne comptez pas sur les ressources externes

Les ressources externes, comme les polices externes, les images externes, les feuilles de style externes ou les scripts externes, sont un goulot d'étranglement potentiel pour le First Contentful Paint. Puisque vous n'avez aucun contrôle sur le serveur où les fichiers sont hébergés, vous ne savez pas à quelle vitesse ils seront envoyés. De plus, vous ne pouvez pas utiliser la connexion existante vers le serveur web. Une nouvelle connexion vers un nouveau serveur doit être établie, et cela prend du temps.

L'une des ressources externes les plus courantes sur le web est Google Fonts. Auto-héberger vos Google Fonts élimine entièrement une connexion tierce et vous donne un contrôle total sur le cache, la compression et le comportement de font-display.

Ressources externes bloquantes

Pas de ressources externes

13. Utilisez le bon format de police

Les polices méritent une attention particulière en ce qui concerne le First Contentful Paint. Sur environ 99 % des pages que nous examinons, l'élément FCP est une ligne de texte. Quand vous utilisez des polices web externes, vous devez d'abord télécharger ces polices depuis un serveur, ce qui prend bien sûr du temps.

Récemment, les polices web ont reçu plus d'attention et il existe de nouveaux formats de polices plus rapides. Le format de police le plus rapide actuellement est woff2, suivi de woff. Woff2 est supporté par tous les navigateurs modernes.

Vous pouvez spécifier l'ordre préféré de votre police web dans la déclaration CSS font-face. Vous le faites de la manière suivante :

 @font-face {
   font-family: 'myFont';
   font-weight: 400;
   font-style: normal;
   font-display: swap;
   unicode-range: U+000-5FF
   src: local('myFont'),
        url('/fonts/myFont.woff2') format('woff2'),
        url('/fonts/myFont.woff') format('woff');
}

14. Font-display: swap

Lors de l'utilisation de polices web, le comportement par défaut de ces polices est de ne pas afficher le texte sur la page tant que la police n'est pas chargée. Cela se fait généralement directement au détriment du First Contentful Paint. Lisez notre guide complet sur comment garantir que le texte reste visible pendant le chargement des polices web.

Vous pouvez résoudre cela en utilisant la déclaration font-display:swap. Avec cela, vous pouvez choisir d'afficher le texte sur la page quand même, dans une police que le navigateur connaît, pendant que la police web se charge en arrière-plan.

Sans font-display:swap

Avec font-display:swap

font-display: swap vs optional

Il existe deux stratégies font-display courantes pour l'optimisation du FCP :

/* swap: Shows fallback font immediately, swaps when webfont loads */
@font-face {
  font-family: 'MyFont';
  font-display: swap;
  src: url('/fonts/myfont.woff2') format('woff2');
}

/* optional: Shows fallback font, only uses webfont if already cached */
@font-face {
  font-family: 'MyFont';
  font-display: optional;
  src: url('/fonts/myfont.woff2') format('woff2');
}

Utiliser font-display: swap garantit le FCP le plus rapide possible car le texte s'affiche immédiatement dans la police de fallback. Utiliser font-display: optional évite entièrement le flash de texte non stylisé (FOUT) lors de la première visite, mais la police web ne s'affichera que si elle est déjà dans le cache du navigateur. Pour la plupart des sites, swap est le meilleur choix pour le FCP.

15. Minimiser la taille du DOM

Une page web est constituée de HTML. La première chose qu'un navigateur fait est de convertir le HTML en nœuds DOM. C'est une structure arborescente d'éléments HTML qui est ensuite utilisée pour construire l'arbre de rendu. À partir de l'arbre de rendu, un navigateur commence le rendu ; finalement, la page web apparaît à l'écran.

Le nombre de nœuds DOM (éléments HTML) que vous avez et la profondeur de ces nœuds DOM dans l'arborescence déterminent la complexité pour un navigateur de construire votre page. Le CSS et le JavaScript prennent aussi plus de temps à analyser quand vous avez trop de nœuds DOM. Tout cela est, encore une fois, directement au détriment du FCP.

Résolvez cela en :

• Chargez des parties de votre page web en différé
  Pour accélérer l'affichage initial, envisagez de charger des parties de votre site web, comme le pied de page, via AJAX ultérieurement.
• Utilisez content-visibility
  La propriété CSS content-visibility dit à un navigateur de sauter le style, la mise en page et le rendu pendant le rendu. Elle le fait juste avant que l'élément ne devienne visible.
• Divisez les grandes pages en plusieurs pages
  Le nombre de nœuds DOM peut être réduit en divisant les grandes pages en plusieurs pages.
• Implémentez le défilement infini
  Le défilement infini est essentiellement du lazy loading : lors du défilement à travers des éléments répétés comme des images (Pinterest) ou de grands tableaux de données, le défilement infini peut accélérer significativement votre page.
• Évitez les interactions DOM en JavaScript
  Soyez particulièrement prudent avec JavaScript quand vous avez un grand nombre de nœuds DOM sur votre page. Une commande comme querySelectorAll peut alors charger un grand nombre de nœuds DOM, augmentant l'utilisation de la mémoire.
• Évitez les déclarations CSS complexes
  Soyez particulièrement prudent avec les commandes CSS complexes avec un grand nombre de nœuds DOM. Par exemple, vérifier le statut last-child pour chaque élément div de votre page peut être coûteux.
• Utilisez les web workers pour épargner le main thread de votre navigateur
  Les web workers sont du JavaScript qui peut s'exécuter en parallèle avec votre page web. Vous pouvez donner à ces web workers des commandes qui sont exécutées en arrière-plan. Quand le web worker a exécuté la commande, il la transmet à la page originale. L'avantage de cela est que vous pouvez toujours exécuter du JavaScript complexe sans que la page ne se fige.

Guides d'optimisation connexes

Améliorer le FCP nécessite de travailler sur plusieurs domaines. Voici nos guides les plus pertinents :

• Auto-héberger Google Fonts : Éliminez une connexion tierce et gagnez un contrôle total sur la livraison des polices.
• Garantir que le texte reste visible pendant le chargement des polices web : Utilisez font-display pour garantir un rendu rapide du texte.
• 14 méthodes pour différer JavaScript : Toutes les techniques pour empêcher JavaScript de bloquer votre FCP.
• Corriger et supprimer le CSS inutilisé : Réduisez le CSS bloquant le rendu au minimum.
• 103 Early Hints : Laissez le navigateur commencer à récupérer les ressources avant l'arrivée du HTML.
• Guide du Largest Contentful Paint (LCP) : Le FCP et le LCP partagent de nombreuses stratégies d'optimisation. Si votre FCP est lent, votre LCP le sera aussi.
• Guide du Time to First Byte (TTFB) : Le TTFB est le plus grand contributeur au FCP. Commencez ici si votre réponse serveur est lente.