Mesurer le chemin critique du rendu

Ilya Grigorik

Des mesures et une instrumentation efficaces sont à la base de toute stratégie de performances solide. Vous ne pouvez pas optimiser ce que vous ne pouvez pas mesurer. Ce document présente différentes approches permettant de mesurer les performances de la 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 CRP de la page. Cette approche offre un aperçu rapide et facile des performances générales d'une page particulière 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 permet de capturer les métriques Real User Monitoring (RUM). Comme leur nom l'indique, ces métriques proviennent des interactions réelles des utilisateurs avec votre site et fournissent une vue précise des performances CRP réelles, telles qu'elles sont perçues par vos utilisateurs sur divers appareils et conditions de réseau.

En général, une bonne approche consiste à utiliser Lighthouse pour identifier les opportunités évidentes d'optimisation du 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 aux 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 CRP de votre page ressemblent à la capture d'écran ci-dessous.

Pour en savoir plus sur les résultats de cet audit, consultez la section 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 de navigateur émis lors du chargement de la page vous permet de capturer et d'enregistrer les performances CRP réelles de n'importe quelle page.

Chacune des étiquettes du diagramme ci-dessus 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 des différents horodatages. Pour l'instant, nous ignorons tous les horodatages liés au réseau, mais nous y reviendrons dans une prochaine leçon.

Alors, que signifient ces horodatages ?

• domLoading: il s'agit du code temporel 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 terminé d'analyser toute la construction HTML et DOM.
• domContentLoaded: marque le point lorsque le DOM est prêt et qu'aucune feuille de style ne bloque l'exécution JavaScript. Nous pouvons donc (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, l'ensemble du traitement est terminé et le téléchargement de toutes les ressources de la page (images, etc.) est terminé. En d'autres termes, l'icône de chargement a cessé de tourner.
• loadEvent: comme 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: à quel moment il doit être déclenché, quelles conditions doivent être remplies, etc. Pour les besoins de cet atelier, nous allons nous concentrer sur quelques étapes clés liées au chemin critique du rendu:

• domInteractive lorsque le DOM est prêt.
• domContentLoaded marque généralement lorsque le DOM et CSSOM sont tous les deux prêts.
  • Si aucun analyseur ne bloque JavaScript, DOMContentLoaded se déclenche immédiatement après domInteractive.
• domComplete marque la page et toutes ses sous-ressources lorsque celles-ci 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 ci-dessus peut sembler un peu intimidant à première vue, mais en réalité, c'est en fait assez simple. L'API Navigation Timing capture tous les codes temporels pertinents, et notre code attend simplement que l'événement onload se déclenche (rappelez-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.

Ceci étant fait, nous avons maintenant quelques étapes spécifiques à suivre et une fonction simple pour générer ces mesures. Notez qu'au lieu d'afficher ces métriques sur la page, vous pouvez également modifier le code pour les envoyer à un serveur d'analyse (Google Analytics le fait automatiquement). C'est un excellent moyen de surveiller les performances de vos pages et d'identifier les pages susceptibles de 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 Chrome DevTools Network pour illustrer les concepts de la CRP, ces outils ne sont actuellement pas adaptés aux mesures de la CRP, car ils ne disposent pas d'un mécanisme intégré permettant d'isoler les ressources critiques. Exécutez un audit Lighthouse pour identifier ces ressources.

Commentaires