Le La plus grande peinture contenu (LCP) Dans Core Web Vitals, mesure à quelle vitesse un site Web se charge du point de vue d’un visiteur. Il examine combien de temps après l’ouverture d’une page, l’élément de contenu le plus grand devient visible. Si votre site Web se charge lentement, c’est mauvais pour l’expérience utilisateur et peut également provoquer votre site Classement plus bas dans Google.
Lorsque vous essayez de résoudre les problèmes de LCP, il n’est pas toujours clair sur quoi se concentrer. Le serveur est-il trop lent? Les images sont-elles trop grandes? Le contenu n’est-il pas affiché? Google a travaillé pour y remédier récemment en introduisant Sous-parties LCPqui vous indique d’où viennent les retards de chargement de page. Ils ont également ajouté ces données au Rapport Chrome UXvous permettant de voir ce qui provoque des retards pour les vrais visiteurs sur votre site Web!
Jetons un coup d’œil à ce que sont les sous-parties LCP, ce qu’ils signifient pour la vitesse de votre site Web et comment vous pouvez les mesurer.
Les quatre sous-parties LCP
Les sous-parties LCP divisent la plus grande métrique de peinture du contenu en quatre composants différents:
- Temps de premier octet (TTFB): À quelle vitesse le serveur répond à la demande de document.
- Retard de charge de ressources: Temps passé avant le début de l’image LCP.
- Temps de chargement des ressources: Temps passé à télécharger l’image LCP.
- Délai de rendu d’élément: Heure avant que l’élément LCP ne s’affiche.
Les horaires des ressources ne s’appliquent que si le plus grand élément de page est une image ou une image d’arrière-plan. Pour les éléments de texte, les composants de délai de charge et de chargement sont toujours nuls.
Comment mesurer les sous-parties LCP
Une façon de mesurer la quantité que chaque composant contribue au score LCP sur votre site Web est d’utiliser Test de vitesse du site Web. Développez la plus grande métrique de peinture contente pour voir les sous-parties et autres détails liés à votre score LCP.
Ici, nous pouvons voir que TTFB et la durée de charge d’image ensemble représentent 78% du score LCP global. Cela nous indique que ces deux composantes sont les endroits les plus percutants pour commencer à optimiser.
Que se passe-t-il pendant chacune de ces étapes? Un réseau demander une cascade Peut nous aider à comprendre quelles ressources chargent à chaque étape.
La vue de découverte d’image LCP filtre la visualisation de la cascade aux ressources qui sont pertinentes pour afficher la plus grande image de peinture contente. Dans ce cas, chacune des trois premières étapes contient une demande, et l’étape finale se termine rapidement sans nouvelles ressources chargées. Mais cela dépend de votre site Web spécifique et ne sera pas toujours le cas.
Il est temps de premier octet
La première étape pour afficher le plus grand élément de page consiste à récupérer le document HTML. Nous avons récemment publié un Article sur la façon d’améliorer la métrique TTFB.
Dans cet exemple, nous pouvons voir que la création de la connexion du serveur ne prend pas si longtemps. La plupart du temps est consacré à attendre que le serveur génère la page HTML. Donc, pour améliorer le TTFB, nous devons accélérer ce processus ou mettre en cache le HTML afin que nous puissions entièrement ignorer la génération HTML.
Retard de charge de ressources
La «ressource» que nous voulons charger est l’image LCP. Idéalement, nous avons juste un <img> Tag près du haut du HTML, et le navigateur le trouve immédiatement et commence à le charger.
Mais parfois, nous obtenons un Retard de chargecomme c’est le cas ici. Au lieu de charger l’image directement, la page utilise lazysize.js, une image de chargement de chargement paresseux Cela ne charge que l’image LCP une fois qu’elle a détecté qu’elle apparaîtra dans la fenêtre.
Une partie du délai de charge est causée par le fait de télécharger cette bibliothèque JavaScript. Mais le navigateur doit également compléter la mise en page et commencer à rendre le contenu avant que la bibliothèque ne sache que l’image est dans la fenêtre. Après avoir terminé la demande, il y a une tâche CPU (en orange) qui mène au Première peinture content Milestone, lorsque la page commence à rendu. Ce n’est qu’alors que la bibliothèque déclenche la demande d’image LCP.
Comment optimiser cela? Tout d’abord, au lieu d’utiliser une bibliothèque de chargement paresseuse, vous pouvez utiliser le natif loading="lazy" attribut d’image. De cette façon, charger des images ne dépend plus du premier code JavaScript.
Mais plus précisément, L’image LCP ne doit pas être chargée paresseusement. De cette façon, le navigateur peut commencer à le charger dès que le code HTML est prêt. Selon Google, vous devriez viser à Éliminez entièrement le retard de charge des ressources.
Durée de chargement des ressources
Le Sous-partie de durée de chargement est probablement le plus simple: vous devez télécharger l’image LCP avant de pouvoir l’afficher!
Dans cet exemple, l’image est chargée à partir du même domaine que le HTML. C’est bien car le navigateur n’a pas à se connecter à un nouveau serveur.
Autres techniques que vous pouvez utiliser pour réduire le retard de charge:
Délai de rendu d’élément
Le quatrième et dernier composant LCP, Rendre un retardest souvent le plus déroutant. La ressource s’est chargée, mais pour une raison quelconque, le navigateur n’est pas encore prêt à le montrer à l’utilisateur!
Heureusement, dans l’exemple que nous avons regardé jusqu’à présent, l’image LCP apparaît rapidement après sa charge. L’une des raisons courantes du retard de rendu est que L’élément LCP n’est pas une image. Dans ce cas, le délai de rendu est causé par scripts de blocage de rendu et feuilles de style. Le texte ne peut apparaître qu’après que ceux-ci ont été chargés et le navigateur a terminé le processus de rendu.
Une autre raison pour laquelle vous pourriez voir le retard de rendu est le moment où le site Web précharge l’image LCP. Le préchargement est une bonne idée, car il élimine pratiquement tout retard de charge et garantit que l’image est chargée tôt.
Cependant, si l’image termine le téléchargement avant que la page ne soit prête à rendre, vous verrez une augmentation du délai de rendu sur la page. Et c’est bien! Vous avez amélioré la vitesse de votre site Web dans l’ensemble, mais après avoir optimisé votre image, vous avez découvert un nouveau goulot d’étranglement sur lequel vous concentrer.
Sous-parties LCP dans les données réelles du nœud utilisateur
Regarder les plus grandes sous-parties de peinture contenu dans les tests en laboratoire peut fournir de nombreux informations sur l’endroit où vous pouvez optimiser. Mais trop souvent, le LCP Le laboratoire ne correspond pas à ce qui se passe pour les vrais utilisateurs!
C’est pourquoi, en février 2025, Google a commencé y compris les données de sous-partie dans le rapport de données Crux. Ce n’est pas (encore?) Inclus dans PagesPeed Insights, mais vous pouvez voir ces mesures dans l’onglet «Web Vitals» de Debugbear.
Un peu utile d’informations ici est le type de ressource LCP: Il vous indique combien de visiteurs ont vu l’élément LCP comme un élément texte ou une image.
Même pour la même page, différents visiteurs verront un contenu légèrement différent. Par exemple, différents éléments sont visibles en fonction de la taille de l’appareil, ou certains visiteurs verront une bannière cookie tandis que d’autres voient le contenu de la page réel.
Pour rendre les données plus faciles à interpréter, Google rapporte uniquement les données de sous-partie pour les images.
Si l’élément LCP est généralement un SMS sur la page, les informations sur les sous-parties ne seront pas très utiles, car elles ne s’appliqueront pas à la plupart de vos visiteurs.
Mais la rupture de Text LCP est relativement facile: tout ce qui ne fait pas partie du score TTFB est en retard.
Suivre les sous-parties sur votre site Web avec une véritable surveillance des utilisateurs
Les données de laboratoire ne correspondent pas toujours à ce que les vrais utilisateurs vivent. Les données de nœud sont superficielles, signalé uniquement pour les pages à fort traficet prend au moins 4 semaines Pour mettre à jour entièrement une fois qu’un changement a été déployé.
C’est pourquoi un outil de surveillance des utilisateurs réel comme Debugbear est utile lors de la réparation de vos scores LCP. Tu peux suivre les scores sur toutes les pages Sur votre site Web au fil du temps et obtenez des tableaux de bord dédiés pour chaque sous-partie LCP.
Vous pouvez aussi Passez en revue des expériences de visiteurs spécifiquesVoir quelle était l’image LCP pour eux, inspecter une cascade de demande et vérifier les synchronisations de la sous-partie LCP. Inscrivez-vous à un essai gratuit.
Conclusion
Le fait d’avoir des données métriques plus granulaires disponibles pour la plus grande peinture de contenu donne aux développeurs Web une longueur d’avance lors de la réalisation de leur site Web plus rapidement.
L’inclusion des sous-parties de Crux fournit de nouvelles informations sur la façon dont les vrais visiteurs éprouvent votre site Web et peuvent dire si les optimisations que vous envisagez auraient vraiment un impact.
(GG, YK)
Source link