AccueilContact

Problème de score LCP lié au backend

Publié dans Développement Web
5 juillet 2024
6 min read
Problème de score LCP lié au backend

Votre mauvais score LCP pourrait être un problème backend

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.

Comment vérifier un score LCP

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 ?

Ce qui cause un mauvais score LCP

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 :

  • Réduisons le JavaScript inutilisé
  • (comme les formats webp et avif)
  • Encodons efficacement les images (réduire la taille du fichier sans compromettre la qualité)

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 .

Comment utiliser le traçage pour déboguer un mauvais score LCP

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.

Étape 0 : Soupçonnez que vous avez un vrai problème LCP

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.

Étape 1 : Installez un SDK d’outil de surveillance des performances des applications comme Sentry sur l’ensemble de vos applications et services

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.

Étape 2 : Asseyez-vous et détendez-vous pendant que votre outil de surveillance des performances des applications (Sentry) collecte des données auprès de vrais utilisateurs

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.

Étape 3 : Explorez vos scores Core Web Vitals pour trouver des données de terrain agrégées qui soutiennent vos données de laboratoire

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.

Étape 4 : Trouvez des événements d’échantillonnage de chargement de page avec un mauvais score LCP

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.

Étape 5 : Explorez la trace complète de ces événements de chargement de page pour découvrir où se produisent les goulets d’étranglement de performance

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.

Mais attendez, il y a plus !

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.

Essayez l’expérience complète de débogage en temps réel

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.

Mais attendez, il y a encore plus !

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à !

Source de l’article


Share

Article précédent
RBUILDER - Un constructeur de blocs Ethereum écrit en Rust

Articles similaires

Choses étranges apprises en écrivant un émulateur x86
12 juillet 2024
1 min
© 2024, All Rights Reserved.

Liens Rapides

Partenariats et opportunités publicitairesContactez nous

Réseaux Sociaux