Bonnes pratiques pour mesurer les signaux Web sur le terrain

Comment mesurer les signaux Web avec votre outil d'analyse actuel

La possibilité de mesurer et de générer des rapports sur les performances réelles de vos pages est essentielle pour diagnostiquer et améliorer les performances au fil du temps. Sans données de champ, il est impossible de savoir avec certitude si les modifications que vous apportez à votre site atteignent les résultats souhaités.

De nombreux fournisseurs d'outils d'analyse populaires de la surveillance des utilisateurs réels (RUM) sont déjà compatibles avec les métriques Core Web Vitals dans leurs outils (ainsi que de nombreux autres Web Vitals). Si vous utilisez actuellement l'un de ces outils d'analyse RUM, vous êtes parfaitement équipé pour évaluer dans quelle mesure les pages de votre site respectent les seuils recommandés pour les Core Web Vitals et éviter les régressions à l'avenir.

Bien que nous vous recommandions d'utiliser un outil d'analyse compatible avec les métriques Core Web Vitals, si l'outil d'analyse que vous utilisez actuellement ne l'est pas, vous n'avez pas nécessairement besoin de changer. Presque tous les outils d'analyse offrent un moyen de définir et de mesurer des métriques personnalisées ou des événements. Vous pouvez donc probablement utiliser votre fournisseur d'analyse actuel pour mesurer les métriques Core Web Vitals et les ajouter à vos rapports et tableaux de bord d'analyse existants.

Ce guide présente les bonnes pratiques à suivre pour mesurer les métriques Core Web Vitals (ou toute métrique personnalisée) à l'aide d'un outil d'analyse tiers ou interne. Il peut également servir de guide aux fournisseurs d'outils d'analyse qui souhaitent ajouter la prise en charge des Core Web Vitals à leur service.

Utiliser des métriques ou des événements personnalisés

Comme indiqué ci-dessus, la plupart des outils d'analyse vous permettent de mesurer des données personnalisées. Si votre outil d'analyse le permet, vous devriez pouvoir mesurer chacune des métriques Core Web Vitals à l'aide de ce mécanisme.

La mesure des métriques ou événements personnalisés dans un outil d'analyse se déroule généralement en trois étapes:

  1. Définissez ou enregistrez la métrique personnalisée dans l'interface administrateur de votre outil (si nécessaire). (Remarque: tous les fournisseurs d'analyse ne nécessitent pas de définir des métriques personnalisées à l'avance.)
  2. Calculez la valeur de la métrique dans votre code JavaScript côté client.
  3. Envoyez la valeur de la métrique à votre backend d'analyse, en vous assurant que le nom ou l'ID correspond à ce qui a été défini à l'étape 1 (encore une fois, si nécessaire).

Pour les étapes 1 et 3, vous pouvez consulter la documentation de votre outil d'analyse pour obtenir des instructions. Pour l'étape 2, vous pouvez utiliser la bibliothèque JavaScript web-vitals pour calculer la valeur de chacune des métriques Core Web Vitals.

L'exemple de code suivant montre à quel point il peut être facile de suivre ces métriques dans le code et de les envoyer à un service d'analyse.

import {onCLS, onINP, onLCP} from 'web-vitals';

function sendToAnalytics({name, value, id}) {
  const body = JSON.stringify({name, value, id});
  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.
  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||
      fetch('/analytics', {body, method: 'POST', keepalive: true});
}

onCLS(sendToAnalytics);
onINP(sendToAnalytics);
onLCP(sendToAnalytics);

Éviter les moyennes

Il est tentant de résumer une plage de valeurs pour une métrique de performances en calculant une moyenne. Les moyennes semblent pratiques à première vue, car elles constituent un résumé bien organisé d'une grande quantité de données. Toutefois, vous devez résister à l'envie de vous y fier pour interpréter les performances des pages.

Les moyennes sont problématiques, car elles ne représentent pas la session d'un utilisateur donné. Les valeurs aberrantes à l'une ou l'autre extrémité de la distribution peuvent fausser la moyenne de manière trompeuse.

Par exemple, un petit groupe d'utilisateurs peut se trouver sur des réseaux ou des appareils extrêmement lents qui se situent dans la plage de valeurs maximales, mais qui ne représentent pas suffisamment de sessions utilisateur pour avoir un impact sur la moyenne de manière à suggérer qu'il existe un problème.

Dans la mesure du possible, utilisez des percentiles plutôt que des moyennes. Les percentiles d'une distribution pour une métrique de performances donnée décrivent mieux l'ensemble des expériences utilisateur de votre site Web. Vous pouvez ainsi vous concentrer sur des sous-ensembles d'expériences réelles, ce qui vous donnera plus d'insights qu'une seule valeur.

S'assurer que vous pouvez signaler une distribution

Une fois que vous avez calculé les valeurs de chacune des métriques "Signaux Web essentiels" et les avez envoyées à votre service d'analyse à l'aide d'une métrique ou d'un événement personnalisés, l'étape suivante consiste à créer un rapport ou un tableau de bord affichant les valeurs collectées.

Pour vous assurer de respecter les seuils recommandés pour les Core Web Vitals, votre rapport doit afficher la valeur de chaque métrique au 75e percentile.

Si votre outil d'analyse ne propose pas de rapports sur les quantiles en tant que fonctionnalité intégrée, vous pouvez probablement obtenir ces données manuellement en générant un rapport qui liste chaque valeur de métrique triée par ordre croissant. Une fois ce rapport généré, le résultat qui correspond à 75% de la liste complète et triée de toutes les valeurs de ce rapport sera le 75e percentile pour cette métrique. Cela sera le cas, quelle que soit la façon dont vous segmentez vos données (par type d'appareil, type de connexion, pays, etc.).

Si votre outil d'analyse ne vous fournit pas de granularité de reporting au niveau des métriques par défaut, vous pouvez probablement obtenir le même résultat si votre outil d'analyse est compatible avec les dimensions personnalisées. En définissant une valeur de dimension personnalisée unique pour chaque instance de métrique que vous suivez, vous devriez pouvoir générer un rapport, ventilé par instance de métrique, si vous incluez la dimension personnalisée dans la configuration du rapport. Étant donné que chaque instance aura une valeur de dimension unique, aucun regroupement ne sera effectué.

Le rapport "Signaux Web" est un exemple de cette technique qui utilise Google Analytics. Le code du rapport est Open Source. Les développeurs peuvent donc s'y référer comme à un exemple des techniques décrites dans cette section.

Captures d'écran du rapport Web Vitals

Envoyer vos données au bon moment

Certaines métriques de performances peuvent être calculées une fois le chargement de la page terminé, tandis que d'autres (comme le CLS) prennent en compte toute la durée de vie de la page et ne sont définitives qu'une fois la page commencée à se décharger.

Cela peut toutefois poser problème, car les événements beforeunload et unload ne sont pas fiables (en particulier sur mobile) et leur utilisation n'est pas recommandée (car ils peuvent empêcher une page d'être éligible au cache des pages précédentes et suivantes).

Pour les métriques qui suivent la durée de vie complète d'une page, il est préférable d'envoyer la valeur actuelle de la métrique lors de l'événement visibilitychange, chaque fois que l'état de visibilité de la page passe à hidden. En effet, une fois que l'état de visibilité de la page passe à hidden, rien ne garantit qu'un script de cette page pourra à nouveau s'exécuter. Cela est particulièrement vrai sur les systèmes d'exploitation mobiles, où l'application du navigateur elle-même peut être fermée sans que des rappels de page ne soient déclenchés.

Notez que les systèmes d'exploitation mobiles déclenchent généralement l'événement visibilitychange lors du changement d'onglet, de l'ouverture d'une autre application ou de la fermeture de l'application de navigateur elle-même. Ils déclenchent également l'événement visibilitychange lorsque vous fermez un onglet ou accédez à une nouvelle page. L'événement visibilitychange est donc beaucoup plus fiable que les événements unload ou beforeunload.

Surveiller les performances au fil du temps

Une fois que vous avez mis à jour votre implémentation d'analyse pour suivre et générer des rapports sur les métriques Core Web Vitals, l'étape suivante consiste à suivre l'impact des modifications apportées à votre site sur les performances au fil du temps.

Mettre à jour vos modifications

Une approche naïve (et finalement peu fiable) pour suivre les modifications consiste à les déployer en production, puis à supposer que toutes les métriques reçues après la date de déploiement correspondent au nouveau site et que toutes les métriques reçues avant la date de déploiement correspondent à l'ancien site. Toutefois, un certain nombre de facteurs (y compris la mise en cache au niveau de la couche HTTP, du service worker ou du CDN) peuvent empêcher cela de fonctionner.

Une meilleure approche consiste à créer une version unique pour chaque modification déployée, puis à suivre cette version dans votre outil d'analyse. La plupart des outils d'analyse permettent de définir une version. Si ce n'est pas le cas, vous pouvez créer une dimension personnalisée et la définir sur votre version déployée.

Effectuer des tests

Vous pouvez aller plus loin dans la gestion des versions en suivant plusieurs versions (ou tests) en même temps.

Si votre outil d'analyse vous permet de définir des groupes de test, utilisez cette fonctionnalité. Sinon, vous pouvez utiliser des dimensions personnalisées pour vous assurer que chacune de vos valeurs de métrique peut être associée à un groupe de test particulier dans vos rapports.

Une fois les tests mis en place dans vos données analytiques, vous pouvez déployer une modification expérimentale auprès d'un sous-ensemble de vos utilisateurs et comparer ses performances à celles des utilisateurs du groupe de contrôle. Une fois que vous êtes sûr qu'un changement améliore effectivement les performances, vous pouvez le déployer auprès de tous les utilisateurs.

S'assurer que la mesure n'affecte pas les performances

Lorsque vous mesurez les performances sur des utilisateurs réels, il est absolument essentiel que le code de mesure des performances que vous exécutez n'ait pas d'impact négatif sur les performances de votre page. Si c'est le cas, toutes les conclusions que vous tenterez de tirer sur l'impact de vos performances sur votre activité seront peu fiables, car vous ne saurez jamais si la présence du code d'analyse elle-même a le plus grand impact négatif.

Suivez toujours ces principes lorsque vous déployez le code d'analyse RUM sur votre site de production:

Différer vos données analytiques

Le code Analytics doit toujours être chargé de manière asynchrone et non bloquante, et généralement en dernier. Si vous chargez votre code d'analyse de manière bloquante, cela peut avoir un impact négatif sur le LCP.

Toutes les API utilisées pour mesurer les métriques Core Web Vitals ont été conçues spécifiquement pour prendre en charge le chargement asynchrone et différé des scripts (via l'indicateur buffered). Il n'est donc pas nécessaire de se précipiter pour charger vos scripts plus tôt.

Si vous mesurez une métrique qui ne peut pas être calculée plus tard dans le calendrier de chargement de la page, vous ne devez inclure que le code qui doit s'exécuter tôt dans le <head> de votre document (afin qu'il ne s'agisse pas d'une requête bloquant le rendu) et différer le reste. Ne chargez pas toutes vos données analytiques à l'avance simplement parce qu'une seule métrique l'exige.

Ne créez pas de tâches longues

Le code d'analyse s'exécute souvent en réponse à une entrée utilisateur, mais si votre code d'analyse effectue de nombreuses mesures DOM ou utilise d'autres API gourmandes en processeur, le code d'analyse lui-même peut entraîner une mauvaise réactivité des entrées. De plus, si le fichier JavaScript contenant votre code d'analyse est volumineux, son exécution peut bloquer le thread principal et avoir un impact négatif sur l'interaction jusqu'à la prochaine peinture (INP) d'une page.

Utiliser des API non bloquantes

Les API telles que sendBeacon() et requestIdleCallback() sont spécifiquement conçues pour exécuter des tâches non critiques de manière à ne pas bloquer les tâches critiques pour l'utilisateur.

Ces API sont d'excellents outils à utiliser dans une bibliothèque d'analyse RUM.

En règle générale, tous les balises d'analyse doivent être envoyées à l'aide de l'API sendBeacon() (si disponible), et tout code de mesure d'analyse passive doit être exécuté pendant les périodes d'inactivité.

Ne pas suivre plus que ce dont vous avez besoin

Le navigateur expose de nombreuses données de performances, mais le fait qu'elles soient disponibles ne signifie pas nécessairement que vous devez les enregistrer et les envoyer à vos serveurs d'analyse.

Par exemple, l'API Resource Timing fournit des données temporelles détaillées pour chaque ressource chargée sur votre page. Toutefois, il est peu probable que toutes ces données soient nécessaires ou utiles pour améliorer les performances de chargement des ressources.

En résumé, ne suivez pas simplement les données parce qu'elles sont là, assurez-vous qu'elles seront utilisées avant de consommer des ressources pour les suivre.