Qu’est-ce que le Largest Contentful Paint (LCP) et comment l’améliorer ?

La première impression que les utilisateurs ont de votre site, c’est sa vitesse de chargement perçue.

Le plus grand élément est en général une image mise en avant ou la balise <h1>. Mais il peut aussi s’agir de l’un des éléments suivants :

• Un élément <img>
• Un élément <image> à l’intérieur d’un élément <svg>
• Une image à l’intérieur d’un élément <video>
• Une image d’arrière-plan chargée via la fonction url()
• Des blocs de texte
• La première frame affichée pour un élément <video> en lecture automatique
• La première frame d’un format d’image animée, comme un GIF animé

Tout ce qui se trouve en dehors de la fenêtre d’affichage, ou qui dépasse de son conteneur, n’est pas pris en compte dans le calcul de la taille. Si une image occupe l’intégralité de la fenêtre d’affichage, elle n’est pas considérée pour le LCP.

Voyons ce qu’est un bon score LCP et comment l’améliorer.

Un bon score LCP, mesuré à partir des données du Chrome User Experience Report (CrUX), est inférieur à 2,5 secondes. Il s’agit de données provenant de véritables utilisateurs de Chrome ayant accepté de les partager lorsqu’ils visitent votre site. Il faut que 75 % des visites de page se chargent en 2,5 secondes ou moins.

Votre page peut être classée dans l’une des catégories suivantes :

• Bon : <= 2,5s
• À améliorer : > 2,5s et <= 4s
• Médiocre : > 4s

Données sur le LCP

57,1 % des sites se situent dans la catégorie « bon » pour le LCP en avril 2023. Cette moyenne porte sur l’ensemble du site : pour qualifier un site, le seuil doit être tenu sur 75 % des visites de page.

Le LCP est le Core Web Vital que les éditeurs ont le plus de mal à améliorer.

Lorsque nous avons mené une étude sur les Core Web Vitals, nous avons constaté que les pages obtiennent moins souvent de bonnes valeurs de LCP sur mobile que sur ordinateur.

Le seuil LCP semble quasiment impossible à atteindre sur les connexions lentes.

Il existe deux façons de mesurer le LCP à examiner : les données de terrain (field data) et les données de laboratoire (lab data).

Les données de terrain proviennent du Chrome User Experience Report (CrUX), c’est-à-dire de véritables utilisateurs de Chrome ayant choisi de partager leurs données. Elles donnent la meilleure idée des performances réelles du LCP dans différentes conditions de réseau, sur différents appareils, avec ou sans cache, etc. Ce sont aussi les données qui seront effectivement utilisées par Google pour évaluer les Core Web Vitals.

Les données de laboratoire reposent sur des tests réalisés dans des conditions identiques afin d’être reproductibles. Google ne les utilise pas pour les Core Web Vitals, mais elles sont utiles pour vos tests : les données CrUX (de terrain) correspondent à une moyenne glissante sur 28 jours, il faut donc patienter avant de voir l’impact de vos modifications.

Le meilleur outil pour mesurer le LCP dépend du type de données souhaité (laboratoire ou terrain) et du nombre d’URL à analyser.

Mesurer le LCP pour une seule URL

PageSpeed Insights récupère des données de terrain au niveau de la page que vous ne pouvez pas interroger directement dans le jeu de données CrUX. L’outil exécute également des tests en laboratoire basés sur Google Lighthouse et fournit des données d’origine afin de comparer les performances d’une page à celles de l’ensemble du site.

Mesurer le LCP pour plusieurs URL ou un site entier

Vous pouvez obtenir les données CrUX dans Google Search Console, classées dans les catégories bon, à améliorer et médiocre.

En cliquant sur l’un des problèmes, vous obtenez une répartition par groupes de pages affectées. Ces groupes rassemblent des pages ayant des valeurs similaires, vraisemblablement issues d’un même modèle. Une seule modification appliquée au modèle suffira à corriger toutes les pages du groupe.

Si vous souhaitez obtenir à la fois des données de laboratoire et des données de terrain à grande échelle, le seul moyen est de passer par l’API PageSpeed Insights. Vous pouvez vous y connecter facilement avec Site Audit d’Ahrefs et obtenir des rapports détaillés sur vos performances. C’est gratuit pour les sites vérifiés disposant d’un compte Ahrefs Webmaster Tools (AWT).

Notez que les données Core Web Vitals affichées dépendent du user-agent sélectionné pour votre crawl lors de la configuration. Si vous explorez le site en mode mobile, vous obtiendrez les valeurs CWV mobiles renvoyées par l’API.

Outil gratuit : vérifiez les CWV et Lighthouse jusqu’à 10 pages

Voici un autre outil gratuit qui vous permet d’analyser jusqu’à 10 pages ou sites simultanément pour vous comparer à vos concurrents.

Configuration :

• Saisissez votre clé d’API Google PageSpeed Insights dans le champ prévu à cet effet. (Voici comment générer une clé d’API.)
• Ajoutez les URL à analyser (une par ligne).

Lancement de l’analyse :

• Cliquez sur le bouton « Check CWV » pour démarrer la récupération des indicateurs. Une barre de progression affichera l’état des requêtes.

Consultation des résultats :

Les résultats sont présentés sous forme de cartes de score classées par catégorie :

• CWV Desktop pour la page
• CWV Desktop pour l’origine
• Lighthouse Desktop
• CWV Mobile pour la page
• CWV Mobile pour l’origine
• Lighthouse Mobile

Chaque indicateur est associé à un code couleur reflétant la performance :

• Vert : Bon
• Jaune : À améliorer
• Rouge : Médiocre

Voici un aperçu des cartes de score. L’outil peut aussi être utilisé de manière autonome comme test de vitesse de site web (en anglais).

Dans PageSpeed Insights, l’élément LCP est identifié dans la section « Diagnostics ». Notez également la présence d’un onglet permettant de sélectionner uniquement les problèmes liés au LCP. Ce sont ceux remontés par le test en laboratoire qu’il faudra résoudre.

Les problèmes liés au LCP sont nombreux, ce qui en fait l’indicateur le plus difficile à améliorer.

La théorie générale paraît assez simple : afficher le plus grand élément plus rapidement. Mais en pratique, cela peut devenir complexe. Certains fichiers exigent que d’autres soient chargés au préalable, et il peut exister des priorités contradictoires dans le navigateur. Vous risquez de corriger toute une série de problèmes sans constater la moindre amélioration, ce qui peut être frustrant.

Si vous n’êtes pas très technique et que vous ne souhaitez pas engager quelqu’un, cherchez des plugins, modules ou packages d’optimisation des performances ou de la vitesse de page adaptés à votre système. Les informations ci-dessous vous serviront de guide pour identifier les fonctionnalités dont vous aurez besoin.

Voici plusieurs façons d’améliorer le LCP :

1. Identifiez votre élément LCP

Dans PageSpeed Insights, vous pouvez cliquer sur « Largest Contentful Paint element » dans la section « Diagnostics » : l’outil identifiera votre élément LCP.

2. Priorisez le chargement des ressources

Pour valider le test LCP, vous devez hiérarchiser le chargement de vos ressources dans le chemin de rendu critique. Concrètement, il s’agit d’indiquer au navigateur quelles ressources télécharger en priorité, et lesquelles peuvent attendre, en utilisant des attributs HTML détaillés plus bas (fetchpriority, preload, defer, async).

Vous devez d’abord charger les ressources nécessaires à votre élément LCP, ainsi que toutes les autres ressources requises pour le contenu situé au-dessus de la ligne de flottaison. Une fois les éléments initialement visibles chargés pour les utilisateurs, le reste est chargé ensuite.

De nombreux sites peuvent valider le seuil LCP simplement en ajoutant quelques Early Hints ou directives de preload pour des éléments comme l’image principale, ainsi que les feuilles de style et polices indispensables. Examinons comment optimiser les différents types de ressources.

Images en priorité

Si vous n’avez pas besoin de l’image, la solution la plus efficace consiste simplement à la supprimer. Si l’image est indispensable, mieux vaut en optimiser la taille et la qualité pour qu’elle reste la plus légère possible. L’objectif est de rester sous les 200 ko, voire sous 100 ko sur mobile. Les formats modernes comme WebP ou AVIF compriment 30 à 50 % mieux que JPEG ou PNG.

Vous pouvez aussi utiliser les Early Hints. L’attribut fetchpriority="high" peut être appliqué aux balises <img> ou <link> et indique au navigateur de récupérer l’image en priorité. Elle s’affichera ainsi un peu plus tôt.

Les Early Hints ne fonctionnent pas sur tous les navigateurs, vous pouvez donc également précharger l’image avec un preload. Cela lance le téléchargement de l’image un peu plus tôt, mais pas aussi tôt qu’avec fetchpriority="high".

Une directive de preload pour une image responsive ressemble à ceci :

<link rel="preload" as="image" href="cat.jpg" imagesrcset="cat_400px.jpg 400w, cat_800px.jpg 800w, cat_1600px.jpg 1600w" imagesizes="50vw">

Vous pouvez même combiner fetchpriority="high" et preload !

Images en différé

Vous devez charger en différé toutes les images qui ne sont pas nécessaires immédiatement. Cela permet de charger les images plus tard dans le processus, ou au moment où l’utilisateur est sur le point de les voir. Ajoutez la balise loading="lazy" à chaque image de cette façon :

<img src="cat.jpg" alt="cat" loading="lazy">

Ne chargez jamais en différé les images situées au-dessus de la ligne de flottaison !

Un CSS simplifié

Le CSS doit être minifié, c’est-à-dire allégé en supprimant espaces, commentaires et caractères inutiles. Si possible, supprimez également le CSS inutilisé. C’est un conseil encore plus important maintenant qu’on a tendance à vibe coder des sites : les IA ajoutent beaucoup de HTML et CSS inutiles.

L’autre point majeur est d’inliner le CSS critique. Le principe : vous prenez la partie du CSS nécessaire à l’affichage du contenu visible immédiatement par l’utilisateur, et vous l’intégrez directement dans le HTML. Lorsque le HTML est téléchargé, tout le CSS requis pour afficher ce que voient les utilisateurs est déjà disponible.

CSS en différé

Pour tout CSS supplémentaire qui n’est pas critique, il faudra l’appliquer plus tard dans le processus. Vous pouvez lancer le téléchargement du CSS avec une directive de preload, mais ne l’appliquer que plus tard via un événement onload. Cela donne :

<link rel="preload" href="stylesheet.css" as="style" onload="this.rel='stylesheet'">

Optimiser les polices

Voici plusieurs options :

Niveau 1 : préchargez vos polices. C’est encore mieux si vous utilisez le même serveur pour éviter une connexion supplémentaire.

Niveau 2 : font-display: optional. Cette propriété peut être combinée avec une directive de preload. Elle accorde à votre police une courte fenêtre temporelle pour se charger. Si la police n’arrive pas à temps, le chargement initial affichera simplement une police par défaut. Votre police personnalisée sera ensuite mise en cache et apparaîtra lors des chargements suivants.

Niveau 3 : utilisez simplement une police système. Il n’y a rien à charger, donc aucun délai. C’est la meilleure solution.

JavaScript en priorité

Nous avons déjà évoqué la suppression du JavaScript inutilisé et la minification du reste. Si vous utilisez un framework JavaScript, vous pouvez envisager le pre-rendering ou le rendu côté serveur (SSR) de la page.

Vous pouvez également inliner le JavaScript nécessaire en début de chargement. Le principe est le même que pour le CSS : vous déplacez certaines parties de vos fichiers JavaScript pour les charger directement avec le HTML.

Autre option : précharger les fichiers JavaScript pour les obtenir plus tôt. Ne le faites que pour les ressources nécessaires au chargement du contenu au-dessus de la ligne de flottaison, ou si certaines fonctionnalités dépendent de ce JavaScript.

JavaScript en différé

Tout JavaScript dont vous n’avez pas besoin immédiatement doit être chargé plus tard. Il existe deux principales méthodes pour cela : les attributs defer et async. Ces attributs peuvent être ajoutés à vos balises <script>.

Habituellement, un script bloque le parseur pendant son téléchargement et son exécution. async permet au parsing et au téléchargement de se dérouler simultanément, mais bloque tout de même le parsing pendant l’exécution du script. defer ne bloque pas le parsing pendant le téléchargement, et le script n’est exécuté qu’une fois le parsing du HTML terminé.

Lequel choisir ? Pour tout ce que vous voulez charger plus tôt ou qui comporte des dépendances, j’aurais tendance à privilégier async.

Par exemple, j’utilise généralement async pour les balises analytics afin de comptabiliser davantage d’utilisateurs. Privilégiez defer pour tout ce qui n’est pas nécessaire immédiatement ou qui n’a pas de dépendances. Ces attributs sont très simples à ajouter.

Voici quelques exemples :

Standard :

<script src="https://www.domain.com/file.js"></script>

Async :

<script src="https://www.domain.com/file.js" async></script>

Defer :

<script src="https://www.domain.com/file.js" defer></script>

3. Réduisez la taille des fichiers

Si vous pouvez supprimer des fichiers ou en réduire la taille, votre page se chargera plus rapidement. Une bonne cible : viser un poids total inférieur à 1,5 Mo, et idéalement sous 1 Mo sur mobile. Cela signifie qu’il faudra supprimer les fichiers inutilisés ou les portions de code qui ne servent pas.

La façon de procéder dépend largement de votre configuration, mais le processus de suppression des parties inutiles d’un fichier est généralement appelé tree shaking.

Il est couramment réalisé via un processus automatisé avec Webpack ou Grunt, dans le cadre des frameworks JavaScript, voire parfois avec des systèmes comme WordPress, mais la plupart des CMS courants ne le prennent pas en charge.

Vous pouvez ignorer cette étape ou vérifier si des plugins offrent cette option pour votre système.

Pour réduire la taille des fichiers, vous voulez en général les compresser.

Pratiquement tous les types de fichiers utilisés pour construire votre site peuvent être compressés : CSS, JavaScript, images et HTML. Et la quasi-totalité des systèmes et serveurs prennent en charge la compression.

Elle s’effectue généralement au niveau du serveur ou du CDN, mais certains plugins l’assurent également, comme WP Rocket pour WordPress.

4. Utilisez un CDN

L’information met du temps à voyager. Plus vous êtes éloigné d’un serveur, plus le transfert des données est long. À moins de cibler une zone géographique restreinte, il est judicieux de mettre en place un Content Delivery Network (CDN).

Les CDN permettent de connecter et de servir votre site depuis un point plus proche des utilisateurs. C’est comme si vous disposiez de copies de votre serveur réparties à travers le monde.

5. Hébergez vos ressources sur le même serveur

Lorsque vous vous connectez à un serveur pour la première fois, il y a un processus qui parcourt le web et établit une connexion sécurisée entre vous et ce serveur.

Cela prend un certain temps, et chaque nouvelle connexion ajoute un délai supplémentaire, car il faut repasser par le même processus. En hébergeant vos ressources sur le même serveur, vous éliminez ces délais supplémentaires.

Si vous ne pouvez pas utiliser le même serveur, vous pouvez recourir à preconnect ou dns-prefetch pour initier les connexions plus tôt. Un navigateur attend normalement la fin du téléchargement du HTML avant d’amorcer une connexion. Avec preconnect ou dns-prefetch, elle démarre plus tôt qu’à l’accoutumée. Notez que dns-prefetch bénéficie d’un meilleur support que preconnect.

Pour chaque ressource que vous souhaitez obtenir plus tôt, vous ajoutez une nouvelle directive comme celle-ci :

<link rel="preconnect" href="https://fonts.googleapis.com/"> <link rel="dns-prefetch" href="https://fonts.googleapis.com/" />

6. Utilisez le cache

Lorsque vous mettez vos ressources en cache, elles sont téléchargées lors de la première vue de page, mais n’ont plus besoin de l’être pour les vues suivantes. Les ressources étant déjà disponibles, les chargements de page ultérieurs sont nettement plus rapides.

Regardez le peu de fichiers téléchargés lors du second chargement dans les graphiques en cascade ci-dessous.

Premier chargement de la page :

Second chargement de la page :

Si vous le pouvez, mettez également en cache au niveau du CDN. La durée de cache doit être aussi longue que vous l’acceptez.

L’idéal est de mettre en cache sur une très longue période, mais de purger le cache à chaque modification apportée à une page.

7. Divers

D’autres technologies peuvent contribuer à améliorer les performances. Parmi elles : le Speculative Prerendering, les Signed Exchanges et HTTP/3.

Conclusion

Existe-t-il une meilleure métrique pour mesurer le chargement visuel ? Je ne vois rien de nouveau à l’horizon pour le moment. Nous avons déjà assisté à plusieurs évolutions visant à mesurer le chargement.

load et DOMContentLoaded ne reflètent pas vraiment ce que voit l’utilisateur. Le First Contentful Paint (FCP) marque le début de l’expérience de chargement. Le First Meaningful Paint (FMP) et le Speed Index (SI) sont complexes et n’identifient pas réellement le moment où le contenu principal a été chargé.

Si vous avez des questions, contactez-nous sur LinkedIn pour les francophones.