Métriques Personnalisées du Performance Observer Frontend : Mesure Spécifique à l'Application

Dans le monde du développement web, garantir une performance frontend optimale est primordial. Bien que les navigateurs offrent une gamme de métriques de performance, elles sont souvent insuffisantes lorsqu'il s'agit de capturer le comportement spécifique à une application. C'est là que l'API Frontend Performance Observer et la capacité de définir des métriques personnalisées deviennent inestimables. Cet article vous guidera à travers le processus d'exploitation du Performance Observer pour suivre des métriques sur mesure, offrant une vue personnalisée du paysage de la performance de votre application.

Comprendre le Besoin de Métriques Personnalisées

Les métriques de performance standard des navigateurs, telles que le First Contentful Paint (FCP), le Largest Contentful Paint (LCP) et le Time to Interactive (TTI), offrent un aperçu général du chargement de la page et de sa réactivité. Cependant, ces métriques ne reflètent souvent pas avec précision l'expérience utilisateur au sein de votre application spécifique. Considérez ces scénarios :

• Application e-commerce : Le temps nécessaire pour ajouter un article au panier ou finaliser un processus de paiement.
• Plateforme de médias sociaux : La latence du chargement des flux d'utilisateurs ou de la publication de mises à jour.
• Tableau de bord financier : Le temps requis pour calculer et afficher des données financières complexes.
• Application de cartographie : Le délai de chargement des tuiles de carte ou de rendu des données géographiques.

Ces actions spécifiques à l'application sont essentielles à l'expérience utilisateur mais ne sont pas directement capturées par les métriques de performance standard. Les métriques personnalisées comblent cette lacune, vous permettant de surveiller la performance des fonctionnalités critiques et d'acquérir une compréhension plus approfondie du comportement des utilisateurs.

Introduction à l'API Performance Observer

L'API Performance Observer fournit un mécanisme pour observer et collecter les métriques de performance au fur et à mesure qu'elles se produisent dans le navigateur. Elle vous permet de vous abonner à des types d'entrées de performance spécifiques, tels que `paint`, `resource`, `navigation`, et, plus important encore, `measure` et `mark`. Cette approche événementielle vous permet de réagir aux événements de performance en temps réel et de collecter des données pour analyse.

Les composants principaux de l'API Performance Observer sont :

• Constructeur `PerformanceObserver` : Crée une nouvelle instance de PerformanceObserver.
• Méthode `observe()` : Spécifie les types d'entrées de performance à observer.
• Méthode `disconnect()` : Arrête l'écoute des entrées de performance par l'observateur.
• Méthode `takeRecords()` : Retourne toutes les entrées de performance qui ont été mises en mémoire tampon depuis le dernier appel.

Définir des Métriques Personnalisées avec `mark` et `measure`

Les API `mark` et `measure` sont fondamentales pour créer des métriques de performance personnalisées. Voici comment elles fonctionnent :

• `performance.mark(markName)` : Crée un marqueur horodaté dans la chronologie des performances du navigateur. Vous utilisez `mark` pour indiquer le début et la fin d'un événement spécifique que vous souhaitez mesurer.
• `performance.measure(measureName, startMark, endMark)` : Calcule la durée entre deux marqueurs et crée une entrée de performance de type `measure`. Le `measureName` est un identifiant unique pour votre métrique personnalisée.

Illustrons cela avec un exemple. Supposons que vous souhaitiez mesurer le temps nécessaire pour qu'un composant spécifique se rende après une interaction de l'utilisateur.

            
// Début de la mesure du processus de rendu
performance.mark('componentRenderStart');

// ... (Logique de rendu du composant ici) ...

// Fin de la mesure du processus de rendu
performance.mark('componentRenderEnd');

// Créer une mesure pour calculer la durée
performance.measure('componentRenderTime', 'componentRenderStart', 'componentRenderEnd');

            

              
                Copy
              
            
          

Implémenter un Performance Observer pour les Métriques Personnalisées

Maintenant, créons un Performance Observer pour écouter les entrées de type `measure` et traiter les données des métriques personnalisées.

            
const observer = new PerformanceObserver((list) => {
  list.getEntriesByType('measure').forEach((entry) => {
    console.log(`Métrique personnalisée : ${entry.name} - Durée : ${entry.duration}ms`);
    // Dans un scénario réel, vous enverriez ces données à votre plateforme d'analytique
    // Exemple :
    // trackCustomMetric(entry.name, entry.duration);
  });
});

observer.observe({ entryTypes: ['measure'] });

            

              
                Copy
              
            
          

Cet extrait de code crée un Performance Observer qui écoute les entrées `measure`. Lorsqu'une entrée `measure` est créée (via `performance.measure`), la fonction de rappel de l'observateur est exécutée. La fonction de rappel parcourt les entrées collectées, enregistre le nom de la métrique et sa durée dans la console et, idéalement, envoie les données à une plateforme d'analytique pour une analyse plus approfondie.

Exemples Pratiques : les Métriques Personnalisées en Action

Explorons plusieurs exemples pratiques de la manière dont vous pouvez utiliser des métriques personnalisées pour surveiller des aspects spécifiques de la performance de votre application.

1. Mesurer le Temps de Réponse des API

Le suivi du temps nécessaire pour recevoir les réponses de vos API backend est crucial pour identifier les goulots d'étranglement potentiels. Voici comment vous pouvez mesurer le temps de réponse d'une API :

            
async function fetchData() {
  performance.mark('apiCallStart');
  const response = await fetch('/api/data');
  performance.mark('apiCallEnd');
  performance.measure('apiResponseTime', 'apiCallStart', 'apiCallEnd');
  return response.json();
}

            

              
                Copy
              
            
          

Cet extrait de code mesure le temps nécessaire pour récupérer des données depuis le point de terminaison `/api/data`. La métrique `apiResponseTime` capture la durée totale de l'appel API, du début de la requête à la réception de la réponse.

2. Suivre le Temps de Chargement des Images

Les images sont souvent un facteur important dans la performance de chargement des pages. Mesurer le temps de chargement des images peut vous aider à identifier des images surdimensionnées ou des CDN lents.

            
const image = new Image();
image.onload = () => {
  performance.mark('imageLoadEnd');
  performance.measure('imageLoadTime', 'imageLoadStart', 'imageLoadEnd');
};
performance.mark('imageLoadStart');
image.src = 'https://example.com/image.jpg';

            

              
                Copy
              
            
          

Cet extrait de code mesure le temps nécessaire au chargement d'une image à partir de l'URL spécifiée. La métrique `imageLoadTime` capture la durée entre le début de la requête de l'image et la fin de son chargement.

3. Surveiller le Temps d'Exécution des Scripts Tiers

Les scripts tiers peuvent souvent avoir un impact significatif sur la performance frontend. Mesurer leur temps d'exécution peut vous aider à identifier les scripts problématiques et à optimiser leur chargement ou leur exécution.

            
// En supposant que le script tiers a une fonction globale appelée 'thirdPartyScript'

performance.mark('thirdPartyScriptStart');
thirdPartyScript();
performance.mark('thirdPartyScriptEnd');
performance.measure('thirdPartyScriptExecutionTime', 'thirdPartyScriptStart', 'thirdPartyScriptEnd');

            

              
                Copy
              
            
          

Cet extrait de code mesure le temps d'exécution d'un script tiers hypothétique. La métrique `thirdPartyScriptExecutionTime` capture la durée de l'exécution du script.

4. Mesurer le Time to Interactive (TTI) pour des Composants Spécifiques

Bien que le TTI soit une métrique standard, vous pouvez la personnaliser pour mesurer le temps nécessaire pour que des composants spécifiques deviennent interactifs. Cela vous permet d'identifier les composants qui contribuent le plus au TTI global.

            
// Après que votre composant est entièrement rendu et interactif
performance.mark('componentInteractive');
performance.measure('componentTTI', 'componentRenderStart', 'componentInteractive');

            

              
                Copy
              
            
          

Cet exemple suppose que `componentRenderStart` a été défini plus tôt. Il mesure le temps écoulé entre le début du rendu du composant et le moment où il est entièrement interactif.

Techniques Avancées et Considérations

Au-delà des bases, voici quelques techniques avancées et considérations pour utiliser efficacement le Performance Observer et les métriques personnalisées :

1. Utiliser l'API User Timing pour les Scénarios Complexes

Pour des scénarios plus complexes, vous pourriez avoir besoin de créer plusieurs marqueurs et mesures pour suivre différentes phases d'un événement. L'API User Timing offre un moyen flexible de gérer ces marqueurs et calculs.

2. Utiliser l'API Long Tasks

L'API Long Tasks peut aider à identifier les tâches qui bloquent le thread principal pendant des périodes prolongées, entraînant une mauvaise expérience utilisateur. Vous pouvez combiner cela avec des métriques personnalisées pour corréler les tâches longues avec des actions spécifiques de l'application.

3. Indicateur `buffered` et Observateurs à Chargement Tardif

Si vous initialisez votre Performance Observer après que certains événements de performance se soient déjà produits, vous pouvez utiliser l'indicateur `buffered` pour récupérer ces événements. Par exemple :

            
const observer = new PerformanceObserver((list) => { /* ... */ });
observer.observe({ entryTypes: ['measure'], buffered: true });

            

              
                Copy
              
            
          

4. Throttling et Debouncing

Dans les scénarios à haute fréquence, envisagez d'utiliser le throttling ou le debouncing pour votre collecte de métriques afin d'éviter une surcharge de performance. Par exemple, si vous suivez les mouvements de la souris, vous pourriez ne collecter des données que toutes les 100 ms.

5. Agrégation et Analyse des Données

Les données de performance brutes collectées par le Performance Observer doivent être agrégées et analysées pour fournir des informations significatives. Cela implique généralement d'envoyer les données à une plateforme d'analytique, telle que Google Analytics, New Relic, ou une solution développée sur mesure. Assurez-vous que votre plateforme d'analytique peut gérer les métriques personnalisées et fournir les capacités de reporting nécessaires.

6. Real User Monitoring (RUM)

Pour obtenir une image fidèle de la performance de votre application, mettez en œuvre le Real User Monitoring (RUM). Le RUM collecte des données de performance auprès d'utilisateurs réels dans des conditions réelles, fournissant des informations précieuses sur la façon dont votre application se comporte pour différents utilisateurs et appareils. Les métriques personnalisées sont une partie essentielle d'une stratégie RUM complète.

7. Considérations de Sécurité

Soyez attentif à la sécurité lors de la collecte et de la transmission des données de performance. Évitez de collecter des informations utilisateur sensibles et assurez-vous que les données sont transmises de manière sécurisée (par exemple, en utilisant HTTPS).

Exemple : Mesurer le Time to First Byte (TTFB) avec l'API Resource Timing

Le TTFB est le temps qu'il faut au navigateur pour recevoir le premier octet de données du serveur. Bien qu'il ne s'agisse pas strictement d'une métrique personnalisée définie avec `mark` et `measure`, c'est un indicateur de performance précieux et il peut être accédé via l'API Resource Timing et observé avec un Performance Observer.

            
const ttfbObserver = new PerformanceObserver((list) => {
  list.getEntriesByType('resource').forEach((entry) => {
    if (entry.name === window.location.href) { // Vérifie s'il s'agit du document principal
      const ttfb = entry.responseStart - entry.startTime;
      console.log(`TTFB: ${ttfb}ms`);
      // Envoyer le ttfb à votre plateforme d'analytique
    }
  });
});

ttfbObserver.observe({ type: 'resource', buffered: true });

            

              
                Copy
              
            
          

Compatibilité entre Navigateurs

L'API Performance Observer est largement prise en charge par les navigateurs modernes. Cependant, il est toujours de bonne pratique de vérifier la compatibilité des navigateurs et de fournir des mécanismes de repli pour les navigateurs plus anciens. Vous pouvez utiliser un polyfill ou une technique de mesure plus simple pour les navigateurs qui ne prennent pas en charge l'API Performance Observer.

            
if ('PerformanceObserver' in window) {
  // Utiliser l'API Performance Observer
  const observer = new PerformanceObserver((list) => { /* ... */ });
  observer.observe({ entryTypes: ['measure'] });
} else {
  // Utiliser un mécanisme de repli (ex: Date.now() pour des mesures de temps simples)
  console.warn('API PerformanceObserver non prise en charge dans ce navigateur.');
}

            

              
                Copy
              
            
          

Meilleures Pratiques pour l'Utilisation des Métriques Personnalisées

• Définir des objectifs clairs : Quels aspects spécifiques de la performance souhaitez-vous surveiller ?
• Choisir des noms de métriques significatifs : Utilisez des noms descriptifs et cohérents pour vos métriques personnalisées.
• Documenter vos métriques : Documentez clairement l'objectif et le calcul de chaque métrique personnalisée.
• Établir des budgets de performance : Définissez des seuils de performance acceptables pour vos métriques personnalisées.
• Automatiser la collecte et l'analyse des données : Intégrez la collecte de métriques personnalisées dans votre processus de build et votre pipeline d'analytique.
• Examiner et affiner régulièrement vos métriques : À mesure que votre application évolue, vos besoins en matière de surveillance de la performance peuvent changer.

Conclusion

La performance frontend est un voyage continu, pas une destination. En tirant parti de l'API Frontend Performance Observer et en définissant des métriques personnalisées, vous pouvez acquérir une compréhension plus approfondie de la performance de votre application et identifier les domaines à améliorer. Cette approche sur mesure de la surveillance de la performance vous permet d'optimiser l'expérience utilisateur et de fournir une application web plus rapide et plus réactive. N'oubliez pas de surveiller, d'analyser et d'affiner constamment vos métriques pour garder une longueur d'avance et garantir que votre application fonctionne de manière optimale pour tous les utilisateurs, quel que soit leur emplacement ou leur appareil.

Cet article a fourni un aperçu complet des métriques personnalisées à l'aide de l'API Performance Observer. Il est crucial d'adapter ces techniques aux besoins spécifiques de votre application et de surveiller et analyser continuellement les données pour prendre des décisions éclairées en matière d'optimisation de la performance.

Lectures Complémentaires :

• API PerformanceObserver - MDN Web Docs
• performance.mark() - MDN Web Docs
• performance.measure() - MDN Web Docs