Pratique de construction de surveillance des performances de la page d'accueil de la voiture

1. Introduction

Se concentrer sur l'expérience utilisateur et améliorer les performances des pages est l'une des tâches quotidiennes de chaque étudiant en R&D front-end. Bien qu'il ne soit pas facile de mesurer l'aide apportée à l'amélioration des performances des pages pour l'entreprise, les avantages doivent largement l'emporter sur les inconvénients. Comment mesurer les performances des pages ? Comment aider les étudiants R&D à localiser rapidement le goulot d'étranglement des performances des pages ? Cela a toujours été l'une des tâches clés du front-end. Cet article partage une partie du travail d'Autohome dans la construction du suivi des performances des pages, qui comprend principalement trois aspects :

Sélection de la technologie

Quelles solutions technologiques de surveillance des performances des pages dois-je choisir ?
Partant du principe de ne pas affecter autant que possible les performances de la page, il peut non seulement mesurer les performances de la page de manière objective et complète, mais également aider les étudiants en recherche et développement à localiser rapidement le goulot d'étranglement des performances.
Comment évaluer les performances hors page d'accueil des applications SPA ?
En partant du principe de ne pas affecter autant que possible les performances de la page et d'assurer l'exactitude des données collectées, collectez et rapportez autant de données que possible. Comment choisir le calendrier et la méthode de rapport appropriés pour les indicateurs ?

conception de l'architecture globale

Intégrez les solutions techniques sélectionnées, créez un cadre de surveillance systématique des performances, fournissez une chaîne d'outils de surveillance et d'analyse des performances, et aidez les étudiants en production et en recherche à découvrir et à localiser les problèmes de performances des pages à chaque étape de DevOps.

Établir un système de jugement

Avec les données, nous pouvons mesurer ; avec la notation, la technologie peut être améliorée.

En utilisant les indicateurs collectés, selon les caractéristiques de l'application, selon l'importance de chaque indicateur de performance, définissez différentes lignes de base et pondérations, et obtenez le score de l'application sous forme de moyenne pondérée. Grâce au score, indiquez intuitivement aux étudiants en recherche et développement si la page d'application est rapide ou lente ? Les performances de l'application sont-elles élevées ou faibles ? A-t-il besoin d'être amélioré ?

Le score de l'application ne peut refléter que les performances d'une seule application, et il sert principalement les étudiants en production et en recherche. Une entreprise a plusieurs services, chaque service a plusieurs équipes et une équipe a plusieurs applications. Nous avons besoin de scores de performance au niveau de l'entreprise, du service et de l'équipe afin que les dirigeants à tous les niveaux puissent comprendre intuitivement les performances de leurs pages responsables, et c'est pratique Le leader supérieur juge le niveau de performance parmi les équipes subordonnées, nous utilisons donc toujours l'algorithme de moyenne pondérée pour obtenir les scores de performance de l'équipe, du département et de l'entreprise en fonction du numéro PV de l'application et du niveau d'application.

2 Sélection de la technologie

Selon l'environnement d'exploitation lors de la surveillance des performances des pages, nous divisons les solutions techniques en deux types : la surveillance synthétique (SYN) et la surveillance de l'utilisateur réel (RUM).

Surveillance synthétique (ci-après dénommée SYN)

Fait référence à l'exécution de la page dans l'environnement de simulation pour évaluer les performances de la page. Les premiers outils représentatifs incluent les célèbres YSlow et PageSpeed. Au fur et à mesure que la technologie progresse, les trois outils SYN les plus matures sont : Lighthouse, WebPageTest et SiteSpeed. Bien que Lighthouse ne supporte que le navigateur Chrome et ait des coûts de mise en œuvre élevés, il présente les avantages du support de Google, d'une extension facile, d'indicateurs riches et d'une notation. Il a progressivement remplacé WebPageTest et est devenu l'outil préféré de SYN. Ce qui suit prend Lighthouse comme exemple pour présenter le processus de fonctionnement, les avantages et les inconvénients de SYN.

processus de travail

À partir de la page des résultats en cours d'exécution, en plus de générer des valeurs et des scores d'indicateurs de performance clés, Lighthouse nous fournit également des suggestions d'optimisation et des résultats de diagnostic. La version 10.1.0 de Lighthouse intègre des spécifications ou des suggestions de performances et de meilleures pratiques 94 et 16, parmi lesquelles il existe de nombreuses spécifications plus significatives qui sont moins remarquées dans la recherche et le développement quotidiens, telles que : minimiser le travail du thread principal (mainthread -work-breaking), la page web a empêché la restauration du cache aller-retour (bf-cache), la réduction du JavaScript inutilisé (unused-javascript) dans le fichier js, etc.

Il est recommandé d'utiliser Node Cli ou Node Module pour exécuter Lighthouse et de générer les résultats aux formats html et json en même temps. Les données dans json sont plus complètes, y compris des informations détaillées telles que : le plus grand élément de peinture de contenu, les tâches de thread principal de longue durée qui doivent être évitées (tâches longues), etc.

Avantages et inconvénients

Selon notre pratique, Lighthouse présente les avantages et inconvénients suivants :

Améliorer

En réponse aux lacunes ci-dessus et aux exigences du produit, nous avons apporté quelques améliorations :

• Afin de résoudre le problème que l'environnement non-benchmark par défaut, la même page s'exécute sur différents clients, et les résultats sont différents en raison de différents environnements d'exploitation et ressources matérielles, nous avons apporté deux améliorations :

Tout d'abord, fournissez l'environnement d'exploitation de base SYN. Utilisez le module Lighthouse Node pour développer vous-même la version Web du service SYN et la déployer dans le conteneur. En ajoutant une politique de file d'attente côté serveur Node, il est garanti qu'un seul conteneur n'est autorisé à exécuter qu'une seule tâche SYN à tout moment, et les ressources matérielles (4 cœurs + 4G) et la configuration de la vitesse du réseau de chaque conteneur sont les mêmes (Les applications côté M utilisent uniformément une vitesse de réseau de 10M), afin de garantir que les résultats en cours d'exécution et les scores finaux sont relativement justes et fiables.

Deuxièmement, il prend en charge l'exécution de tâches SYN en tant que tâches planifiées à des intervalles de 6, 12 ou 24 heures. Comptez les valeurs AVG et TP des indicateurs de résultat de plusieurs exécutions et excluez l'écart de résultat de quelques exécutions anormales.

• Visant le problème de courir lentement et de prendre beaucoup de ressources. Nous pensons qu'une même page, s'il n'y a pas de révision, il n'est pas nécessaire de continuer à tester trop fréquemment. Il est recommandé d'ajouter une tâche planifiée à exécuter une fois toutes les 12 heures ou plus pour les pages avec une grande quantité de PV ou des pages importantes. Cela peut non seulement refléter objectivement les performances de la page, mais aussi économiser des ressources.
• Intégrez SYN dans le pipeline CI et utilisez SYN comme outil de mise en œuvre pour les tests de performances de page avant le lancement ou la comparaison de produits concurrents.

Scène applicable

• Intégrez SYN en tant qu'outil de test des performances des pages dans les applications back-office de surveillance frontale, les suites QA et CI. Il est recommandé aux étudiants en R&D d'évaluer les performances de la page via SYN avant de livrer la page, et d'améliorer les défauts de qualité de la page et la qualité de la livraison en fonction des suggestions d'optimisation et des résultats de diagnostic.
• Utilisez SYN pour comparer les produits concurrents.
• En utilisant SYN comme outil préféré pour analyser les pages lentes capturées par RUM, combiné avec Chrome DevTools, la plupart des problèmes peuvent être localisés dans la pratique.

Instructions

Résumer

SYN a un faible coût de mise en œuvre et est facile à unifier les normes. Par rapport à RUM, il est moins affecté par l'environnement d'exécution et les résultats sont plus comparables et reproductibles. C'est une partie importante de la surveillance des performances. Basé sur Lighthouse, avec l'aide de K8S et d'autres technologies d'orchestration de conteneurs, la création rapide d'un service Web SYN qui fournit un environnement de référence est la première étape de la création d'un système de surveillance des performances des pages. Cette étape fournit principalement des fonctions clés telles que l'évaluation des performances des pages et l'analyse des pages lentes. Bien que Lighthouse ait encore deux problèmes : il ne supporte que Google Chrome, il n'est pas assez représentatif et il ne peut pas vraiment refléter les performances du vrai client. En parallèle, nous résoudrons ces deux problèmes en ajoutant une autre solution technique : le Real User Monitoring (RUM).

Real User Monitoring (RUM en abrégé)

Comme son nom l'indique, il fait référence à la surveillance et à l'exécution sur de vrais terminaux d'utilisateurs (navigateurs), en collectant de vrais indicateurs de performance lorsque les utilisateurs exécutent des pages. Il existe deux principales solutions techniques dans l'industrie :

1. S'appuyant sur l'organisation W3C et divers éditeurs de navigateurs prennent largement en charge les solutions techniques : PerformanceTiming et PerformanceNavigationTiming. Il préfère mesurer la consommation de temps de chaque nœud et de chaque étape lorsque la page est en cours d'exécution du point de vue du traitement du navigateur.
2. Chaque usine développe ses propres solutions techniques en fonction des besoins réels. Google web-vitals est le meilleur représentant d'entre eux. Du point de vue de l'expérience utilisateur, il utilise des indicateurs plus faciles à comprendre pour montrer les performances des pages.

En plus des deux solutions techniques courantes ci-dessus, un petit nombre de fournisseurs commerciaux de services de surveillance frontale, en plus de prendre en charge le W3C et les web-vitals, fournissent également un petit nombre d'indicateurs de performance personnalisés, tels que : FMP dans Ali ARMS, SPA_LOAD dans Byte WebPro. SPA_LOAD est utilisé pour évaluer les performances de la page non-accueil SPA, ce qui est assez innovant et sera mentionné plus tard.

Sélection de la technologie

Le choix de la technologie résout principalement deux problèmes : 1) Les spécifications PerformanceTiming et PerformanceNavigationTiming du W3C, laquelle devrait être la principale ? 2) Comment la spécification W3C Timing et les web-vitals doivent-ils coopérer ?
Les spécifications PerformanceTiming et PerformanceNavigationTiming du W3C, laquelle devrait être la principale ?
PerformanceTiming : il a été abandonné par la dernière norme W3C, mais les navigateurs grand public actuels le prennent toujours en charge, et les anciens navigateurs le supportent bien et ont une compatibilité élevée.

PerformanceNavigationTiming : La dernière norme a été introduite en 2019 avec le niveau 2 de synchronisation de navigation, qui est destiné à remplacer le niveau 1 de synchronisation de navigation, qui couvre la synchronisation de performance.
Point de changement :
Intégrez les fonctions de PerformanceTiming et PerformanceNavigation.
Abandonner le nœud domLoading qui ne suffit pas à guider à cause des différentes implémentations des éditeurs de navigateurs.
Ajoutez des nœuds liés à ServiceWorker.
L'heure de chaque nœud d'attribut utilise une heure relative de haute précision à partir de startTime.
Avantages :
Utilisez un temps relatif de haute précision pour éviter des valeurs de nœud ultérieures inexactes en raison de modifications de l'heure système côté utilisateur.
Prend en charge les statistiques liées à ServiceWorker.
Inconvénients :
Manque de compatibilité du navigateur.
en conclusion:
Selon les statistiques de Can I Use, la différence de compatibilité entre les deux n'est que de 2,67 %, mais à partir de notre répartition réelle des utilisateurs, en utilisant PerformanceNavigationTiming, la compatibilité des utilisateurs chute de 12 %, ce qui est inacceptable. Nous nous concentrons donc sur PerformanceNavigationTiming, si le navigateur ne le supporte pas, utilisez PerformanceTiming. Il y a peu de différence dans le format de données entre les deux, ignorez simplement le nœud domLoading dans PerformanceTiming et considérez que le navigateur n'est pas compatible avec le nœud workStart lors de l'utilisation de PerformanceTiming.
Comment la spécification W3C Timing et les web-vitals doivent-ils fonctionner ensemble ?
PerformanceNavigationTiming (ci-après dénommé Timing) : basé sur la spécification W3C, il se concentre sur la mesure des performances des pages du point de vue du traitement du navigateur, ci-après dénommé Timing.
avantage:

• Bonne compatibilité avec le navigateur Bonne compatibilité avec le navigateur.
• Des données riches et des indicateurs complets. C'est-à-dire qu'il inclut la consommation de temps de chaque étape, telle que : décharger, rediriger, DNS, TCP, SSL, réponse, DomContentLoadedEvent et LoadEvent ; il prend également en charge l'affichage de la consommation de temps lorsque la page s'exécute sur chaque nœud, par exemple : workStart , fetchStart, requestStart, domInteractive et domComplate ; il est également possible de calculer la consommation de temps de DCL ( DomContentLoaded ), de l'événement window.load ou de PageLoad (chargement de la page) en fonction de la valeur de nœud donnée.

défaut:

• Les métriques clés sont manquantes. Bien qu'il existe de nombreux indicateurs complets, ils ne sont pas assez intuitifs pour exprimer l'effet d'expérience utilisateur.

web-vitals : contient actuellement 6 indicateurs : TTFB, FCP, LCP, FID, INP et CLS, où FID sera remplacé par INP. TTFB, FCP et LCP reflètent les performances de chargement de la page, FID et INP représentent l'expérience d'interaction de la page et CLS représente la stabilité visuelle de la page. Seules 6 mesures prennent en charge l'évaluation du chargement de la page, de l'interaction et de la stabilité visuelle. Cependant, certains indicateurs de web-vitals proviennent de spécifications telles que LargegestContentfulPaint, LayoutShift, PerformanceEventTiming et PerformancePaintTiming formulées par le W3C, mais ils sont plus compatibles et plus intégrés.

avantage:

• Les indicateurs sont concis, concis et faciles à comprendre.
• Avec sa propre ligne de base, il peut juger des performances de la page en fonction des indicateurs.

Inconvénients :
Compatibilité navigateur insuffisante, notamment côté IOS.
Le LCP peut être truqué. Méthode : Ajoutez une image d'arrière-plan blanche de grande taille à la page. Le temps de chargement de cette image est probablement la valeur LCP, mais la valeur LCP n'a aucune signification commerciale. Limité par les principes LCP et CLS, il
existe certaines exigences concernant le calendrier de collecte des indicateurs, qui seront présentées en détail ultérieurement .
Exigences :
mesure réelle, objective et complète des performances de la page.
Conclusion
Collecter en même temps des données de Timing et de web-vitals apporte les avantages suivants :
des indicateurs riches et des données complètes. Il peut non seulement utiliser le Timing pour refléter le traitement chronophage de chaque nœud et de chaque étape du point de vue du navigateur, mais également exprimer intuitivement la vision de l'utilisateur à travers l'expérience web-vitals. Il est recommandé de juger visuellement d'abord les performances de la page à l'aide des éléments vitaux du Web, puis de les analyser plus en détail via la synchronisation pour obtenir une considération et une analyse complètes, et réduire les erreurs d'appréciation des performances de la page en raison d'une compatibilité insuffisante du navigateur et de la fraude LCP.
La combinaison des données Timing et Web Vitals facilite la localisation des problèmes. Par exemple, si le TTFB collecté par web-vitals est lent, vous pouvez utiliser Timing pour localiser la lenteur spécifique dans Unload, Redirect, DNS, TCP et SSL.
Résoudre le problème de la compatibilité insuffisante des anciens navigateurs web-vitals. Si le navigateur ne prend pas en charge les éléments vitaux Web, vous pouvez évaluer les performances de la page via DCL, l'événement window.load ou PageLoad (chargement de la page) qui prend du temps.
Section : Sélection de la technologie RUM, tout en collectant PerformanceNavigationTiming et Web-Vitals. Si le navigateur n'est pas compatible avec PerformanceNavigationTiming, utilisez plutôt PerformanceTiming.

Quels indicateurs collecter

Notre exigence est non seulement d'affecter autant que possible les performances des pages, mais également de mesurer les performances des pages de manière objective et complète, et d'aider les étudiants en R&D à localiser rapidement les goulots d'étranglement des performances. Plus précisément, il comprend trois exigences : 1) Les indicateurs doivent être complets et objectifs ; 2) Les points de goulot d'étranglement des pages lentes peuvent être trouvés ; 3) En partant du principe que les deux premières exigences sont satisfaites, les performances de la page ne doivent pas être autant affectées que possible.

Les indicateurs doivent être complets et objectifs
Dans un premier temps, nous avons collecté six indicateurs de web-vitals, et les résultats sont les suivants :

Google prévoit de remplacer FID par INP en 2024. FID reflète le délai de la première interaction, et INP représente le délai le plus long parmi toutes les interactions. Nous pensons que FID et INP ont leurs propres scénarios d'utilisation, et il n'est pas contradictoire de les conserver en même temps.

Deuxièmement, nous avons traité PerformanceNavigationTiming, l'effet est le suivant : il

est différent de l'exemple de diagramme W3C ci-dessous :

la raison est :

• Au cours de l'opération de page réelle, les étapes ne s'exécutent pas nécessairement en série, comme illustré dans la figure ci-dessus. Il y a des cas où responseEnd prend plus de temps que domLoading.
• La phase de cache HTTP n'a pas de nœuds d'heure de début et de fin, elle peut uniquement indiquer qu'elle se produit entre les nœuds fetchStart et domainLookUpStart.
• Les phases ServiceWorkerInit, ServiceWorkerFetchEvent et Request
  n'ont que des nœuds de début et aucun nœud de fin, de sorte que les phases chronophages ne peuvent pas être comptées. Pour l'étape de demande, responseStart ne peut pas être utilisé
  comme nœud de terminaison, car le contenu est transmis dans des trames sur le réseau et l'intégralité du contenu de la page peut ne pas être transmise en une seule fois.
• L'étape de traitement commence par domInteractive, ce qui n'est pas conforme à la loi objective. Lorsque la page s'exécute sur domInteractive, le DOM
  est prêt, de sorte que l'étape de traitement ne peut pas représenter le processus de traitement de la page.

Nous combinons donc l'exemple de diagramme du W3C pour montrer le processus d'exécution de la page réelle sous la forme de points, de segments et de lignes :

• Point : Désigne le nœud qui n'a pas de nœud terminal, comprenant : workStart, fetchStart, requestStart, domInteractive et
  domComplete, représentés par un point blanc.
• Segment : fait référence à l'étape de traitement où les nœuds de début et de fin existent réellement. Par exemple, la valeur de l'étape de déchargement est : unloadEnd - unloadStart. Il en va de même pour la redirection, DNS, TCP, SSL, Response, domContentLoadedEvent et loadEvent, représentés par un histogramme bleu.
• Ligne : contient des événements déclenchés lors du chargement de la page, tels que DCL (DomContentLoaded), window.load. De plus, nous personnalisons
  l'événement PageLoad pour indiquer le temps de chargement de la page entière, et la valeur est : loadEventEnd-loadEventStart. Indiqué par un histogramme jaune.
  Algorithmes spécifiques pour les segments et les lignes :
• UnloadEvent = unloadEventEnd - unloadEventStart
• Redirection = fin de redirection - début de redirection
• DNS = domainLookupEnd - domainLookupStart
• TCP = connectEnd - connectStart
• SSL = connectEnd - secureConnectionStart
• Réponse = réponseFin - réponseDébut
• loadEvent = loadEventEnd - loadEventStart
• DCL = domContentLoadedEventStart - startTime
• WindowLoad = loadEventStart - startTime
• PageLoad = loadEventEnd - startTime
  De plus, afin de mieux refléter les performances de la page, les entrées suivantes sont également collectées et comptées :
• Les données complètes de PerformanceEntry sont collectées avec une faible probabilité (1 %). PerformanceEntry contient des données telles que LargegestContentfulPaint, LayoutShift, PerformanceEventTiming, PerformanceLongTaskTiming, PerformanceNavigationTiming, PerformancePaintTiming, PerformanceResourceTiming, PerformanceServerTiming, etc. Il inclut non seulement les indicateurs de performance de la page elle-même, mais couvre également les ressources, le réseau, le cache, les tâches JS à blocage long, les événements d'exécution lente et d'autres aspects de l'information. Il est utile d'évaluer les performances des pages et de déterminer les goulots d'étranglement des pages lentes. Étant donné que la plupart des pages ont beaucoup de contenu, le nombre de collections PerformanceEntry est trop important. Si 100 % est collecté et signalé, cela aura un impact important sur la bande passante, le stockage et les performances des requêtes, de sorte qu'il ne peut être collecté qu'avec un petite probabilité.
• Le type de navigation de page, qui prend la valeur de PerformanceNavigationTiming.type, détermine si la page est chargée pour la première fois ou actualisée et rechargée.
• Selon le type de ressources, des statistiques sont réalisées sur le nombre de ressources diverses, le volume total de transmission et la consommation totale de temps.
• Selon le nom de domaine, le nombre de ressources, le volume total de transmission et la consommation totale de temps de chaque nom de domaine sont comptés.
  
  Nous pouvons trouver des goulots d'étranglement de pages lentes,
  nous nous référons aux statistiques du site Lighthouse 50-point line et HTTP Archive, et formulons des normes de pages lentes selon le type d'application : PC ou M. Les seuils spécifiques sont les suivants : pour les pages lentes, nous
  
  collectons le PerformanceNavigationTiming mentionné dans la section précédente, En plus des données Web-Vitals, des données PerformanceEntry complètes et des données statistiques avec une faible probabilité, nous collecterons également :
• TOP N ressources lentes, méthode : prendre N
  PerformanceEntry de type PerformanceResourceTiming avec la plus grande valeur de durée.
• Les tâches longues font référence aux tâches qui occupent le thread d'interface utilisateur pendant plus de 50 millisecondes. Méthode : collectez toutes les PerformanceEntry de type PerformanceLongTaskTiming. Cependant, la plupart des navigateurs ne peuvent actuellement pas fournir l'adresse du script (containerSrc) et le nom de la méthode (containerName) où se trouve la tâche longue. La collecte de cette partie des données ne peut que déterminer si la tâche longue s'est produite ? le nombre d'occurrences. Le contenu de PerformanceLongTaskTiming est le suivant :
  
• Les événements lents font référence aux événements interactifs dont le temps de traitement dépasse 104 ms. Méthode : collectez toutes les PerformanceEntry de type PerformanceEventTiming.
• Le nombre de sauts de page, la valeur est : PerformanceNavigationTiming.redirectCount, qui peut aider à analyser la raison pour laquelle la phase de redirection prend beaucoup de temps.
• Enregistre l'élément associé lorsque les valeurs CLS et LCP sont supérieures au seuil de page lente.
  N'affecte pas les performances de la page
  RUM doit être implémenté en envahissant la page et en introduisant JS SDK dans la page, ce qui affectera inévitablement les performances de la page. En tant qu'outil de découverte et d'analyse des performances des pages, il ne devrait pas aggraver les problèmes de performances des pages. Afin de minimiser l'impact sur les performances, nous avons fait deux choses :
• Chargement asynchrone du SDK JS : la page n'importe qu'un fichier d'en-tête JS de petite taille et à fonction unique, et une fois que la page atteint l'événement DomContentLoaded, charge de manière asynchrone le fichier principal JS complet sous la forme d'un script dynamique.
• Réduisez l'utilisation de la bande passante :
  • Rapport d'échantillonnage : les pages lentes doivent être signalées, les pages non lentes sont échantillonnées et signalées, le taux de tabagisme par défaut est de 30 %, réduisez le nombre de rapports.
  • Réduisez le volume de données signalées : la quantité totale de données PerformanceEntry peut pleinement refléter les performances de la page. De nombreuses pages dépassent souvent les données performanceEntry de la barre blanche, et le volume est trop important, de sorte que la quantité totale de données PerformanceEntry ne peut que être collecté avec une faible probabilité, et les statistiques de PerformanceEntry peuvent être calculées et collectées.

Pour résumer, nous collectons deux grandes catégories d'indicateurs : PerformanceEntry et web-vitals.
Comment évaluer les performances hors page d'accueil des applications SPA ?
En collectant les indicateurs ci-dessus, nous pouvons évaluer de manière objective et complète les performances de la page standard et de la page d'accueil de l'application SPA. Cependant, la non-page d'accueil de l'application SPA n'est pas une norme de navigateur. Pendant le processus de commutation de routage SPA :

Le navigateur n'exécutera que la méthode History.replaceState(), il ne régénérera pas et ne doit pas régénérer les données PerformanceNavigationTiming.
La plupart des données PerformanceEntry contiennent les indicateurs de performance de toutes les pages de commutation de routage depuis la première page du SPA. En prenant PerformanceResourceTiming comme exemple, il est impossible d'obtenir le temps de commutation de route réel via la méthode History.replaceState() et d'exclure les données historiques de la collection PerformanceResourceTiming pour obtenir les données PerformanceResourceTiming de la route actuelle. Étant donné que la plupart des frameworks frontaux exécutent d'abord leur logique interne, puis déclenchent la méthode History.replaceState() pendant le processus de changement de route SPA, l'heure de déclenchement de la méthode History.replaceState() est donc postérieure à l'heure d'exécution de le changement d'itinéraire.
web-vitals ne prend pas en charge la collecte d'indicateurs de performance après le changement d'itinéraire SPA hors page d'accueil pour le moment.
Par conséquent, il est impossible ou impossible d'obtenir avec précision les indicateurs ci-dessus pour SPA hors page d'accueil, nous n'évaluons donc pas les performances de SPA hors page d'accueil pour le moment.

Visant la difficulté d'évaluer les performances de SPA hors page d'accueil dans l'industrie, Byte WebPro a introduit de manière créative le concept de SPA_LOAD. La logique de base est la suivante : en commençant par déclencher la méthode history.replaceState(), en surveillant les changements de dom, le chargement des ressources, envoi de requêtes et autres événements de modification via MutationObserver Pour trouver le temps nécessaire à une page pour atteindre un état stable en tant que point final, et mesurer les performances de la page non-accueil SPA en calculant le temps entre les points de début et de fin. SPA_LOAD est similaire à l'événement normal de chargement de page, mais l'heure de début est postérieure à l'heure de changement de route réelle, et la page peut avoir été chargée à l'heure de fin, ce qui est légèrement insuffisant, mais c'est actuellement la meilleure solution, et nous pourra le présenter plus tard.

Temps de collecte des indicateurs

Ce n'est qu'en collectant des valeurs d'index réelles et précises que nous pouvons vraiment refléter les performances de la page, sinon cela pourrait induire les étudiants en erreur dans la production et la recherche et évaluer à tort les performances réelles de la page. Par conséquent, il existe plusieurs principes pour choisir le moment de la collecte des indicateurs :

• En référencement aux normes, le plus important est de s'assurer que les indicateurs sont exacts, et il vaut mieux ne pas les utiliser s'ils ne sont pas autorisés.
• Il existe de nombreux échantillons et des rapports fiables. Pour certains indicateurs, tels que CLS, INP, PerformanceEventTiming,
  etc., plus la valeur collectée est tardive, plus la valeur est précise, mais plus la collecte est tardive, moins il reste de temps pour le reporting, et plus la probabilité d'échec de la déclaration des données est grande, afin de collecter autant de données que possible. Pour les échantillons, nous ne pouvons pas attendre que la page soit fermée pour collecter des indicateurs et soumettre des rapports.
• Pour être juste, certains indicateurs, tels que CLS, INP, LCP,
  etc., peuvent augmenter en valeur à mesure que la page est ouverte plus longtemps. Pour de tels indicateurs, nous ne pouvons que choisir un temps de collecte relativement raisonnable et équitable pour "tous les projets" sous réserve de garantir que les données disposent de "grands échantillons".
• Un rapport, certains indicateurs dans les web-vitals
  tels que : LCP, CLS, INP, chaque changement déclenchera sa fonction de rappel, Google recommande officiellement de collecter et de signaler chaque changement de valeur d'indicateur. Ce type de logique de traitement, la valeur d'index est plus précise, mais elle prend trop de connexion frontale, de bande passante et de
  ressources CPU, et augmente également considérablement la difficulté de traitement du programme de réception back-end, ce qui n'est pas raisonnable et choix équilibré. Par conséquent, nous devons trouver une opportunité de collecte appropriée, collecter et rapporter tous les indicateurs de performance en même temps.

Alors, comment déterminer le temps de collecte? Nous devons analyser le temps de génération exact de deux types de données d'indicateurs, PerformanceEntry et web-vitals :

Pour les données PerformanceEntry, lorsque l'événement onload est déclenché, la page est presque chargée et la plupart des données d'indicateur dans PerformanceEntry qui affectent le chargement du premier écran ont été générées. Les données non générées ont peu d'impact sur l'évaluation des performances de la page, comme la valeur de l'indicateur loadEventEnd dans PerformanceNavigationTiming. Nous pensons donc que lorsque l'événement onload est déclenché, l'indicateur PerformanceEntry peut être collecté.
Les principes de génération des indicateurs dans les web-vitals sont différents.Lorsque l'événement onload est déclenché :

• Les indicateurs TTFB et FCP ont été générés et ne changeront pas, et peuvent être collectés.
• Le plus grand élément correspondant au LCP a été chargé avec une probabilité élevée, nous pensons donc que la valeur LCP est très probablement exacte à ce moment et peut être collectée.
• La précision de la valeur CLS ne peut pas être déterminée. La logique de calcul est la suivante : toutes les 5 s après l'ouverture de la page est utilisée comme fenêtre de session, et la valeur de décalage générée dans cette fenêtre est cumulée pour devenir la valeur CLS. Si la valeur CLS de la fenêtre de session suivante est supérieure à celle de la fenêtre de session précédente
  , puis remplacez. Par conséquent, pour les indicateurs CLS,
  il est plus approprié de collecter 5S après l'ouverture de la page, de préférence 5S ou son multiple entier, et il est plus équitable pour "tous les projets".
• La précision du FID et de l'INP ne peut pas être déterminée. Ils ne sont générés qu'après les opérations d'interaction de l'utilisateur. Les opérations d'interaction incluent : clic, saisie, glisser-déposer, toucher et autres événements. FID
  est le temps de retard de la première interaction, et INP prend la valeur avec le plus grand temps de retard parmi plusieurs opérations interactives. Ces deux indicateurs dépendent des opérations de l'utilisateur, et INP
  peut augmenter en valeur à mesure que le nombre d'opérations de l'utilisateur augmente, il est donc impossible de garantir une acquisition précise de ces deux indicateurs à tout moment.

Sur la base des considérations ci-dessus, nous pensons qu'au moins une des conditions de déclenchement de l'événement onload ou d'ouverture de la page 5 peut être garantie pour garantir l'exactitude de PerformanceEntry ou de certains indicateurs Web Vitals, et la collecte est significative. Selon le principe de la poursuite de "plusieurs échantillons", combiné à la situation réelle dans laquelle le SDK RUM est chargé de manière asynchrone après l'événement onload, nous avons défini un total de trois délais de collecte en fonction de la fermeture normale de la page. Les caractéristiques sont les suivantes : Afin d'éviter l'impact des


indicateurs de collecte sur les performances de la page, nous chargeons le SDK RUM JS de manière asynchrone. Les indicateurs dans web-vitals ne prennent en charge que le rappel asynchrone par défaut. Le chargement asynchrone puis le rappel asynchrone peuvent toujours échouer à obtenir la valeur de chacun indicateur au moment de la collecte, nous avons donc effectué une transformation pour prendre en charge l'acquisition synchrone de chaque valeur d'indicateur.

Méthode de déclaration

Après avoir collecté les indicateurs, vous devez choisir une méthode de rapport appropriée pour envoyer de manière fiable les indicateurs au backend. La méthode de notification comprend deux parties : le mécanisme de notification et le calendrier de notification.

Pour choisir un mécanisme de rapport approprié, tout d'abord, il doit répondre aux exigences fonctionnelles, avoir une compatibilité de navigateur élevée et, de préférence, n'avoir aucune limite sur la taille des données ; deuxièmement, être capable de détecter les demandes de rapport anormales, de faciliter les nouvelles tentatives de rapport et d'améliorer le rapport la fiabilité ; enfin, le Support client fixant le délai d'attente pour éviter l'occupation à long terme et l'oubli de connexion, augmentant la pression sur les services back-end. Il existe quatre mécanismes de rapport courants, à savoir : Image, XMLHttpRequest, sendBeacon et Fetch API. Ses caractéristiques sont les suivantes :

	Image	XMLHttpRequest	envoyerBeacon	Aller chercher
Fondamental	Créez un DOM img masqué de 1 pixel et incluez l'adresse de rapport et le contenu dans le src de l'img. Si le rapport réussit, un code d'état 200 est renvoyé	Utiliser l'objet intégré au navigateur XMLHttpRequest pour rapporter les données	Utilisez la méthode navigator.sendBeacon() spécialement conçue pour envoyer des données d'analyse pour soumettre des données d'analyse au backend en envoyant des requêtes HTTP POST de manière asynchrone	fetch est une API moderne basée sur Promise pour envoyer des requêtes HTTP
compatibilité du navigateur	haut	haut	, ne prend pas en charge Internet Explorer	Modérément faible, ne prend pas en charge IE
limite de taille des données	Moins de 8K La limite de taille de chaque navigateur est différente, et elle est soumise au CDN, au proxy back-end et au serveur Web. La valeur par défaut est généralement de 8K. 8K fait référence à la longueur encodée par URI	Demande avec POST, illimité	Oui, certains navigateurs font moins de 64K	Demande avec POST, illimité
Anomalie de rapport perçue	Partiellement pris en charge. L'événement img onerror sera déclenché lorsque la requête renvoie un code d'état de 404 ou 204. Si le code d'état est supérieur ou égal à 400, l'événement onerror ne sera pas déclenché, tel que 400, 500, 502 et 504.	soutien	pas de support. La valeur de retour de sendBeacon() peut uniquement indiquer si le navigateur envoie une requête	soutien
le délai d'attente peut être défini	Non, cela dépend des paramètres du serveur	Peut	Ne peut pas	Peut
avantage	Facile à utiliser et haute compatibilité	Puissant, flexible et facile à étendre ; pas de limite de taille, haute compatibilité	Facile à utiliser, haute fiabilité ; lorsque la page est fermée, elle peut toujours être envoyée	Comparé à XMLHttpRequest, il est plus simple à utiliser et plus puissant
défaut	La taille des données est limitée et il est difficile de percevoir et de signaler les exceptions	L'écriture de code est un peu compliquée, alors faites attention au traitement inter-domaines	Incapable de percevoir et de signaler les exceptions, la valeur de retour de la fonction true, false ne peut que représenter si l'envoi est réussi	Compatibilité de navigateur la plus faible avec XMLHttpRequest
Scène applicable	Les données rapportées sont petites et les exigences de fiabilité ne sont pas élevées	Les exigences fonctionnelles sont nombreuses, il est recommandé de signaler au format text/plain ou application/x-www-form-urlencoded par POST, CORS pré-authentification	Besoin de rapporter des données lorsque la page est fermée	Identique à XMLHttpRequest, plus adapté aux terminaux avec une distribution de navigateur plus récente

La conclusion ci-dessus : dépend de chrome114

Par rapport à Fetch, XMLHttpRequest a presque la même fonction et une compatibilité plus élevée ; par rapport à Image, XMLHttpRequest présente les avantages d'une compatibilité élevée, d'une taille de données illimitée, de la capacité de percevoir les exceptions et d'un délai d'expiration pouvant être défini ; XMLHttpRequest est un processus normal (non fermé) page Ensuite, le mécanisme de rapport préféré pour l'envoi de données métriques. En ce qui concerne sendBeacon, bien qu'il existe de nombreuses lacunes, les données peuvent toujours être signalées lorsque la page est fermée et le taux de réussite est relativement élevé. Il convient comme mécanisme de rapport pour envoyer des données d'indicateur non envoyées lorsque la page est fermée.

Maintenant que sendBeacon est sélectionné comme mécanisme de rapport pour envoyer des données d'indicateur lorsque la page est fermée, comment juger que la page est fermée ? La solution traditionnelle consiste à écouter l'événement unload ou beforeunload, qui présente deux défauts :

Les exigences fonctionnelles ne peuvent pas être satisfaites. Lorsque les utilisateurs de téléphones mobiles quittent la page, ils sont plus habitués à masquer le navigateur au lieu de le fermer. Lorsque la page est masquée, les événements unload et beforeunload ne sont pas déclenchés.
Les performances en souffrent. Certains navigateurs ne peuvent pas utiliser bfcache après avoir écouté les événements de déchargement ou avant déchargement, ce qui réduit les performances de la page.
Une solution plus adaptée et moderne consiste à écouter les événements pagehide ou visibilitechange===hiden.Cette solution évite les deux défauts des solutions traditionnelles et a un degré de compatibilité plus élevé. Pour les projets SPA, nous ne collectons pas d'indicateurs de performance hors page d'accueil, et le déclenchement de la méthode History.replaceState() est également compté comme une sortie de page.

Pour résumer, le mécanisme global de création de rapports est le suivant : 1) La page est normale (non fermée) et, au moment de la collecte, le SDK collecte les données de l'indice de performance et les signale à l'aide du mécanisme XMLHttpRequest ; 2) En écoutant l'événement pagehide ou visibilitechange===hiden, lorsque la page Lorsqu'elle est désactivée, si une condition de minutage de collecte est remplie, les indicateurs seront collectés immédiatement et signalés à l'aide du mécanisme sendBeacon.

Programme global

En résumé, nous organisons le schéma de mise en œuvre du RUM comme suit :

Dans le processus de codage proprement dit, le flux de traitement spécifique est le suivant :

Avantages et inconvénients

Au cours du processus de mise en œuvre, nous avons résumé les avantages et les inconvénients de RUM comme suit :

La conception de l'architecture RUM est complexe et le coût de mise en œuvre est relativement élevé.En raison des besoins techniques rigides, nous ne pouvons qu'investir des ressources et travailler dur pour bien le faire.

Pour les défauts d'absence de résultats de diagnostic et de suggestions d'optimisation, vous pouvez utiliser SYN pour apprendre les uns des autres et utiliser SYN pour diagnostiquer la distribution des goulots d'étranglement des performances des pages lentes.

Pour le problème qu'il n'y a pas de score et qu'il est impossible de juger de la performance de la page, nous procéderons en trois étapes : d'abord, formuler un standard de page lente pour juger si une seule page est rapide ou lente, et la valeur standard a été décrit ci-dessus ; deuxièmement, comptez les indicateurs importants des valeurs AVG, TP50, TP90, TP99 de la page, évaluez de manière exhaustive la distribution des performances de toutes les requêtes sur la page ; enfin, nous noterons l'application où se trouve la page et dirons directement les étudiants en recherche et développement, la performance de l'application est bonne ou mauvaise, et la méthode spécifique de notation de l'application sera décrite dans le chapitre suivant "Établir un système de notation" expliqué en détail.

3 conception globale de l'architecture

L'article précédent a analysé en profondeur les caractéristiques respectives, les méthodes d'utilisation, les avantages et les inconvénients de SYN et RUM. Nous avons constaté que SYN et RUM ont leurs propres avantages et ne peuvent pas être remplacés. La chaîne d'outils d'analyse aide les étudiants en production et en recherche à découvrir et à localiser les performances des pages. problèmes à chaque étape de devpos.

Dans les étapes de codage, de construction et de test, les étudiants en R&D peuvent utiliser SYN pour effectuer des tests de performances de page afin de déterminer si les performances de la page sont conformes aux normes ? S'il y a un problème avec les performances de la page, utilisez SYN pour diagnostiquer les problèmes de performances et obtenir des suggestions d'optimisation. Cette décision résout les problèmes de longue date de la page d'accueil, tels que la difficulté des tests de performance sur la page d'accueil et la qualité non standard de la page livrée. Une fois l'application déployée, utilisez RUM pour collecter les performances réelles des pages utilisateur et évaluer les performances réelles des pages. Si des pages lentes existent toujours, vous pouvez toujours utiliser SYN pour localiser les goulots d'étranglement des performances des pages lentes et utiliser les résultats de diagnostic et les suggestions d'optimisation pour améliorer l'efficacité de l'optimisation. En outre, SYN peut également être utilisé pour comparer des produits concurrents afin d'atteindre l'objectif de vous connaître et de connaître l'ennemi, et d'avoir une longueur d'avance sur les concurrents.

Avec SYN et RUM, nous pouvons construire une boucle fermée pour optimiser en continu les pages lentes en ligne, comme le montre la figure ci-dessus. RUM est responsable de la collecte des pages lentes générées par de vrais utilisateurs. Après stockage et agrégation en arrière-plan, il crée automatiquement un SYN JOB pour les pages lentes de TOPN. Une fois le travail terminé, il informe les étudiants en recherche et développement des résultats du diagnostic et de l'optimisation. suggestions comme alarme. Les étudiants R&D utilisent les suggestions d'optimisation SYN, puis utilisent devtools, webpack et d'autres outils pour améliorer la page, fournir des pages de haute qualité et réduire la fréquence des pages lentes. Ce cycle itère en continu pour optimiser les performances de la page d'application, et enfin l'application peut atteindre les performances ultimes.

4 Établir un système de jugement

En présentant SYN, le SDK RUM auto-développé, et après avoir collecté de nombreuses données d'indicateurs SYN et RUM, nous allons commencer à établir un système d'évaluation pour évaluer les performances de chaque application, équipe, département et même de l'ensemble de l'entreprise, et produire quelques clés des indicateurs et des scores, qui sont intuitifs Informer les employés à tous les niveaux et rôles des performances des pages de leurs organisations et organisations au même niveau, et juger s'il convient d'optimiser les performances des pages en comparant les scores avec leurs pairs ?

Lors de l'établissement du système d'évaluation, nous adhérons au principe non seulement de mettre en évidence les points clés et les indicateurs clés, mais également de refléter de manière exhaustive, exhaustive, objective et fidèle les performances de la page. Par conséquent, nous divisons le système de jugement en deux parties, dont l'une montre les indicateurs de performance les plus critiques. Deuxièmement, générez les scores de performance et les niveaux de chaque indicateur, application, équipe, département et niveau de l'entreprise.

Afficher les indicateurs de performance les plus critiques

Nous sélectionnons un indicateur qui représente le mieux la performance de la page à partir de web-vitals et performanceNavigationTiming, respectivement : DCL et LCP. LCP n'est pas hautement compatible et peut être falsifié. DCL peut remplacer LCP pour refléter partiellement les performances du premier écran et a une compatibilité élevée et est difficile à falsifier. Il complète LCP et peut mieux refléter les performances de la page.

TP90 représente la limite inférieure de l'expérience utilisateur pour 90 % des utilisateurs. Par rapport à AVG, TP50 et TP75, il couvre et compte un plus large éventail d'utilisateurs, et il peut également bloquer une petite quantité de données sales générées par la page sous le environnement réseau spécial du téléphone mobile, qui est plus représentatif.

Notes de sortie à tous les niveaux

Notation des performances des applications
Afin d'évaluer de manière exhaustive, complète et objective les performances des pages d'application. Nous allons sélectionner des indicateurs représentatifs de chaque dimension, nous référer à la répartition des indicateurs dans l'industrie donnée par HTTP Archive, et mettre en place différents Calculer le score de chaque indicateur. Définissez ensuite le poids en fonction de l'importance de chaque indicateur et obtenez le score de performance de l'application grâce à l'algorithme de moyenne pondérée. Le processus est le suivant :

Le processus d'obtention des scores de performance des applications implique plusieurs processus importants : 1) sélection des indicateurs et établissement des pondérations ; 2) sélection des algorithmes de notation ; 3) établissement de références d'indicateurs ; 4) calcul des scores de performances des applications à l'aide d'algorithmes de moyenne pondérée. Les éléments suivants sont introduits un par un.

Sélection de l'indice et établissement du poids
Dans ce processus, je considère principalement deux points :

Considération globale. La performance des pages couvre de nombreux aspects, traditionnellement, elle n'est mesurée que par quelques indicateurs tels que le premier octet, l'écran blanc et le temps de premier écran, ce qui est relativement unilatéral et pas assez objectif. Nous pensons que l'évaluation des performances des pages doit couvrir des indicateurs de différentes dimensions, tels que : le chargement de la page, l'expérience interactive et l'expérience visuelle. En outre, nous introduisons également le concept de ratio API lent. Le ratio de requêtes API fait référence au ratio de requêtes API qui prennent plus de 3 secondes après l'ouverture de la page. Une API lente peut affecter le temps de chargement du premier écran et l'expérience utilisateur pendant le processus d'interaction. Afin de permettre aux étudiants R&D de prêter attention aux pages lentes et d'utiliser SYN en ligne comme outil d'évaluation des performances de développement quotidien, nous utilisons également le score SYN comme indice de pondération. Le système d'arrière-plan comptera les pages lentes avec le nombre de visites TOP10 chaque jour et créer automatiquement une tâche chronométrée SYN Attendre que la tâche soit exécutée et analysée Une fois terminée, les suggestions d'optimisation et les résultats du diagnostic seront notifiés aux étudiants R&D. Éléments de notation SYN, y compris les points de performance et les points de meilleures pratiques, tous deux basés sur un système de 100 points.

Mettez en évidence les points clés. Augmentez le rapport de poids des indicateurs importants. Par exemple, l'indicateur de chargement est utilisé pour mesurer si la page peut être utilisée, et c'est le plus critique, donc on lui attribue le poids le plus important. Le LCP est l'indicateur de charge le plus important et le rapport de poids est également augmenté en conséquence. Étant donné que LCP lui-même n'est pas nécessairement tout à fait raisonnable et peut être falsifié, des indicateurs de charge tels que DCL, FCP, TTFB, WindwLoad et PageLoad sont également introduits lors de l'évaluation des performances de chargement des pages. Avantages de cette méthode : nombreux indicateurs, dimensions larges, angles larges, plus complets et plus objectifs et précis ; inconvénients : augmentation de la complexité et de la difficulté du système d'évaluation.

Sur la base des deux considérations ci-dessus, nous définissons les résultats de la sélection de l'indice et les paramètres du rapport de pondération, comme indiqué dans la figure ci-dessous :

chaque indice participe au calcul de la notation en fonction de sa valeur statistique TP90.

Sélection de l'algorithme de notation L'
algorithme de notation fait principalement référence au modèle de courbe de notation Lighthouse.Le principe de base est : définir deux points de contrôle, généralement TP50 et TP90, c'est-à-dire les points de valeur de l'indice lorsque 50 ou 90 points sont obtenus, puis générer un paire de points basée sur ces deux points de contrôle La courbe numérique normale, à travers laquelle le score correspondant à n'importe quelle valeur d'indice peut être obtenu. La figure suivante est la courbe de notation du LCP M-terminal :

m représente la médiane et la valeur de m dans la figure est de 4 000 ms, ce qui signifie que lorsque la valeur LCP est de 4 000 ms, 50 points sont attribués ; de même, lorsque p10 est de 2 520 ms et que la valeur LCP est de 2 529 ms, 90 points sont obtenus. Après avoir défini m et p10, le modèle de courbe de notation sur la droite sera généré, selon lequel le score lorsque la valeur LCP est de 0 à l'infini positif peut être obtenu.

Établissement de la ligne de base métrique
L'objectif de l'établissement de la ligne de base métrique est de fournir à l'algorithme de notation deux points de contrôle, les valeurs de m et p10. Il existe trois façons d'établir :

• Empruntez directement la configuration Lighthouse. Prenez les seuils de 50 points et 90 points des indicateurs correspondants de Lighthouse en tant que valeurs de points de contrôle m et p10, comme les
  indicateurs dans Web-Vitals.
• Reportez-vous aux données statistiques HTTP Archive et utilisez les valeurs p10 et p75 dans les données statistiques comme valeurs de point de contrôle m et p10. Tels que
  les indicateurs de performanceNavigationTiming.
• Construisez votre propre ligne de base. Un petit nombre d'indicateurs de référence ne peuvent pas être établis à partir des deux méthodes ci-dessus et ne peuvent être construits que par soi-même. Méthode spécifique : prenez les données obtenues par le système de fond actuel comme échantillon et utilisez les valeurs tp75 et tp95 de l'échantillon comme valeurs de
  point de contrôle m et p10. S'applique aux métriques d'échelle d'API lentes.

Lors du processus d'établissement de la ligne de base, la différence entre la valeur de l'application et les exigences de R&D doit être prise en compte, et des réglages ciblés doivent être effectués en fonction des caractéristiques de l'application. Tout d'abord, les applications côté PC et côté M doivent définir des lignes de base d'index différentes. Heureusement, Lighthouse et HTTP Archive fournissent des références de configuration pour le côté PC et le côté M. Les applications côté C et côté B génèrent directement de la valeur métier et leurs exigences de performances sont supérieures à celles des applications internes, de sorte que les valeurs des deux points de contrôle doivent être inférieures.

Utilisez l'algorithme de moyenne pondérée pour calculer le score de performance de l'application.
Selon la valeur tp90 de l'indicateur, la ligne de base de l'indicateur et l'algorithme de notation, le score en centile de l'indicateur est obtenu.
Utilisez l'algorithme de moyenne pondérée pour calculer le score de performance de l'application, et le résultat = (Σ (valeur de l'index tp90 × poids de l'index)) / (Σ poids), où : Σ signifie sommation.

Scores de l'organisation à tous les niveaux
En ce qui concerne les scores de performance des organisations à tous les niveaux, y compris les équipes, les départements et les entreprises, l'algorithme de moyenne pondérée est toujours utilisé pour obtenir les scores de l'organisation en fonction du nombre d'applications sous sa juridiction, les scores de performance des applications et poids des applications. Le processus est le suivant :

La difficulté pour obtenir le score de performance organisationnelle est : comment fixer le poids de la candidature ? Nous nous référons principalement à l'intervalle PV et au niveau d'application de l'application. Plus le niveau PV est élevé et plus le niveau d'application est élevé, plus le poids est élevé. La référence de configuration spécifique est la suivante :

La valeur PV dans l'intervalle PV fait référence à la PV, et non à la PV réelle, et la PV = volume de données RUM collectées/taux d'échantillonnage.
Après les étapes ci-dessus, nous pouvons obtenir des scores de performance d'application, ainsi que des scores de performance d'organisations à tous les niveaux, tels que des scores de performance d'équipe, des scores de performance de département et des scores de performance à domicile Un score supérieur est considéré comme excellent

.

5 résumé

Grâce à la construction du système de suivi et d'évaluation des performances de la page, nous avons non seulement les données de performance de la page d'origine, mais également des valeurs statistiques agrégées, ainsi que le score final. Grâce à la notation, aux statistiques et aux données brutes, le lien de découverte, de localisation et d'analyse des problèmes de performance est ouvert. Les étudiants en R&D peuvent juger intuitivement si les performances de l'application doivent être optimisées grâce à la notation. Si une optimisation est nécessaire, analysez les goulots d'étranglement des applications en agrégeant des données statistiques ; lorsque vous localisez des goulots d'étranglement spécifiques, vous pouvez afficher des données détaillées pour vous aider à analyser les causes spécifiques des goulots d'étranglement ; après l'amélioration, vous pouvez vérifier l'effet d'optimisation à l'aide de statistiques et enfin refléter l'amélioration score supérieur.

En raison du manque d'espace, cet article ne peut présenter que des pratiques liées à la construction d'un système de surveillance et d'évaluation des performances des pages. Un système complet de surveillance des performances des pages doit également inclure : la surveillance, l'alarme, l'optimisation, la gouvernance et d'autres modules, pas seulement des indicateurs, mais peuvent mesurer les performances des pages, trouver les goulots d'étranglement des performances, aider les étudiants en R&D à améliorer l'efficacité de l'optimisation et remédier à la cause première, grâce à Build une série de chaînes d'outils frontaux, améliorer le processus de livraison, améliorer la qualité de la livraison des pages à partir de la source grâce à des spécifications, des outils et des processus, éviter de mettre les problèmes en ligne et découvrir les problèmes de performances avant les utilisateurs.
Références
vitals-spa-faq
Web Vital Metrics for Single Page Applications
Beaconing In Practice
HTTP Archive
est un projet de collecte et d'analyse des données de performances des sites Web, visant à aider les développeurs Web à comprendre les tendances de la technologie Internet et les meilleures pratiques d'optimisation des performances.