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 prêt à évaluer dans quelle mesure les pages de votre site respectent les seuils Core Web Vitals recommandés 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 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 est compatible avec cette fonctionnalité, 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 :
- Définissez ou enregistrez la métrique personnalisée dans l'interface administrateur de votre outil (si nécessaire). (Remarque: les fournisseurs de solutions d'analyse n'exigent pas tous la définition de métriques personnalisées à l'avance.)
- Calculez la valeur de la métrique dans votre code JavaScript côté client.
- 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 anomalies dans les deux plages de 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 offrira plus d'informations 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 toujours 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 de ce rapport est Open Source. Les développeurs peuvent donc le référencer comme exemple des techniques décrites dans cette section.
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 arrière).
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. Cela rend l'événement visibilitychange 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.
Gérer les versions de 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. Cependant, 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 cette méthode 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.
Vérifier 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 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 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 données analytiques à l'avance 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, 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 sans bloquer les tâches critiques de 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 que les données 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 bref, ne vous contentez pas de suivre les données, car elles sont présentes, assurez-vous qu'elles seront utilisées avant de consommer des ressources qui les suivent.