Core/Dash Comprendre les tableaux de bord de répartition des métriques

Comprendre le tableau de bord de répartition des métriques

Les métriques composites comme LCP et INP agrègent plusieurs événements temporels distincts. L'optimisation du score total nécessite d'isoler ces composants sous-jacents. Le tableau de bord de répartition des métriques dissèque la performance en phases granulaires pour identifier le goulot d'étranglement spécifique.

Cet outil remplace l'optimisation globale par des cibles d'ingénierie précises. Il attribue la latence au serveur, au réseau ou à l'exécution client.

Anatomie du tableau de bord de répartition

Le tableau de bord fournit trois vues synchronisées pour isoler la cause profonde de la latence :

• Anneau de contribution : Visualise le poids relatif de chaque sous-partie. Il répond à la question "Quel est le facteur le plus important ?" Si le `Time to First Byte` occupe 70 % du graphique, vous savez que le problème est lié au backend.
• Chronologie historique : Indique la tendance des valeurs absolues de chaque composant au fil du temps. Utilisez ceci pour corréler les variations de performance avec des événements spécifiques comme les déploiements.
• Tableau de données segmentées : Répartit la métrique par dimension (URL, appareil, etc.). Chaque ligne inclut une barre de distribution qui révèle le profil unique de ce segment, vous aidant à repérer les valeurs aberrantes.

Composants du LCP (Largest Contentful Paint)

LCP mesure les performances de chargement. Nous divisons cette métrique en quatre phases :

• TTFB (Time to First Byte) : Le temps de réponse du serveur. Un TTFB élevé indique des requêtes de base de données lentes ou un manque de mise en cache à la périphérie.
• Load Delay : L'écart entre la réponse HTML initiale et le début du téléchargement de la ressource du LCP. Cela mesure la latence de découverte de la ressource.
• Load Time : La durée nécessaire pour télécharger la ressource du LCP (image ou police) sur le réseau. Cela est corrélé à la taille du fichier et à la bande passante.
• Render Delay : Le temps entre la fin du téléchargement de la ressource et l'affichage à l'écran. Un Render Delay élevé indique souvent un blocage du thread principal par JavaScript.

Composants du TTFB (Time to First Byte)

TTFB sert de proxy pour la réactivité du serveur. Cette répartition isole les phases de connexion réseau :

• Attente : Le temps passé par le navigateur à attendre que le serveur génère une réponse (traitement backend).
• Cache : Temps passé à vérifier les caches locaux ou intermédiaires.
• DNS : La durée de la recherche du système de noms de domaine.
• Connexion : Temps mis pour établir la connexion TCP.
• Requête : Temps pris pour envoyer les en-têtes de la requête HTTP.

Composants de l'INP (Interaction to Next Paint)

INP mesure l'interactivité. Nous segmentons le cycle de vie de l'interaction pour identifier précisément le blocage du thread principal :

• Input Delay : Le temps entre l'interaction de l'utilisateur et l'exécution du gestionnaire d'événements. Un Input Delay élevé signifie que le thread principal était occupé.
• Processing : Le temps mis pour exécuter les rappels d'événements. Cela représente l'efficacité de votre logique JavaScript.
• Presentation : Le temps pris par le navigateur pour calculer la mise en page et afficher l'image suivante.

Flux de diagnostic

Suivez cette séquence pour diagnostiquer une régression :

• Quantifier le goulot d'étranglement : Regardez le graphique en anneau pour trouver la sous-partie dominante. Si le `TTFB` est élevé, vérifiez votre serveur. Si le `Resource Load Delay` est élevé, vérifiez la priorité de vos ressources.
• Établir la causalité : Vérifiez la chronologie pour corréler le pic avec un déploiement spécifique ou une mise à jour de contenu.
• Isoler le contexte : Utilisez le tableau de données pour voir si ce modèle se vérifie sur toutes les pages ou s'il est spécifique à un certain modèle. Trouver le modèle est la clé pour déployer un correctif évolutif.

Optimisation des Core Web Vitals

Utilisez ces répartitions pour diriger les tickets vers la bonne équipe d'ingénierie. Attribuez les problèmes de TTFB au Backend. Attribuez le Load Delay et le Render Delay au Frontend. Attribuez la latence DNS/Connexion à l'Infrastructure. Ce processus de tri rationalisé réduit le temps d'investigation et accélère la résolution.