Comment mesurer les signaux Web avec votre outil d'analyse actuel.
La possibilité de mesurer les performances réelles de vos pages et de générer des rapports les concernant est essentielle pour diagnostiquer et améliorer les performances au fil du temps. Sans les données de terrain, il est impossible de savoir avec certitude si les modifications que vous apportez à votre site donnent réellement les résultats souhaités.
De nombreux fournisseurs de solutions d'analyse Real User Monitoring (RUM) prennent déjà en charge les métriques Core Web Vitals dans leurs outils (ainsi que de nombreuses autres métriques Web Vitals). Si vous utilisez actuellement l'un de ces outils d'analyse RUM, vous êtes en mesure d'évaluer dans quelle mesure les pages de votre site respectent les seuils recommandés Core Web Vitals et d'é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 les prend pas en charge, vous n'avez pas nécessairement besoin de changer. Presque tous les outils d'analyse permettent de définir et de mesurer des métriques personnalisées ou des événements. Vous pouvez donc probablement utiliser votre fournisseur de solutions 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 décrit 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 de solutions 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 de métriques ou d'événements personnalisés dans un outil d'analyse s'effectue généralement en trois étapes:
- Définissez ou enregistrez la métrique personnalisée dans l'administrateur de votre outil (si nécessaire). (Remarque: Tous les fournisseurs de solutions d'analyse n'exigent pas que des métriques personnalisées soient définies à l'avance.)
- Calculez la valeur de la métrique dans le code JavaScript de votre interface.
- 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 est facile de suivre ces métriques dans le code et de les envoyer à un service d'analyse.
import {onCLS, onFID, 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);
onFID(sendToAnalytics);
onLCP(sendToAnalytics);
Éviter les moyennes
Il est tentant d'additionner une plage de valeurs pour une métrique de performances en calculant une moyenne. Les moyennes semblent pratiques à première vue, car elles résument bien une grande quantité de données, mais vous devez résister à la tentation de vous y fier pour interpréter les performances d'une page.
Les moyennes sont problématiques, car elles ne représentent pas la session d'un seul utilisateur. Les anomalies au niveau de l'une ou l'autre plage 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 extrêmement lents ou sur des appareils proches de la plage de valeurs maximale, mais ne pas tenir compte d'un nombre suffisant de sessions utilisateur pour avoir un impact sur la moyenne d'une manière qui suggère la présence d'un problème.
Dans la mesure du possible, utilisez des centiles plutôt que des moyennes. Les centiles 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 fournira plus d'informations qu'une seule valeur ne pourrait jamais.
Assurez-vous de pouvoir signaler une distribution
Une fois que vous avez calculé les valeurs de chacune des métriques Core Web Vitals et que vous les avez envoyées à votre service d'analyse à l'aide d'une métrique ou d'un événement personnalisé, l'étape suivante consiste à créer un rapport ou un tableau de bord affichant les valeurs collectées.
Pour vous assurer d'atteindre les seuils recommandés pour les métriques Core Web Vitals, votre rapport doit afficher la valeur de chaque métrique au 75e centile.
Si votre outil d'analyse ne propose pas la création 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 listant chaque valeur de métrique triée par ordre croissant. Une fois ce rapport généré, le résultat qui s'affiche à 75% de la liste complète et triée de toutes les valeurs de ce rapport correspond au 75e centile de cette métrique. Ce 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 n'offre pas par défaut la précision des rapports au niveau des métriques, vous pouvez probablement obtenir le même résultat s'il 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 réparti 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 n'aura lieu.
Le rapport Core Web Vitals est un exemple de cette technique qui utilise Google Analytics. Le code de ce rapport étant Open Source, les développeurs peuvent s'en servir comme exemple des techniques décrites dans cette section.
Envoyez 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 que lorsque la page a commencé à 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 amélioré).
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 s'exécutera à nouveau. Cela est particulièrement vrai sur les systèmes d'exploitation mobiles où l'application de navigateur elle-même peut être fermée sans qu'aucun rappel de page ne soit déclenché.
Notez que les systèmes d'exploitation mobiles déclenchent généralement l'événement visibilitychange lors du changement d'onglet, du changement d'application ou de la fermeture du navigateur.
Ils déclenchent également l'événement visibilitychange lors de la fermeture d'un onglet ou de la navigation vers une nouvelle page. De ce fait, l'événement visibilitychange est 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 configuration d'analyse pour suivre les métriques Core Web Vitals et générer des rapports les concernant, vous devez suivre l'impact des modifications apportées à votre site sur les performances au fil du temps.
Version de vos modifications
Une approche naïve (et finalement peu fiable) du suivi des modifications consiste à déployer ces modifications en production, puis à partir du principe 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. Cependant, n'importe quel nombre de facteurs (y compris la mise en cache au niveau de la couche HTTP, service worker ou CDN) peut empêcher cela de fonctionner.
Une approche bien meilleure 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 de la vôtre, vous pouvez créer une dimension personnalisée et la définir sur votre version déployée.
Effectuer des tests
Pour aller plus loin, vous pouvez suivre 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 des valeurs de vos métriques peut être associée à un groupe de test spécifique dans vos rapports.
Une fois les tests mis en place dans vos analyses, vous pouvez déployer une modification expérimentale sur un sous-ensemble d'utilisateurs et comparer les performances de cette modification à celles des utilisateurs du groupe de contrôle. Une fois que vous avez la certitude qu'une modification améliore les performances, vous pouvez la déployer auprès de tous les utilisateurs.
S'assurer que les mesures n'affectent 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 essayez de tirer sur l'impact de vos performances sur votre activité ne seront pas fiables, car vous ne saurez jamais si la présence du code d'analyse en lui-même a le plus grand impact négatif.
Suivez toujours ces principes lorsque vous déployez du code d'analyse RUM sur votre site de production:
Reporter 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é spécialement conçues pour accepter le chargement de scripts asynchrone et différé (via l'indicateur buffered). Vous n'avez donc pas besoin de vous précipiter pour charger vos scripts plus tôt.
Si vous mesurez une métrique qui ne peut pas être calculée ultérieurement dans la chronologie de chargement de la page, vous devez intégrer uniquement le code qui doit s'exécuter tôt dans la <head> de votre document (il ne s'agit donc pas d'une requête bloquant l'affichage) et différer le reste. Ne chargez pas toutes vos analyses trop tôt simplement parce qu'une seule métrique l'exige.
Ne pas créer de longues tâches
Le code d'analyse s'exécute souvent en réponse à une entrée utilisateur. Toutefois, 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é aux entrées. En outre, 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 le First Input Delay (FID) ou l'Interaction to Next Paint (INP).
Utiliser des API non bloquantes
Les API telles que sendBeacon() et requestIdleCallback() sont spécialement conçues pour exécuter des tâches non critiques sans bloquer les tâches critiques de l'utilisateur.
Ces API sont d'excellents outils à utiliser dans une bibliothèque d'analyse RUM.
En général, toutes les balises d'analyse doivent être envoyées à l'aide de l'API sendBeacon() (si disponible), et l'ensemble du code de mesure d'analyse passive doit être exécuté pendant les périodes d'inactivité.
Ne suivez pas plus que ce dont vous avez besoin
Le navigateur expose de nombreuses données de performances. Toutefois, ce n'est pas parce que ces données sont disponibles 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 bref, ne vous contentez pas de suivre les données parce qu'elles sont présentes, assurez-vous qu'elles seront utilisées avant de consommer les ressources qui les suivent.