Surveillance efficace des performances Web —

Il n’existe pas de moyen unique de mesurer les performances d’un site Web. Cela dit, le Éléments essentiels du Web les statistiques que Google utilise comme facteur de classement sont un excellent point de départ, car ils couvrent différents aspects de l’expérience du visiteur :

• La plus grande peinture de contenu (LCP) : Mesure le temps de chargement initial de la page.
• Changement de mise en page cumulatif (CLS): Mesure si le contenu est stable après le rendu.
• Interaction avec la peinture suivante (INP): mesure la rapidité avec laquelle la page répond aux entrées de l’utilisateur.

Il y a aussi de nombreuses autres mesures de performances Web que vous pouvez utiliser pour suivre les aspects techniques, comme le poids de la page ou le temps de réponse du serveur. Bien que ces éléments n’aient souvent pas d’importance directe pour l’utilisateur final, ils vous donnent un aperçu de ce qui ralentit vos pages.

Vous pouvez également utiliser le API de synchronisation des utilisateurs pour suivre les étapes de chargement des pages qui sont spécifiquement importantes sur votre site Web.

Données utilisateur synthétiques et réelles

Il y a deux types différents des données de performances web :

• Tests synthétiques sont exécutés dans un environnement de test contrôlé.
• Données utilisateur réelles sont collectés auprès des visiteurs réels du site Web.

La surveillance synthétique peut fournir des rapports très détaillés pour vous aider à identifier les problèmes de vitesse de page. Vous pouvez configurer exactement la manière dont vous souhaitez collecter les données, en choisissant une vitesse de réseau, une taille d’appareil ou un emplacement de test spécifiques.

Obtenez une expérience pratique de la surveillance synthétique en utilisant le logiciel gratuit Test de vitesse du site Web DebugBear à vérifier sur votre site internet.

Cela dit, vos paramètres de test synthétique peuvent ne pas correspondre à ceux typiques de vos vrais visiteurs, et vous ne pouvez pas créer un script pour toutes les manières possibles dont les gens peuvent interagir avec votre site Web.

C’est pourquoi vous avez également besoin d’une véritable surveillance des utilisateurs (RUM). Au lieu de regarder une seule expérience, vous voyez différents temps de chargement et comment des segments de visiteurs spécifiques sont impactés. Vous pouvez examiner des pages vues spécifiques pour identifier la cause des mauvaises performances d’un visiteur particulier.

Dans le même temps, les données des utilisateurs réels ne sont pas aussi détaillées que les rapports de tests synthétiques, en raison des limitations de l’API Web et des problèmes de performances.

DebugBear propose les deux surveillance synthétique et surveillance réelle des utilisateurs:

• Pour mettre en place des tests synthétiques, il vous suffit de saisir l’URL d’un site Web, et
• Pour collecter des métriques utilisateur réelles, vous devez installer un extrait d’analyse sur votre site Web.

Trois étapes pour un site Web rapide

La collecte de données vous aide tout au long du cycle de vie de vos optimisations de performances Web. Vous pouvez suivre ce processus en trois étapes :

1. Identifier: Collectez des données sur votre site Web et identifiez les expériences lentes des visiteurs.
2. Diagnostiquer: Plongez en profondeur dans l’analyse technique pour trouver des optimisations.
3. Moniteur: Vérifiez que les optimisations fonctionnent et soyez alerté des régressions de performances.

Examinons chaque étape en détail.

Étape 1 : Identifier les expériences lentes des visiteurs

Qu’est-ce qui vous pousse à vous pencher en premier lieu sur les problèmes de performances d’un site Web ? Vous avez probablement déjà des problèmes spécifiques en tête, qu’ils proviennent de rapports clients ou de mauvais scores dans le Section Core Web Vitals de la console de recherche Google.

Les données utilisateur réelles sont le meilleur endroit pour vérifier les pages lentes. Il vous indique si les problèmes techniques sur votre site entraînent réellement une mauvaise expérience utilisateur. Il est facile de collecter des données sur l’ensemble de votre site Web (alors que des tests synthétiques doivent être mis en place pour chaque URL). Et vous pouvez souvent obtenir un nombre de vues ainsi que les mesures de performances. Une page moyennement lente qui reçoit deux visiteurs par mois n’est pas aussi importante qu’une page moyennement rapide qui reçoit des milliers de visites par jour.

Le tableau de bord Web Vitals du produit RUM de DebugBear vérifie l’état des performances de votre site et affiche les pages et les URL les plus visitées où de nombreux visiteurs ont une mauvaise expérience.

Vous pouvez également exécuter un analyse du site Web pour obtenir une liste d’URL de votre plan de site, puis vérifier chacune de ces pages par rapport aux données utilisateur réelles de Google Rapport sur l’expérience utilisateur Chrome (CrUX). Cependant, cela ne fonctionnera que pour les pages qui atteignent un seuil de trafic minimum pour être incluses dans l’ensemble de données CrUX.

Le résultat de l’analyse met en évidence les pages avec des scores Web Vitals médiocres sur lesquelles vous souhaiterez peut-être approfondir vos recherches.

Si aucune donnée utilisateur réelle n’est disponible, il existe un outil d’analyse appelé Un pharebasé sur l’outil Lighthouse de Google. Il exécute des tests synthétiques pour chaque page, vous permettant de filtrer les résultats afin d’identifier les pages qui doivent être optimisées.

Étape 2 : Diagnostiquer les problèmes de performances Web

Une fois que vous avez identifié les pages lentes de votre site Web, vous devez examiner ce qui se passe réellement sur votre page et qui provoque des retards.

Temps de chargement de la page de débogage

S’il y a des problèmes avec les mesures de temps de chargement des pages, comme La plus grande peinture de contenu (LCP) — les résultats des tests synthétiques peuvent fournir une analyse détaillée. Vous pouvez également exécuter tests de vitesse de page pour tester et mesurer l’impact de certaines optimisations.

Les données utilisateur réelles peuvent toujours être importantes lors du débogage de la vitesse des pages, car le temps de chargement dépend de nombreux facteurs spécifiques à l’utilisateur et à l’appareil. Par exemple, en fonction de la taille de l’appareil de l’utilisateur, l’élément de page responsable du LCP peut varier. Les données RUM peuvent fournir une ventilation des facteurs d’influence possibles, tels que les sélecteurs CSS et les URL d’images, pour tous les visiteurs, vous aidant ainsi à vous concentrer sur ce qui doit exactement être corrigé.

Débogage des interactions lentes

Les données RUM sont également généralement nécessaires pour diagnostiquer correctement les problèmes liés au Interaction avec la peinture suivante (INP) métrique. Plus précisément, les données réelles des utilisateurs peuvent fournir un aperçu des causes des interactions lentes, ce qui vous aide à répondre à des questions telles que :

• Quels éléments de la page sont responsables ?
• Le temps est-il consacré au traitement de tâches en arrière-plan déjà actives ou à la gestion de l’interaction elle-même ?
• Quels scripts contribuent le plus au temps de traitement global du processeur ?

Vous pouvez afficher ces données à un niveau élevé pour identifier les tendances, ainsi qu’examiner des pages vues spécifiques pour voir ce qui a impacté une expérience de visiteur spécifique.

Étape 3 : Surveiller les performances et répondre aux régressions

La surveillance continue des performances de votre site Web vous permet de savoir si les performances s’améliorent après avoir apporté une modification et vous avertit lorsque les scores diminuent.

La façon dont vous réagissez aux régressions de performances dépend de si vous envisagez des tests synthétiques en laboratoire ou de véritables analyses d’utilisateurs.

Données synthétiques

Les paramètres de test pour les tests synthétiques sont standardisés entre les exécutions. Bien que les changements d’infrastructure, comme les mises à niveau du navigateur, entraînent parfois des changements, les performances sont plus généralement déterminées par les ressources chargées par le site Web et le code qu’il exécute.

Lorsqu’une métrique change, DebugBear vous permet d’afficher une comparaison avant et après entre les deux résultats de test. Par exemple, la capture d’écran suivante affiche une régression dans la métrique First Contentful Paint (FCP). La comparaison révèle que de nouvelles images ont été ajoutées à la page, en concurrence pour la bande passante avec d’autres ressources de page.

D’après le rapport, il ressort clairement qu’un fichier CSS qui prenait auparavant 255 millisecondes à charger prend désormais 915 millisecondes. Étant donné que des feuilles de style sont nécessaires pour afficher le contenu de la page, cela signifie que la page se charge désormais plus lentement, vous donnant ainsi un meilleur aperçu de ce qui nécessite une optimisation.

Données utilisateur réelles

Lorsque vous constatez un changement dans les statistiques des utilisateurs réels, il peut y avoir deux causes :

1. Un changement dans les caractéristiques ou le comportement des visiteurs, ou
2. Un changement technique sur votre site internet.

Le lancement d’une campagne publicitaire, par exemple, augmente souvent les redirections, réduit les accès au cache et modifie les données démographiques des visiteurs. Lorsque vous constatez une régression dans les données RUM, la première étape consiste à savoir si le changement s’est produit sur votre site Web ou dans le navigateur de votre visiteur. Vérifiez les modifications du nombre de vues dans les campagnes publicitaires, les domaines référents ou la vitesse du réseau pour obtenir une image plus claire.

Si ces visites ont des performances différentes de celles de vos visiteurs typiques, cela suggère que la répression n’est pas due à un changement sur votre site Web. Cependant, vous devrez peut-être encore apporter des modifications à votre site Web pour mieux servir ces cohortes de visiteurs et leur offrir une bonne expérience.

Pour identifier la cause d’un changement technique, examinez les mesures de panne des composants, telles que Sous-parties du LCP. Cela vous aide à affiner la cause d’une régression, qu’elle soit due à des modifications du temps de réponse du serveur, à de nouvelles ressources bloquant le rendu ou à l’image LCP.

Vous pouvez également vérifier les changements dans les propriétés d’affichage des pages, comme différents sélecteurs d’éléments LCP ou des scripts spécifiques qui entraînent de mauvaises performances.

Conclusion

Les tests de vitesse de page ponctuels sont un excellent point de départ pour optimiser les performances. Cependant, un outil de surveillance comme DebugBear peut constituer la base d’un site Web plus complet. stratégie de performance cela vous aide à rester rapide sur le long terme.

Obtenir un essai gratuit de DebugBear sur notre site internet !

(gg, ouais)