Mesurer le chemin critique du rendu

Ilya Grigorik

Publié le 31 mars 2014

La base de toute stratégie de performances solide repose sur de bonnes mesures et une bonne instrumentation. Vous ne pouvez pas optimiser ce que vous ne pouvez pas mesurer. Ce guide explique les différentes approches permettant de mesurer les performances des CRP.

• L'approche Lighthouse exécute une série de tests automatisés sur une page, puis génère un rapport sur les performances de la page en termes de CRP. Cette approche fournit une présentation générale rapide et basique des performances de la CRP d'une page spécifique chargée dans votre navigateur, ce qui vous permet de tester, d'itérer et d'améliorer rapidement ses performances.
• L'approche de l'API Navigation Timing capture les métriques de surveillance des utilisateurs réels (RUM). Comme leur nom l'indique, ces métriques sont collectées à partir d'interactions réelles des utilisateurs avec votre site. Elles fournissent une vue précise des performances réelles de la CRP, telles que les voient vos utilisateurs sur différents appareils et dans différentes conditions de réseau.

En général, une bonne approche consiste à utiliser Lighthouse pour identifier les opportunités évidentes d'optimisation de la CRP, puis à instrumenter votre code avec l'API Navigation Timing pour surveiller les performances de votre application.

Auditer une page avec Lighthouse

Lighthouse est un outil d'audit d'applications Web qui exécute une série de tests sur une page donnée, puis affiche les résultats de la page dans un rapport consolidé. Vous pouvez exécuter Lighthouse en tant qu'extension Chrome ou module NPM, ce qui est utile pour intégrer Lighthouse à des systèmes d'intégration continue.

Pour commencer, consultez Auditer des applications Web avec Lighthouse.

Lorsque vous exécutez Lighthouse en tant qu'extension Chrome, les résultats du CRP de votre page ressemblent à la capture d'écran suivante.

Pour en savoir plus sur les résultats de cet audit, consultez Chaînes de requêtes critiques.

Instrumenter votre code avec l'API Navigation Timing

La combinaison de l'API Navigation Timing et d'autres événements du navigateur émis lors du chargement de la page vous permet de capturer et d'enregistrer les performances réelles de la CRP de n'importe quelle page.

Chacun des libellés du diagramme précédent correspond à un code temporel haute résolution que le navigateur suit pour chaque page qu'il charge. En fait, dans ce cas précis, nous n'affichons qu'une fraction de tous les différents codes temporels. Pour l'instant, nous ignorons tous les codes temporels liés au réseau, mais nous y reviendrons dans une prochaine leçon.

Que signifient ces codes temporels ?

• domLoading: horodatage de début de l'ensemble du processus. Le navigateur est sur le point de commencer à analyser les premiers octets reçus du document HTML.
• domInteractive: marque le point lorsque le navigateur a fini d'analyser l'ensemble du code HTML et du DOM.
• domContentLoaded : marque le moment où le DOM est prêt et qu'aucune feuille de style ne bloque l'exécution JavaScript. Cela signifie que nous pouvons maintenant (potentiellement) construire l'arborescence de rendu.
  • De nombreux frameworks JavaScript attendent cet événement avant de commencer à exécuter leur propre logique. C'est pourquoi le navigateur capture les codes temporels EventStart et EventEnd pour nous permettre de suivre la durée de cette exécution.
• domComplete : comme son nom l'indique, tout le traitement est terminé et toutes les ressources de la page (images, etc.) ont été téléchargées. En d'autres termes, la roue de chargement a cessé de tourner.
• loadEvent : à la dernière étape de chaque chargement de page, le navigateur déclenche un événement onload qui peut déclencher une logique d'application supplémentaire.

La spécification HTML dicte des conditions spécifiques pour chaque événement : quand il doit être déclenché, quelles conditions doivent être remplies et d'autres considérations importantes. Pour nos besoins, nous allons nous concentrer sur quelques étapes clés liées au chemin de rendu critique :

• domInteractive indique quand le DOM est prêt.
• domContentLoaded indique généralement quand le DOM et le CSSOM sont prêts.
  • Si aucun analyseur ne bloque JavaScript, DOMContentLoaded se déclenchera immédiatement après domInteractive.
• domComplete indique quand la page et toutes ses sous-ressources sont prêtes.

<!DOCTYPE html>
<html>
  <head>
    <title>Critical Path: Measure</title>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <link href="style.css" rel="stylesheet" />
    <script>
      function measureCRP() {
        var t = window.performance.timing,
          interactive = t.domInteractive - t.domLoading,
          dcl = t.domContentLoadedEventStart - t.domLoading,
          complete = t.domComplete - t.domLoading;
        var stats = document.createElement('p');
        stats.textContent =
          'interactive: ' +
          interactive +
          'ms, ' +
          'dcl: ' +
          dcl +
          'ms, complete: ' +
          complete +
          'ms';
        document.body.appendChild(stats);
      }
    </script>
  </head>
  <body onload="measureCRP()">
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg" /></div>
  </body>
</html>

Essayer

L'exemple précédent peut sembler un peu intimidant à première vue, mais en réalité, il est assez simple. L'API Navigation Timing capture tous les codes temporels pertinents, et notre code attend que l'événement onload se déclenche (souvenez-vous que l'événement onload se déclenche après domInteractive, domContentLoaded et domComplete) et calcule la différence entre les différents codes temporels.

Nous avons maintenant des jalons spécifiques à suivre et une fonction de base pour générer ces mesures. Notez qu'au lieu d'imprimer ces métriques sur la page, vous pouvez également modifier le code afin de les envoyer à un serveur d'analyse (Google Analytics le fait automatiquement). C'est un excellent moyen de garder un œil sur les performances de vos pages et d'identifier les pages candidates qui pourraient bénéficier d'un travail d'optimisation.

Qu'en est-il des outils de développement ?

Bien que ces documents utilisent parfois le panneau "Network" (Réseau) de Chrome DevTools pour illustrer les concepts de CRP, DevTools n'est pas adapté aux mesures de CRP, car il ne dispose pas d'un mécanisme intégré permettant d'isoler les ressources critiques. Exécutez un audit Lighthouse pour identifier ces ressources.

Commentaires