Largest Contentful Paint (LCP) est une mesure de l'expérience utilisateur de Google intégrée aux systèmes de classement en 2021.
LCP est l'une des trois mesures Core Web Vitals (CWV) qui suivent les mesures de performances techniques ayant un impact sur l'expérience utilisateur.
Les Core Web Vitals existent de manière paradoxale : Google fournit des conseils soulignant leur importance mais minimisant leur impact sur les classements.
LCP, comme les autres signaux CWV, est utile pour diagnostiquer les problèmes techniques et garantir que votre site Web répond à un niveau de fonctionnalité de base pour les utilisateurs.
Quelle est la plus grande peinture de contenu ?
LCP est une mesure du temps nécessaire au téléchargement du contenu principal d'une page et à son élaboration afin qu'il soit prêt à être utilisé.
Plus précisément, il s'agit du temps nécessaire entre le début du chargement de la page et le rendu de la plus grande image ou du plus grand bloc de texte dans la fenêtre d'affichage de l'utilisateur. Tout ce qui se trouve en dessous de la ligne de flottaison ne compte pas.
Les images, les images d'affiches vidéo, les images d'arrière-plan et les éléments de texte au niveau du bloc comme les balises de paragraphe sont des éléments typiques mesurés.
Le LCP comprend les sous-métriques suivantes :
L'optimisation pour LCP signifie optimiser pour chacune de ces mesures, il faut donc moins de 2,5 secondes pour charger et afficher les ressources LCP.
Voici une échelle de seuil pour votre référence :
Plongeons dans ce que signifient ces sous-métriques et comment vous pouvez vous améliorer.
Temps jusqu'au premier octet (TTFB)
Le TTFB est le temps de réponse du serveur et mesure le temps nécessaire au navigateur de l'utilisateur pour recevoir le premier octet de données de votre serveur. Cela inclut le temps de recherche DNS, le temps nécessaire au traitement des requêtes par le serveur et les redirections.
L'optimisation du TTFB peut réduire considérablement le temps de chargement global et améliorer le LCP.
Le temps de réponse du serveur dépend en grande partie de :
- Requêtes de base de données.
- Manque de cache CDN.
- Rendu côté serveur inefficace.
- Hébergement.
Passons en revue chacun d'eux :
1. Requêtes de base de données
Si votre temps de réponse est élevé, essayez d’identifier la source.
Par exemple, cela peut être dû à des requêtes mal optimisées ou à un volume élevé de requêtes ralentissant le temps de réponse du serveur. Si vous disposez d'une base de données MySQL, vous pouvez enregistrer les requêtes lentes pour identifier celles qui sont lentes.
Si vous avez un site Web WordPress, vous pouvez utiliser le plugin Query Monitor pour voir combien de temps prennent les requêtes SQL.
D'autres excellents outils sont Blackfire ou Newrelic, qui ne dépendent pas du CMS ou de la pile que vous utilisez, mais nécessitent une installation sur votre hébergement/serveur.
2. Échecs du cache CDN
Un échec de cache CDN se produit lorsqu'une ressource demandée n'est pas trouvée dans le cache du CDN et que la demande est transmise pour être récupérée à partir du serveur d'origine. Ce processus prend plus de temps, ce qui entraîne une augmentation de la latence et des temps de chargement plus longs pour l'utilisateur final.
En général, votre fournisseur CDN dispose d'un rapport sur le nombre d'échecs de cache que vous avez.
Si vous observez un pourcentage élevé (> 10 %) d'échecs de cache, vous devrez peut-être contacter votre fournisseur CDN ou le support d'hébergement si vous avez géré un hébergement avec cache intégré pour résoudre le problème.
L'une des raisons qui peuvent entraîner des échecs de cache est lorsque vous subissez une attaque de spam de recherche.
Par exemple, une douzaine de domaines de spam renvoient vers vos pages de recherche internes avec des requêtes de spam aléatoires telles que [/?q=甘肃代]qui ne sont pas mis en cache car le terme de recherche est différent à chaque fois. Le problème est que Googlebot les explore de manière agressive, ce qui peut entraîner des temps de réponse du serveur élevés et des échecs de cache.
Dans ce cas, et de manière générale, il est recommandé de bloquer les URL de recherche ou de facettes via le fichier robots.txt. Mais une fois que vous les bloquez via le fichier robots.txt, vous risquez de constater que ces URL sont indexées car elles contiennent des backlinks provenant de sites Web de mauvaise qualité.
Mais n'ayez pas peur. John Mueller a dit que tout serait réglé à temps.
Voici un exemple réel de la console de recherche d'un temps de réponse élevé du serveur (TTFB) causé par des échecs de cache :
3. Rendu côté serveur inefficace
Certains composants de votre site Web peuvent dépendre d'API tierces.
Par exemple, vous avez vu les chiffres de lecture et de partage sur les articles de SEJ. Nous récupérons ces chiffres à partir de différentes API, mais au lieu de les récupérer lorsqu'une demande est adressée au serveur, nous les pré-récupérons et les stockons dans notre base de données pour un affichage plus rapide.
Imaginez que nous nous connections aux API Share Count et GA4 lorsqu'une requête est adressée au serveur. Chaque requête prend environ 300 à 500 ms pour s'exécuter, et nous ajouterions environ 1 000 ms de retard en raison d'un rendu côté serveur inefficace. Assurez-vous donc que votre backend est optimisé.
4. Hébergement
Sachez que l'hébergement est très important pour les TTFB faibles. En choisissant le bon hébergement, vous pourrez peut-être réduire votre TTFB de deux à trois fois.
Choisissez un hébergement avec CDN et mise en cache intégrés au système. Cela vous évitera d'avoir à acheter un CDN séparément et vous permettra de gagner du temps lors de sa maintenance.
Alors, investir dans le bon hébergement sera rentable.
Lire des conseils plus détaillés :
Examinons maintenant d’autres mesures mentionnées ci-dessus qui contribuent au LCP.
Retard de chargement des ressources
Le délai de chargement des ressources est le temps nécessaire au navigateur pour localiser et commencer à télécharger la ressource LCP.
Par exemple, si vous avez une image d'arrière-plan dans votre section héros qui nécessite le chargement de fichiers CSS pour être identifiée, il y aura un délai égal au temps nécessaire au navigateur pour télécharger le fichier CSS pour commencer à télécharger l'image LCP.
Dans le cas où l'élément LCP est un bloc de texte, ce temps est nul.
En optimisant la rapidité avec laquelle ces ressources sont identifiées et chargées, vous pouvez améliorer le temps nécessaire à l'affichage du contenu critique. Une façon de procéder consiste à précharger les fichiers CSS et les images LCP en définissant fetchpriority=”high” sur l'image afin qu'elle commence à télécharger le fichier CSS.
Mais une meilleure approche – si vous avez suffisamment de contrôle sur le site Web – consiste à intégrer le CSS critique requis pour la partie supérieure de la page, afin que le navigateur ne perde pas de temps à télécharger le fichier CSS. Cela permet d'économiser de la bande passante et de précharger uniquement l'image.
Bien sûr, c'est encore mieux si vous concevez des pages Web pour éviter les images de héros ou les curseurs, car ceux-ci n'ajoutent généralement pas de valeur et les utilisateurs ont tendance à les faire défiler car ils sont distrayants.
Un autre facteur majeur contribuant au retard de chargement est la redirection.
Si vous avez des backlinks externes avec des redirections, vous ne pouvez pas faire grand-chose. Mais vous avez le contrôle sur vos liens internes, alors essayez de trouver des liens internes avec des redirections, généralement en raison de barres obliques manquantes, de versions non WWW ou d'URL modifiées, et remplacez-les par des destinations réelles.
Il existe un certain nombre d'outils techniques de référencement que vous pouvez utiliser pour explorer votre site Web et trouver les redirections à remplacer.
Durée de chargement des ressources
La durée de chargement des ressources fait référence au temps réel passé à télécharger la ressource LCP.
Même si le navigateur trouve et commence rapidement à télécharger des ressources, des vitesses de téléchargement lentes peuvent toujours affecter négativement le LCP. Cela dépend de la taille des ressources, de la vitesse de connexion réseau du serveur et des conditions réseau de l'utilisateur.
Vous pouvez réduire la durée de chargement des ressources en implémentant :
- Format WebP.
- Images correctement dimensionnées (faire correspondre la taille intrinsèque de l'image à la taille visible).
- Priorisation de charge.
- Canada.
Délai de rendu des éléments
Le délai de rendu de l'élément est le temps nécessaire au navigateur pour traiter et restituer l'élément LCP.
Cette métrique est influencée par la complexité de votre HTML, CSS et JavaScript.
La réduction des ressources bloquant le rendu et l'optimisation de votre code peuvent contribuer à réduire ce délai. Cependant, il peut arriver que vous ayez des scripts JavaScript lourds en cours d'exécution, qui bloquent le thread principal, et que le rendu de l'élément LCP soit retardé jusqu'à ce que ces tâches soient terminées.
C'est ici que les faibles valeurs de la métrique Total Blocking Time (TBT) sont importantes, car elles mesurent le temps total pendant lequel le thread principal est bloqué par de longues tâches lors du chargement de la page, indiquant la présence de scripts lourds qui peuvent rendu différé et réactivité.
Une façon d'améliorer non seulement la durée et le délai de chargement, mais également toutes les mesures CWV globales lorsque les utilisateurs naviguent sur votre site Web consiste à implémenter une API de règles de spéculation pour les navigations futures. En pré-affichant les pages lorsque les utilisateurs passent la souris sur les liens ou les pages qu'ils sont susceptibles de parcourir, vous pouvez faire en sorte que vos pages se chargent instantanément.
Attention à ces « pièges » en matière de notation
Tous les éléments de l'écran de l'utilisateur (la fenêtre d'affichage) sont utilisés pour calculer le LCP. Cela signifie que les images rendues hors écran puis déplacées dans la mise en page, une fois rendues, peuvent ne pas être comptabilisées dans le score de Largest Contentful Paint.
À l’opposé, les éléments commençant dans la fenêtre d’affichage de l’utilisateur et ensuite poussés hors de l’écran peuvent être comptabilisés dans le cadre du calcul LCP.
Comment mesurer le score LCP
Il existe deux types d'outils de notation. Le premier s'appelle Outils de terrainet le deuxième s'appelle Outils de laboratoire.
Les outils de terrain sont des mesures réelles d’un site.
Les outils de laboratoire fournissent un score virtuel basé sur une simulation d'exploration à l'aide d'algorithmes qui se rapprochent des conditions Internet qu'un utilisateur de téléphone mobile typique pourrait rencontrer.
Voici une façon de trouver des ressources LCP et de mesurer le temps nécessaire pour les afficher via Outils de développement > Performance rapport:
Vous pouvez en savoir plus dans notre guide détaillé sur la façon de mesurer les métriques CWV, où vous pouvez apprendre à dépanner non seulement LCP mais aussi d'autres métriques dans leur ensemble.
L'optimisation LCP est un sujet beaucoup plus approfondi
L’amélioration du LCP est une étape cruciale vers l’amélioration du CVW, mais elle peut être la mesure CWV la plus difficile à optimiser.
LCP se compose de plusieurs couches de sous-métriques, chacune nécessitant une compréhension approfondie pour une optimisation efficace.
Ce guide vous a donné une idée de base pour améliorer le LCP, et les connaissances que vous avez acquises jusqu'à présent vous aideront à apporter des améliorations significatives.
Mais il reste encore beaucoup à apprendre. L'optimisation de chaque sous-métrique est une science nuancée. Restez à l'écoute, car nous publierons des guides détaillés consacrés à l'optimisation de chaque sous-métrique.
Plus de ressources :
