Comment mesurer les Web Vitals avec votre outil d'analyse actuel
Pouvoir mesurer les performances réelles de vos campagnes et générer des rapports est essentielle pour diagnostiquer et améliorer les performances au fil du temps. Sans champ données, il est impossible de savoir avec certitude si les modifications que vous apportez à votre site atteignent réellement les résultats souhaités.
De nombreuses fonctionnalités de surveillance en situation réelle (Real User Monitoring) (RUM) des fournisseurs de solutions d'analyse sont déjà compatibles avec les métriques Core Web Vitals (ainsi que de nombreux autres Web Vitals). Si vous utilisez si vous utilisez actuellement l'un de ces outils d'analyse RUM, vous êtes en bonne voie pour évaluer si les pages de votre site respectent les Core Web Vitals recommandés des seuils et d'éviter les régressions à l'avenir.
Nous vous recommandons d'utiliser un outil d'analyse compatible avec le rapport Core Web Vitals Si votre outil d'analyse n'est pas compatible, n'ont pas nécessairement besoin d'en changer. Presque tous les outils d'analyse offrent un moyen définissez et mesurez des données de métriques ou événements, ce qui signifie que peut probablement utiliser votre fournisseur de solution d'analyse actuel pour mesurer les 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 l'outil d'analyse le permet, vous devriez être en mesure de mesurer chacune les métriques Android Vitals à l'aide de ce mécanisme.
La mesure des événements ou des métriques personnalisées dans un outil d'analyse en trois étapes:
- Définissez ou registre la métrique personnalisée dans l'interface administrateur de votre outil (si nécessaire). (Remarque : les fournisseurs de solutions d'analyse exigent la définition de métriques personnalisées à l'avance.)
- Calculez la valeur de la métrique dans le code JavaScript de l'interface.
- Envoyez la valeur de la métrique à votre backend d'analyse, en vérifiant le nom ou l'ID. correspond à ce qui a été défini à l'étape 1 (à nouveau si nécessaire).
Pour les étapes 1 et 3, reportez-vous à la documentation de votre outil d'analyse instructions. Pour l'étape 2, vous pouvez utiliser 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 et 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 peut être tentant d'additionner une plage de valeurs pour une métrique de performances pour calculer une moyenne. Les moyennes semblent utiles à première vue, car il s'agit un résumé soigné d'une grande quantité de données, mais vous devez résister à la tentation de s'appuyer pour interpréter les performances de la page.
Les moyennes posent problème car ils ne représentent pas la session d'un seul utilisateur. Les valeurs aberrantes de l'une ou l'autre plage peut fausser la moyenne de façon trompeuse.
Par exemple, un petit groupe d'utilisateurs peut utiliser des réseaux ou des appareils extrêmement lents. qui se rapprochent de la plage de valeurs maximale, mais qui ne représentent pas un nombre suffisant sessions pour avoir un impact sur la moyenne d'une manière qui suggère qu'il y a un problème.
Dans la mesure du possible, utilisez les centiles plutôt que les moyennes. Centiles au sein d'un pour une métrique de performance donnée décrivent mieux l'ensemble l'expérience utilisateur pour votre site Web. Cela vous permet de vous concentrer sur des sous-ensembles des expériences réelles, qui vous offriront plus d'insights qu'une seule valeur pourrait.
S'assurer de pouvoir signaler une distribution
Une fois que vous avez calculé les valeurs de chacune des métriques Core Web Vitals et envoyé à votre service d'analyse à l'aide d'une métrique ou d'un événement personnalisé, l'étape suivante consiste à pour créer un rapport ou un tableau de bord affichant les valeurs collectées.
Pour vous assurer de respecter les critères Core Web Vitals recommandés seuils, vous devez générer un rapport pour afficher la valeur de chaque métrique au 75e centile.
Si votre outil d'analyse n'offre 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 répertorie chaque valeur de métrique triée dans l'ordre croissant. Une fois ce rapport généré, 75% de la liste complète et triée de toutes les valeurs dans Ce rapport correspond au 75e centile de cette métrique. 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 permet pas d'obtenir un rapport au niveau des métriques vous obtiendrez probablement le même résultat si votre outil est compatible avec les d'audience. En définissant un valeur de dimension personnalisée unique pour chaque instance de métrique individuelle dont vous effectuez le suivi, vous devriez pouvoir générer un rapport ventilé par métrique individuelle instances, 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.
Rapport "Signaux Web" est un exemple de cette technique qui utilise Google Analytics. Le code de la section est Open Source, afin que les développeurs puissent s'en servir comme exemple des techniques décrites dans ce .
Envoyez vos données au bon moment
Certaines métriques de performances peuvent être calculées une fois la page chargée. tandis que d'autres (comme le CLS) tiennent compte de la durée de vie complète de la page final une fois que le déchargement de la page a commencé.
Cela peut toutefois poser problème, car beforeunload et unload
ne sont pas fiables (en particulier sur les appareils mobiles) et leur utilisation n'est pas
recommandé
(car ils peuvent empêcher une page d'être éligible pour le rapport Page
Cache).
Pour les métriques qui effectuent le suivi de toute la durée de vie d'une page, il est préférable d'envoyer
la valeur actuelle de la métrique est pendant l'événement visibilitychange, chaque fois que
l'état de visibilité de la page est défini sur hidden. En effet, une fois que la page
l'état de visibilité passe à hidden : il n'y a aucune garantie qu'un script sur
cette page pourra s'exécuter à nouveau. C'est particulièrement vrai pour les environnements
Systèmes permettant de fermer l'application de navigateur elle-même sans aucun rappel de page
être virées.
Notez que les systèmes d'exploitation mobiles déclenchent généralement visibilitychange
lors du changement d'onglet, du changement d'application ou de la fermeture du navigateur.
Elles déclenchent également l'événement visibilitychange lors de la fermeture d'un onglet ou de la navigation vers
une nouvelle page. Ainsi, l'événement visibilitychange est beaucoup plus fiable que l'événement
Événements unload ou beforeunload.
Surveiller les performances au fil du temps
Une fois que vous avez mis à jour l'implémentation de Google Analytics pour suivre et générer des rapports les métriques Core Web Vitals, l'étape suivante consiste à suivre l'évolution de votre site sur les performances au fil du temps.
Gérer les versions de vos modifications
Une approche simpliste (et finalement peu fiable) du suivi des modifications consiste à déployer en production, et supposer que toutes les métriques reçues après le date de déploiement correspondent à celle du nouveau site et à toutes les métriques reçues avant le 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, de service worker ou de CDN) peuvent empêcher de travailler.
Une bien meilleure approche consiste à créer une version unique pour chaque modification déployée. puis suivez cette version dans votre outil d'analyse. La plupart des outils d'analyse sont compatibles définir une version. Si ce n'est pas le cas, vous pouvez créer une dimension personnalisée et définir cette dimension à votre version déployée.
Effectuer des tests
Vous pouvez aller encore plus loin en effectuant le suivi de plusieurs versions 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 peuvent être associés à un groupe de test spécifique dans vos rapports.
Une fois les tests en place, vous pouvez déployer à tester une modification auprès d'un sous-ensemble d'utilisateurs et comparer les performances qui modifient les performances des utilisateurs du groupe de contrôle. Une fois que vous avez de l'assurance qu'un changement améliore les performances, vous pouvez le déployer tous les utilisateurs.
Vérifier que les mesures n'affectent pas les performances
Lorsque vous mesurez les performances sur des utilisateurs réels, du code de mesure des performances que vous exécutez n'a pas d'impact négatif les performances de votre page. Si c'est le cas, alors toutes les conclusions que vous essayez de tirer sur l'impact de vos performances sur votre entreprise, car vous risquez vous ne savez jamais si la présence du code d'analyse lui-même est la plus importante un 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. généralement, il doit être chargé en dernier. Si vous chargez votre code d'analyse dans un cela peut avoir un impact négatif sur le LCP.
Toutes les API utilisées pour mesurer les métriques Core Web Vitals étaient spécifiques
conçue pour permettre le chargement de script asynchrone et différé (via le
l'option buffered), donc
il n'est pas nécessaire 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 le
de la timeline de chargement de page, n'intégrez que le code à exécuter tôt
dans la <head> de votre document (il ne s'agit donc pas d'un blocage
requête) et différer le reste. Ne chargez pas toutes vos
des analyses dès le début parce qu'une
seule métrique l'exige.
Ne pas créer de longues tâches
Le code Analytics s'exécute souvent en réponse à une entrée utilisateur, mais si votre code Analytics effectue de nombreuses mesures DOM ou utilise d'autres API gourmandes en ressources de processeur. le code d'analyse lui-même peut provoquer une mauvaise réactivité aux entrées. De plus, si Le fichier JavaScript contenant votre code d'analyse est volumineux, il exécute ce fichier peut bloquer le thread principal et avoir un impact négatif sur l'Interaction to Next Paint (INP) d'une page.
Utiliser des API non bloquantes
Les API telles que
sendBeacon()
et
requestIdleCallback()
sont spécialement conçus pour exécuter des tâches non critiques
bloquer les tâches
essentielles 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 tout 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, mais ce n'est pas parce qu'elles sont ne signifie pas nécessairement que vous devez l'enregistrer et l'envoyer des 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. Cependant, il est peu probable que toutes ces données soient nécessairement ou utiles ce qui améliore les performances de chargement des ressources.
En bref, ne vous contentez pas de suivre les données, car elles sont présentes, assurez-vous que les données seront utilisées avant de consommer des ressources pour le suivre.