First Contentful Paint

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

Le First Contentful Paint (FCP) est un moyen de mesurer la vitesse de chargement d'une page. Vous ne pouvez pas résumer la vitesse de page à un instant donné, il y a en fait plusieurs moments au cours du processus de chargement où un visiteur peut ressentir 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 rendu à 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 elle dit quelque chose sur la vitesse de chargement qu'un visiteur expérimente. Elle dit quelque chose sur l'expérience utilisateur (UX). 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 (Premier), bien sûr, nous entendons le tout premier moment exact où quelque chose de substantiel apparaît sur votre navigateur.
2. Contentful : Par Contentful (Ayant du contenu), 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 d'arrière-plan, mais plutôt du texte, une image (y compris une image d'arrière-plan), un SVG ou un canvas.
   
3. Paint : Paint (Peinture/Rendu) signifie (plus ou moins) que le navigateur est prêt à mettre quelque chose à l'écran. Cela semble simple mais c'est en fait la tâche la plus complexe du navigateur. Pour mettre quelque chose à l'écran, un navigateur doit être prêt à calculer toutes les caractéristiques d'un élément. Ci-dessous se trouve un exemple du processus de rendu qui est requis avant que quoi que ce soit puisse être ajouté à l'écran.

Quel est un bon score First Contentful Paint ?

Un bon score FCP est tout ce qui est inférieur à 1,8 seconde. Si votre score FCP se situe entre 1,8 et 3 secondes, il nécessite une amélioration. Tout score FCP supérieur à 3 secondes est considéré comme médiocre. Pour réussir les Core Web Vitals pour le Largest Contentful Paint, au moins 75% de vos visiteurs doivent avoir un 'bon' score FCP.

Comme toujours avec les Core Web Vitals, un score First Contentful Paint plus rapide est meilleur qu'un plus grand. 

Comment mesurez-vous votre First Contentful Paint (FCP) ?

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

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

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

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

RUM Tracking signifie Real User Monitoring. Avec le Real User Monitoring, vous pouvez suivre le First Contentful Paint à travers les interactions réelles des utilisateurs. 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 mode incognito pour que les plugins ne vous dérangent pas et ne ralentissent pas potentiellement 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 développeur Chrome.
3. En haut de la console, vous verrez l'onglet Lighthouse. Cliquez dessus. Ensuite, 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. Dans le coin supérieur 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 également mesurer le FCP avec un certain nombre d'outils en ligne. Les plus connus sont GTMetrix, pingdom et pagespeed.web.dev. Ces outils sont faciles à utiliser et fourniront des données sur le LCP dans des circonstances de laboratoire spécifiques.

Améliorer le First Contentful Paint

Maintenant que vous savez ce qu'est le First Contentful Paint, nous pouvons nous mettre au travail pour le rendre 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 avec 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 début du chargement de la page et le moment où le navigateur reçoit le premier octet du HTML. 
2. Délai de chargement de la ressource - Le temps entre le TTFB et le moment où le navigateur commence à charger la ressource FCP
   
3. Temps de chargement de la ressource - Le temps nécessaire pour charger la ressource FCP elle-même.
   
4. Délai de rendu de l'élément - Le temps entre la fin du chargement de la ressource FCP et le rendu complet de l'élément LCP
   

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

Cela nous laisse juste avec le Time to First Byte et le Délai de rendu de l'élément à optimiser.

Ci-dessous se trouvent 14 solutions que j'utilise souvent pour améliorer le FCP. Mais soyez prudent, utiliser une solution au mauvais endroit peut en fait créer des délais. 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 demande et le premier octet que le serveur envoie) est toujours la première étape du processus de rendu. À partir de ce moment, votre navigateur commence le multitâche, et l'impact des optimisations ultérieures commence à diminuer. Le code HTML est la seule demande 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 rendre cela aussi rapide que possible. Souvent, vous faites cela en activant la mise en cache côté serveur.

En ce qui concerne le time to first byte, plus c'est bas, mieux c'est. 

Vous pouvez facilement mesurer le time to first byte vous-même. Cela se fait comme suit :

1. Utilisez le raccourci Ctrl-Shift-I pour ouvrir la console développeur de Google Chrome.
   
2. En haut de la console, vous verrez un onglet Réseau (Network). Cliquez dessus.
3. Rechargez la page via Ctrl-R.
   
4. Vous verrez maintenant toutes les demandes réseau que Chrome a envoyées à votre serveur.
5. Cliquez sur la demande réseau supérieure, qui est la demande pour votre page elle-même.
6. Maintenant, vous obtiendrez plus d'informations sur cette demande réseau.  Cliquez sur l'onglet timing (minutage) en haut de ces informations pour voir quel est le TTFB pour 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 offre une connexion initiale plus rapide et moins de problèmes dus aux interruptions mineures du réseau.

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

Vous pouvez vérifier par 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 Protocole. Maintenant rechargez la page pour voir quel protocole votre site utilise.

3. Mise en cache du navigateur (Browser Caching)

La connexion réseau est souvent un maillon faible en matière de vitesse de page. Ne serait-il pas tellement plus facile de sauter le réseau complètement ?

Lorsqu'un visiteur a déjà été sur votre site auparavant, vous pouvez indiquer si et 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 besoin de l'un de ces fichiers à nouveau, ils surgissent du cache du navigateur en un rien de temps. En conséquence, le navigateur peut commencer le rendu beaucoup plus rapidement et accélérer le FCP.

4. Compression

La vitesse du réseau est dans presque tous les cas un maillon faible. Pour un bon First Contentful Paint, il est si important que les fichiers soient envoyés via 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 sur 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” et ne la regardent plus ensuite. Et c'est dommage car c'est juste un moyen facile de rendre les choses un tout petit peu plus rapides.

Il y a deux techniques de compression populaires : Gzip et Brotli. Gzip est la technique de compression la plus utilisée mais Brotli la rattrape rapidement. Brotli a été créé par Google lui-même et a des résultats 15 à 20% meilleurs en ce qui concerne 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 une manière beaucoup plus intelligente de compresser, mais c'est rarement utilisé.

5. Polices web précoces (Early web-fonts) avec resource hints

Les resource hints (indices de ressources) 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, telles que les polices web ou les images, ne sont téléchargées qu'après que le navigateur est sûr d'avoir besoin de les afficher.

Si vous êtes sûr d'avoir besoin d'une ressource pour rendre 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 tôt.

Mais soyez prudent avec les resource hints, si vous les utilisez incorrectement, ils peuvent en fait ralentir votre page.

Téléchargement précoce avec "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 dans l'arsenal de la 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 sur la partie visible du site.

Se connecter à l'avance avec preconnect

Le lien preconnect se connecte déjà à un serveur. C'est utile lorsque vous hébergez des fichiers sur un serveur tiers tel qu'un CDN ou Google analytics.

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

6. Précharger la page suivante avec prefetch

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

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

7. Éviter les redirections

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

Mais parfois la redirection a lieu via une ou plusieurs étapes intermédiaires, comme indiqué dans l'exemple rouge. Ce sont ces étapes intermédiaires qui font que le site web fonctionne lentement, entraînant un mauvais score First Contentful Paint. Chaque étape intermédiaire coûte du temps supplémentaire, ce qui peut rapidement s'accumuler. Assurez-vous donc toujours d'arriver à la bonne page en une seule redirection.

8. Minimiser le CSS

Un fichier CSS externe est toujours bloquant pour le rendu (render-blocking). Ce que cela signifie, c'est 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. Par conséquent, il est préférable de garder les feuilles de style aussi petites que possible. De cette façon, vous n'avez pas à attendre aussi longtemps que la feuille de style soit téléchargée.

Réduire la taille du CSS avec des shortcodes

Une des façons de réduire la taille du CSS est d'utiliser des shortcodes. 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 comme :

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

Réduire encore la taille du CSS

Il est possible de réduire la taille du CSS encore plus 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 comme

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

9. CSS Critique (Critical CSS)

Nous pouvons pousser le CSS une étape plus loin en utilisant le critical CSS. Le critical CSS est un incontournable 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 montrer 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. De cette façon, vous n'avez pas à télécharger un nouveau fichier et le navigateur peut commencer le rendu à la vitesse de l'éclair. Cela permet 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à finie – 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 génération de critical CSS. Collez simplement l'URL de votre page web dans l'outil et nous ferons le reste pour vous !

10. Différer le chargement du JavaScript

L'une des raisons les plus courantes pour un First Contentful Paint lent est le 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 mettre à l'écran – cela inclut le FCP.

Nous pouvons contourner cela en reportant le JavaScript. Vous pouvez le faire de trois manières

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 que le JavaScript est téléchargé. L'attribut async indique que le téléchargement et la construction de l'arbre de rendu peuvent se produire 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 assez de temps pour construire une partie importante de la page, avec le First Contentful Paint déjà sur la page.

JavaScript Defer

<script defer src="async.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 également être téléchargé simultanément à la construction de la page. Une fois que tous les scripts sont téléchargés, ils sont exécutés dans l'ordre où ils ont été trouvés dans le code HTML. Cela peut aussi bloquer l'affichage de la page mais dans de nombreux cas le First Contentful Paint est déjà à l'écran.

11. Ne comptez pas sur des ressources externes

Les ressources externes, telles que les polices externes, les images externes, les feuilles de style externes ou les scripts externes, sont un goulot d'étranglement potentiel en ce qui concerne 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 au serveur web. Une nouvelle connexion à un nouveau serveur doit être établie – et cela prend du temps.

Ressources externes bloquantes

Pas de ressources externes

12. 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 regardons, l'élément FCP est une ligne de texte. Lorsque vous utilisez des polices web externes, vous devez d'abord télécharger ces polices depuis un serveur, ce qui – bien sûr – prend du temps. 

Récemment, les polices web ont reçu plus d'attention, et il existe de nouveaux formats de police plus rapides. Le format de police le plus rapide en ce moment est woff2, suivi par woff. Woff2 est pris en charge 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 faites cela comme suit :

 @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');
}

13. 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. C'est généralement directement au détriment du First Contentful Paint. 

Vous pouvez résoudre cela en utilisant font-display:swap. Avec cela, vous pouvez choisir d'afficher le texte sur la page de toute façon, dans une police que le navigateur connaît, pendant que la police web est chargée en arrière-plan..

Sans font-display:swap

Avec font-display:swap

Lisez notre article complet  Assurez-vous que le texte reste visible pendant le chargement de la police web

14. Minimiser la taille du DOM

Une page web se compose 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 utilisée plus tard 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 la structure arborescente déterminent la complexité pour un navigateur de construire votre page. CSS et JavaScript prennent également plus de temps à analyser lorsque vous avez trop de nœuds DOM. Cela, encore une fois, est tout directement au détriment du FCP.

Résolvez cela en :

• Chargement différé (Lazy load) de parties de votre page web
  Pour accélérer l'affichage initial, envisagez de charger des parties de votre site web, comme le pied de page, via AJAX à un moment ultérieur.
• Utiliser content-visibility
  La propriété CSS content-visibility indique à un navigateur de sauter le style, la mise en page et la peinture (paint) pendant le rendu. Elle le fait juste avant que l'élément ne devienne visible.
•  Diviser 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émenter le défilement infini (infinite scroll)
  Le défilement infini est essentiellement un chargement différé : lors du défilement à travers des éléments répétés tels que des images (pinterest) ou de grandes tables de données, le défilement infini peut considérablement accélérer votre page.
• Éviter l'interaction JavaScript DOM
  Soyez très prudent avec JavaScript lorsque vous avez un grand nombre de nœuds DOM sur votre page. Une commande comme peut alors charger un grand nombre de nœuds DOM, augmentant l'utilisation de la mémoire.
• Éviter les déclarations CSS compliquées
  Soyez très prudent avec les commandes CSS compliquées avec un grand nombre de nœuds DOM. Par exemple, vous devriez vérifier le statut last-child pour chaque élément div sur votre page.
• Utiliser des web workers pour épargner le thread principal 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. Lorsque le web worker a exécuté la commande, il la transmet à la page d'origine. L'avantage de cela est que vous pouvez toujours exécuter du JavaScript complexe sans que la page ne se fige.