Den kritischen Rendering-Pfad messen

Ilya Grigorik

Veröffentlicht: 31. März 2014

Die Grundlage jeder soliden Leistungsstrategie sind gute Analysen und Messinstrumente. Was sich nicht messen lässt, kann man auch nicht optimieren. In diesem Leitfaden werden verschiedene Ansätze zur Messung der CRP-Leistung erläutert.

• Beim Lighthouse-Ansatz werden eine Reihe automatisierter Tests auf einer Seite ausgeführt und dann ein Bericht zur CRP-Leistung der Seite erstellt. Dieser Ansatz bietet einen schnellen und einfachen Überblick über die CRP-Leistung einer bestimmten Seite, die in Ihrem Browser geladen wird. So können Sie die Leistung schnell testen, iterieren und verbessern.
• Mit der Navigation Timing API werden Real User Monitoring (RUM)-Messwerte erfasst. Wie der Name schon sagt, werden diese Messwerte aus echten Nutzerinteraktionen mit Ihrer Website erfasst und bieten einen genauen Überblick über die tatsächliche CRP-Leistung, die Ihre Nutzer auf einer Vielzahl von Geräten und unter verschiedenen Netzwerkbedingungen erleben.

Im Allgemeinen ist es empfehlenswert, mit Lighthouse offensichtliche Optimierungsmöglichkeiten für die CRP zu identifizieren und dann Ihren Code mit der Navigation Timing API zu instrumentieren, um die Leistung Ihrer App in der Praxis zu überwachen.

Seiten mit Lighthouse prüfen

Lighthouse ist ein Tool zur Analyse von Webanwendungen, das eine Reihe von Tests auf einer bestimmten Seite durchführt und die Ergebnisse der Seite dann in einem konsolidierten Bericht anzeigt. Sie können Lighthouse als Chrome-Erweiterung oder NPM-Modul ausführen. Das ist nützlich, um Lighthouse in Continuous Integration-Systeme einzubinden.

Lesen Sie den Artikel Web-Apps mit Lighthouse prüfen, um loszulegen.

Wenn Sie Lighthouse als Chrome-Erweiterung ausführen, sehen die CRP-Ergebnisse Ihrer Seite in etwa so aus wie im folgenden Screenshot.

Weitere Informationen zu den Ergebnissen dieser Prüfung finden Sie unter Kritische Anfrageabfolgen.

Code mit der Navigation Timing API instrumentieren

Mit der Navigation Timing API und anderen Browserereignissen, die beim Laden der Seite gesendet werden, können Sie die tatsächliche CRP-Leistung einer beliebigen Seite erfassen und aufzeichnen.

Jedes der Labels im vorherigen Diagramm entspricht einem Zeitstempel mit hoher Auflösung, den der Browser für jede Seite erfasst, die er lädt. In diesem Fall sehen Sie nur einen Bruchteil aller Zeitstempel. Wir überspringen jetzt alle netzwerkbezogenen Zeitstempel, aber wir werden sie in einer späteren Lektion noch einmal behandeln.

Was bedeuten diese Zeitstempel?

• domLoading: Dies ist der Startzeitstempel des gesamten Prozesses. Der Browser beginnt gerade, die ersten empfangenen Bytes des HTML-Dokuments zu parsen.
• domInteractive: Gibt an, dass der Browser das gesamte HTML-Parsing abgeschlossen und das DOM-Objekt erstellt hat.
• domContentLoaded: Gibt an, dass sowohl das DOM als auch alle Stylesheets bereit sind und die JavaScript-Ausführung nicht blockiert wird. Das bedeutet, dass wir jetzt (potenziell) den Renderbaum erstellen können.
  • Viele JavaScript-Frameworks warten auf dieses Ereignis, bevor sie mit der Ausführung ihrer eigenen Logik beginnen. Aus diesem Grund erfasst der Browser die Zeitstempel EventStart und EventEnd, damit wir nachvollziehen können, wie lange diese Ausführung gedauert hat.
• domComplete: Wie der Name schon sagt, ist die gesamte Verarbeitung abgeschlossen und alle Ressourcen auf der Seite (Bilder usw.) wurden heruntergeladen. Mit anderen Worten: Das Ladesymbol dreht sich nicht mehr.
• loadEvent: Als letzten Schritt bei jedem Seitenaufbau löst der Browser ein onload-Ereignis aus, das zusätzliche Anwendungslogik auslösen kann.

Die HTML-Spezifikation legt bestimmte Bedingungen für jedes Ereignis fest: wann es ausgelöst werden soll, welche Bedingungen erfüllt sein müssen und andere wichtige Aspekte. Für unsere Zwecke konzentrieren wir uns auf einige wichtige Meilensteine im Zusammenhang mit dem kritischen Rendering-Pfad:

• domInteractive gibt an, dass das DOM bereit ist.
• domContentLoaded gibt in der Regel an, dass sowohl das DOM als auch das CSSOM bereit sind.
  • Wenn kein Parser JavaScript blockiert, wird DOMContentLoaded sofort nach domInteractive ausgelöst.
• domComplete gibt an, dass die Seite und alle zugehörigen Unterressourcen bereit sind.

<!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>

Ausprobieren

Das vorherige Beispiel mag auf den ersten Blick etwas entmutigend erscheinen, ist aber in Wirklichkeit ziemlich einfach. Die Navigation Timing API erfasst alle relevanten Zeitstempel. Unser Code wartet auf das Ereignis onload, das nach domInteractive, domContentLoaded und domComplete ausgelöst wird, und berechnet die Differenz zwischen den verschiedenen Zeitstempeln.onload

Alles in allem haben wir jetzt einige bestimmte Meilensteine zu verfolgen und eine grundlegende Funktion, um diese Messungen auszugeben. Anstatt diese Messwerte auf der Seite auszugeben, können Sie den Code auch so ändern, dass diese Messwerte an einen Analyseserver gesendet werden. In Google Analytics geschieht dies automatisch. So können Sie die Leistung Ihrer Seiten im Blick behalten und Seiten identifizieren, die von Optimierungen profitieren könnten.

Was ist mit den DevTools?

In diesen Dokumenten wird manchmal der Bereich „Netzwerk“ in den Chrome DevTools verwendet, um CRP-Konzepte zu veranschaulichen. DevTools eignet sich jedoch nicht gut für CRP-Messungen, da es keinen integrierten Mechanismus zum Isolieren kritischer Ressourcen gibt. Führen Sie eine Lighthouse-Analyse durch, um solche Ressourcen zu identifizieren.

Feedback