Measure - Custom - Web performance

Pour évaluer vos temps de chargement et les améliorer, vous avez besoin d’identifier précisément les tâches et les événements les plus chronophages pour le navigateur. Mais comment savoir le temps qu’il faut à un script pour s’exécuter ? A quel moment s’affiche l’image principale d’une page ? Quel est le délai de traitement d’une action de l’utilisateur.rice avant qu’elle ne s’exécute ?
Pour répondre à toutes ces questions, les outils et les métriques traditionnelles peuvent être limitées. Les réponses se trouvent alors du côté des Custom Metrics via l’API User Timing ! Jean-Pierre Vincent nous explique à quoi elles servent et comment les utiliser.

Mesurez les événements de votre choix pendant le chargement d’une page

Les indicateurs de web performance sont nombreux et ont chacun leur utilité. Parmi les plus connus, vous pouvez observer la vitesse d’affichage grâce au Speed Index, l’interactivité avec le Time To Interactive, le moment où la page blanche laisse place aux premiers éléments avec le Start Render, ou encore évaluer le temps de réponse serveur avec le Time To First Byte… 

Mais pour plus de finesse et détecter certains leviers d’amélioration précis (pour votre UX, vos taux de conversion…), certains événements au cours du chargement d’une page méritent d’être isolés pour être mesurés. En effet, tous les contenus ne se valent pas, ils n’ont pas tous la même importance pour vos internautes.

La solution ? L’API User Timing, qui vous permet de marquer des événements en JS pour que votre outil de RUM ou de Synthetic Monitoring les affichent au même titre que les événements classiques du chargement de vos pages.

Vous pouvez ainsi indiquer ces événements custom où vous le souhaitez pour relever le moment auquel une image ou un slider s’affichent, un script d’A/B Test se lance, un CTA devient actif, ou quand le deferJS commence à s’exécuter…

Cette méthode est d’autant plus utile pour les pages basées sur des composants, afin de savoir quand l’exécution d’un composant est finie.

Voici un cas dans lequel les Custom Metrics sont particulièrement utiles : il s’agit d’un site de presse. Pour ce type de site, le chargement des pages est marqué par de nombreux événements pour lesquels les métriques génériques ne sont pas adaptées.

Dans cet exemple - typique du chargement d’une page d’un site de presse - sans Custom Metrics, impossible de savoir si le Speed Index ou le Start Render correspondent bien à la réalité du métier. En effet, le comptage Médiamétrie (que l’internaute ne voit pas mais qui est vital pour le métier) et la publicité viennent brouiller les pistes des outils de monitoring, surtout pour les analyses basées sur le Speed Index. En effet, ces événements ne permettent pas de déduire le temps de chargement réel des éléments pertinents pour l’internaute.

custom-metrics-javascript-webperf

Pourquoi utiliser des Custom Metrics et comment les implémenter ?

L’implémentation des Custom Metrics nécessite de modifier le code et un minimum de maintenance, mais le jeu en vaut la chandelle puisqu’elles permettent de disposer d’indicateurs personnalisés en fonction de ce que vous avez précisément besoin de mesurer.

L’API user timing

Disponible sur quasiment tous les navigateurs depuis Chrome 25, elle sert à mesurer les performances en donnant accès à des marqueurs de temps précis et personnalisables. 

Pour marquer le début d’un événement 

Vous aurez besoin d’utiliser le standard performance.mark() pour demander au navigateur de marquer les événements qui vous intéressent en leur attribuant un nom, dont l’entryType sera “mark” (récupérable ensuite via window.performance.getEntries()), et l’attribut duration sera à 0 (NB : Pour les Third Parties, vous aurez besoin de demander aux tiers d’implémenter le header HTTP Timing-Allow-Origin) :

performance.mark('ma-metrique');

Pour mesurer une durée entre deux événements

Vous pouvez aussi mesurer la durée qui sépare deux marques comme suit, dont l’entryType sera alors “measure”, et dont l'attribut duration correspondra à la différence entre la marque start et la marque end

performance.mark(‘startSlider’);
performance.mark(‘endSlider’);
performance.measure(‘chargement-du-slider’, ‘startSlider’, ‘endSlider’);

 

Pour observer les changements à l’écran

Comme le souligne Boris Schapira dans un article détaillé sur le sujet : ce n’est pas parce que le navigateur exécute du JavaScript que les changements sont visibles à l’écran par l'utilisateur.rice.

La solution consiste alors à utiliser requestAnimationFrame(). Ainsi, le marqueur s’intègre de façon à vous rapprocher du comportement de l’interface plutôt que de l’exécution du code.
Nous verrons un peu plus tard l'API Element Timing qui répond aussi à ce besoin.

Quelques cas d’usage

Nous avons évoqué le fait que les métriques webperf sont nombreuses… et les possibilités deviennent infinies avec les Custom Metrics. Pour vous inspirer, voici quelques cas d’usage suggérés par SpeedCurve :

  • détecter quand le chargement des CSS est terminé et comprendre quand démarre le rendu ;
  • observer quand les scripts bloquants ont fini de se charger et de s’exécuter ;
  • identifier le début du chargement des fonts ;
  • voir quand l’image la plus importante (hero image) ou le texte apparaissent ;
  • marquer les actions sur une Single Page App.

Si vous êtes à présent convaincu.e.s de l’utilité des Custom Metrics, vous vous demandez peut-être comment les visualiser. Voici comment intégrer ces données dans vos outils de monitoring webperf.

Visualiser les infos à propos des Custom Metrics

Sur un outil de Synthetic Monitoring

Afin de visualiser ces Custom Metrics dans un outil de monitoring, vous aurez besoin de les déclarer. Plusieurs méthodes existent pour que vos outils les prennent en compte : dans un bloc JS comme nous l’avons vu, un script JS, ou encore dans du HTML avec ce type de balise :

<img src="hero.jpg" onload="performance.mark('hero image');">

WebPageTest ou Dareboost peuvent ensuite récupérer et traduire visuellement ces métriques.

Par exemple, sur WebPageTest :

https://www.fasterize.com/wp-content/uploads/2020/04/web-page-test-custom-metrics

Ou encore sur Dareboost :

https://www.fasterize.com/wp-content/uploads/2020/04/dareboost-custom-metrics

Sur un outil de Real User Monitoring

Visualiser les événements sélectionnés dans un outil de RUM nécessite d’y envoyer les données, c’est un peu plus complexe qu’avec un outil de Synthetic Monitoring.

Pour cela, vous avez tout intérêt à préférer un outil de RUM qui offre un bon taux de sampling, comme le font Quanta, New Relic ou Pingdom.

Si vous êtes tenté.e.s par une option open-source : BoomerangJS vous permettra de collecter les données côté navigateur, BasicRUM vous sera utile pour le stockage et la visualisation, à déployer sur vos propres serveurs.

Vous pouvez aussi faire appel à Google Analytics qui présente l’avantage d’être gratuit, mais… Sachez toutefois que le sampling n’est pas optimal ; et bien qu’il puisse être augmenté en suivant cette documentation, cela vous permettra de réaliser une estimation mais pas d’obtenir des résultats précis.

Voyons toutefois comment vous pouvez utiliser Google Analytics pour marquer et afficher des éléments personnalisés grâce aux User timings

Cette opération nécessite deux étapes :

  1. Récupérer le timing d’un événement donné depuis la timeline du navigateur, après que la page a fini de se charger :
window.addEventListener('load', () => {
performance.getEntriesByType('mark').forEach( (t) => console.log( t.name, t.startTime ) )
}) 

Exemple de sortie : 

https://www.fasterize.com/wp-content/uploads/2020/04/custom-metrics-getentries

 

 

 

2. Envoyer ce chiffre côté serveur, ici Google Analytics

Il suffit alors de remplacer le console.log() ci-dessus par la ligne suivante (à adapter en fonction de la documentation de votre fournisseur de RUM) :

ga('send', {
  hitType: 'timing',
  timingCategory: t.name,
  timingValue: t.startTime
})

Après un certain temps de collecte de données, Google Analytics vous permettra de visualiser une courbe telle que celle ci-dessous, afin de repérer les périodes critiques.

https://www.fasterize.com/wp-content/uploads/2020/04/google-analytics-custom-metrics

Courbe Google Analytics sur plusieurs années,
indiquant le temps qu’il faut à un test A/B pour afficher la page

D’autres API en cours d’exploration pour customiser vos métriques webperf

Lors de son talk à We Love Speed 2019, Gilles Dubuc évoquait deux autres API en cours d’exploration, en test chez Wikimedia : Element Timing et Event Timing.

Element Timing permet d’évaluer à quel moment un élément donné apparaît à l’écran.
Cette API répond au besoin de détecter quand une image est chargée ET s’affiche dans le navigateur, ce qui reste à l’heure actuelle difficile sans alourdir le code.
Il en va de même pour le texte : repérer le moment où un bloc de texte est réellement affiché reste complexe et imprécis. On peut savoir quand une font est chargée, si son style permet de l’afficher, ainsi que ses parents, mais l’arrivée d’Element Timing permettra d’arrêter de faire des suppositions.

Google détaille le principe ici pour les images et ici pour le texte ; l’état des recherches est consigné ici.

En pratique, en HTML, le code ressemblera à : 

<img src="my_image.jpg" elementtiming="foobar">

Et pour la récupération en JS :

const observer = new PerformanceObserver((list) => {
  let perfEntries = list.getEntries().forEach(function(entry) {
      // Send the information to analytics, or in this case just log it to console.
      if (entry.identifier === 'foobar') {
        if (entry.renderTime)
          console.log("My image took " + entry.renderTime + " to render!");
        else
          console.log("Rendering time not available. Image took " + entry.loadTime + " to load!");
      }
   });
});
observer.observe({entryTypes: ['element']});

Event Timing permettra quant à lui de mesurer le temps qu’il faut à une action de l’utilisateur.rice pour être traitée par le navigateur (par exemple, un clic). Le projet est détaillé ici par Google et l’état d’avancement consigné ici.

Ainsi, si vous vous intéressez à l’amélioration de vos temps de chargement et que les métriques génériques ne vous permettent pas de mesurer exactement ce que vous souhaitez, les Custom Metrics sont faites pour vous !

Elles demandent quelques efforts de mise en place, mais elles ont une grande utilité pour le métier car elles permettent de se concentrer sur des éléments précis d’une page, que ce soit pour marquer le début d’un événement ou la durée entre deux événements.

Vous souhaitez suivre les actus webperf, nos astuces techniques
et être au courant des évolutions du secteur ?
Abonnez-vous à notre newsletter mensuelle :

Je m'abonne !


Hello SMX Paris !