Le Largest Contentful Paint (LCP) est une métrique vitale du Web central (CWV) qui marque le point dans la chronologie de chargement de la page où le contenu principal de la page a probablement fini de se charger. Pour obtenir un bon score LCP, le contenu principal d’une page Web doit finir de se charger en moins de 2,5 secondes.
Vous pouvez effectuer un audit ponctuel de la vitesse de la page pour vérifier un score LCP en utilisant des outils comme Google Page Speed Insights, ou dans n’importe quel outil de développement de navigateur Chromium, qui produira un rapport ressemblant à ceci :
Le score global de 59 a été calculé à partir d’une combinaison pondérée de cinq métriques différentes, affichées dans la grille des métriques. Si vous souhaitez en savoir plus sur ce calcul de score, consultez .
Les scores de métriques sont classés comme “médiocre”, “doit s’améliorer” ou “bon”, et sont identifiés par une clé de couleur et de forme. Le score LCP pour cette page sur ce test est de 4,4 secondes, ce qui est médiocre. De plus, remarquez en bas de l’image les images capturées pendant la chronologie de chargement de la page, qui montre ce qu’un utilisateur vivrait pendant que le contenu principal se charge. Nous savons que c’est mauvais, mais comment déboguer la cause racine ?
Pour commencer à déboguer pourquoi un score LCP est lent, vous pouvez choisir d’afficher les audits pertinents pour LCP sous la chronologie visuelle de chargement de la page.
Page Speed Insights conseille que notre LCP lent pourrait être amélioré si nous :
L’expansion de l’élément fournit plus d’informations pour chaque recommandation. Élargissons le premier élément — L’élément Largest Contentful Paint — pour voir quelles informations nous pouvons obtenir.
Malheureusement, ce panneau ne nous dit rien que nous ne savions pas déjà. Le tableau montre, nous pouvons voir que la phase de “Délai de chargement” représente 81 % du LCP, que nous avons observé dans la chronologie visuelle de chargement de la page ci-dessus. Mais ce rapport ne peut pas nous dire pourquoi il y a un délai de chargement — et c’est ce que nous devons déboguer !
Les outils comme Page Speed Insights et Google Lighthouse sont excellents pour diagnostiquer les problèmes et fournir des conseils exploitables pour les performances frontales basés sur des données d’un seul test de laboratoire isolé. Ce que ces outils ne peuvent pas faire, cependant, c’est évaluer les performances sur l’ensemble de votre pile de services et d’applications distribués pour un échantillon de vos vrais utilisateurs. Comment enquêter si le mauvais score LCP est en fait dû à un problème dans le backend ?
Voici où vous avez besoin de .
En suivant le parcours complet de l’utilisateur de la demande de page dans un navigateur à travers tous les systèmes et services en aval jusqu’à la base de données et retour, vous aide à identifier les opérations spécifiques causant des problèmes de performances dans l’ensemble de votre pile d’applications. Chaque trace comprend une collection de spans. Un span est un événement atomique plein de métadonnées et d’informations contextuelles, qui vous aide à comprendre davantage les parties interconnectées de vos systèmes distribués. Les spans sont connectés et associés à une trace à la suite d’un identifiant unique envoyé via un en-tête HTTP à travers ces systèmes. Le traçage est également utile dans les applications autonomes qui ont à la fois un côté serveur et un côté client, comme les méta-cadres JavaScript modernes.
Nous pouvons utiliser le traçage pour trouver la cause racine d’un mauvais score LCP en traçant la cascade d’événements du moment où un utilisateur atterrit sur la page des produits jusqu’à ce que le contenu principal se charge enfin. Parcourons-le étape par étape.
Ou vous pourriez sauter tout cela et faire défiler directement jusqu’à si vous utilisez déjà Sentry.
La plupart d’entre nous peuvent probablement dire quand une page met du temps à se charger, vous pourriez donc finir par sauter cette étape. Cela dit, si vous avez fait un test CWV en utilisant votre machine de développement haut de gamme avec une connexion Internet haut débit et que les scores étaient mauvais, alors vous savez que vous avez un vrai problème à résoudre.
Sentry fournit un SDK pour une variété de langages de programmation et de cadres. Tout d’abord, et créez un nouveau projet pour chacune de vos applications. Chaque projet aura un DSN unique (Data Source Name), c’est ce que vous utiliserez pour pointer votre application vers votre projet Sentry dans votre code.
Disons que vous utilisez React pour votre frontend. Installez le via votre gestionnaire de paquets préféré.
Initialisez Sentry en quelques lignes de code et configurez le .
Pour votre backend, disons que vous exécutez un . Ajoutez et à votre Gemfile :
Et initialisez le SDK dans votre :</p>
Consultez la pour votre SDK préféré, ou créez un nouveau projet dans Sentry où vous serez guidé à travers le processus de configuration.
Eh bien, vous ne pourrez probablement pas vous détendre entièrement. Votre application est nulle et met du temps à se charger. Utilisez plutôt ce temps pour lire des demandes de en colère sur à quel point vous êtes un développeur terrible. Ne vous inquiétez pas ; tout cela en vaudra la peine lorsque vous trouverez enfin la véritable source du goulot d’étranglement des performances LCP.
En fonction de la quantité de trafic que reçoit votre site Web, vous pourriez avoir besoin d’attendre quelques jours pour obtenir suffisamment de données.
Dans Sentry, accédez à Insights > Web Vitals pour un aperçu rapide du score de performance global de votre projet et du CWV. Cliquez sur les en-têtes de colonne du tableau pour trier les données par “LCP” descendant pour confirmer que les données de terrain correspondent à vos données de laboratoire. C’est le cas ? Super.
Sur la page Insights Web Vitals, nous allons cliquer sur la route de la page avec la pire performance pour afficher des données échantillonnées pour cette route de page uniquement. Dans notre cas, c’est la page “/produits”. Les Core Web Vitals auront l’air différent ici (c’est-à-dire pire), car ils sont calculés à l’aide de données provenant uniquement de la page des produits plutôt que de l’application complète.
La prochaine étape consiste à explorer la trace complète des événements. Il existe de nombreuses façons d’accéder à la vue de trace dans Sentry, mais à partir de ce résumé CWV, vous pouvez cliquer sur le bloc de score LCP (qui dans ce cas est de 6,55s) pour afficher un ensemble de données échantillonnées avec une variété de scores à travers le spectre.
Cliquez sur la transaction en haut du tableau avec le pire score LCP pour afficher la trace. C’est là que tous vos rêves de débogage se réaliseront.
La vue de trace montre quand le LCP s’est produit dans la chronologie. Chaque span qui a été envoyé à Sentry avant que le LCP ne se produise est maintenant coupable jusqu’à preuve du contraire. Heureusement, nous n’avons pas besoin d’interroger chaque span individuellement car Sentry a déjà mis en évidence les causes probables de tout ralentissement avec un symbole d’avertissement. Développez les spans pour enquêter plus en profondeur jusqu’à ce que vous trouviez la cause racine de tout goulot d’étranglement. Dans le cas de cette application, deux requêtes lentes à la base de données qui se produisent lorsqu’une demande est faite à la page des produits sur le frontend sont à l’origine du mauvais score LCP.
Nous avons réussi à trouver la cause racine d’un problème de performance frontend qui n’avait pas de solution évidente. Nous avons identifié que le ralentissement s’est produit en raison de deux requêtes spécifiques à la base de données. C’était presque trop facile ! Maintenant, il est temps d’optimiser ces requêtes à la base de données, ce qui pourrait ne pas être aussi facile.
Vous pouvez sauter les étapes 3-5 et aller directement à l’ (actuellement en version bêta) en naviguant vers Explorer > Trace. Sur cette vue, vous pouvez filtrer tous les spans à travers vos projets en utilisant le champ de recherche (qui fournit des indices sur les critères par lesquels vous pouvez filtrer).
Après avoir découvert le problème de LCP lent sur la page des produits, je peux utiliser l’Explorateur de traces pour filtrer tous les spans par pour obtenir un aperçu rapide des durées de span associées à ces spans. Si je remarque quelque chose d’anormal, je peux cliquer directement dans la trace pour enquêter.
Pour avoir une idée de la façon dont cette expérience de débogage basée sur les Core Web Vitals pourrait ressembler et se sentir dans le produit Sentry, cliquez sur cette démo interactive.
Si vous n’êtes toujours pas convaincu, consultez cet atelier en direct de Sentry que j’ai récemment animé avec Lazar. Vous obtiendrez encore plus d’informations sur la façon d’utiliser Sentry pour déboguer vos problèmes frontend qui pourraient avoir des solutions backend, vous entendrez parler de moi d’une terrible histoire de débogage qui me hante encore aujourd’hui, et il pourrait y avoir quelques blagues. Laissez un commentaire amusant si vous passez par là !