Den kritischen Rendering-Pfad messen

Ilya Grigorik

Die Grundlage einer soliden Leistungsstrategie sind eine gute Messung und Instrumentierung. Was sich nicht messen lässt, kann auch nicht optimiert werden. In diesem Dokument werden verschiedene Ansätze zur Messung der CRP-Leistung erläutert.

• Mit dem Lighthouse-Ansatz werden eine Reihe automatisierter Tests für eine 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, und ermöglicht Ihnen, die Leistung schnell zu testen, zu iterieren und zu verbessern.
• Der Navigation Timing API-Ansatz erfasst Messwerte aus dem Real User Monitoring (RUM). 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, wie sie von Ihren Nutzern über eine Vielzahl von Geräten und Netzwerkbedingungen hinweg erfasst wird.

Im Allgemeinen ist es ein guter Ansatz, mit Lighthouse offensichtliche Möglichkeiten zur CRP-Optimierung zu identifizieren und dann Ihren Code mit der Navigation Timing API zu instrumentieren, um die Leistung Ihrer App in der Praxis zu beobachten.

Seite mit Lighthouse prüfen

Lighthouse ist ein Prüftool für Webanwendungen, das eine Reihe von Tests für eine bestimmte Seite ausführt. Die Ergebnisse der Seite werden dann in einem konsolidierten Bericht angezeigt. Sie können Lighthouse als Chrome-Erweiterung oder als NPM-Modul ausführen. Dies ist nützlich, um Lighthouse in Continuous-Integration-Systeme einzubinden.

Weitere Informationen finden Sie unter Web-Apps mit Lighthouse prüfen.

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

Weitere Informationen zu den Ergebnissen dieser Prüfung finden Sie unter Ketten kritischer Anfragen.

Code mit der Navigation Timing API instrumentieren

Durch die Kombination der Navigation Timing API und anderer Browserereignisse, die beim Laden der Seite ausgegeben werden, kannst du die tatsächliche CRP-Leistung jeder Seite erfassen und aufzeichnen.

Jedes der Labels im obigen Diagramm entspricht einem Zeitstempel mit hoher Auflösung, den der Browser für jede einzelne Seite, die er lädt, erfasst. In diesem speziellen Fall wird nur ein Bruchteil der verschiedenen Zeitstempel angezeigt. Derzeit überspringen wir alle netzwerkbezogenen Zeitstempel, aber wir kommen in einer späteren Lektion darauf zurück.

Was bedeuten diese Zeitstempel also?

• domLoading: Dies ist der Startzeitstempel des gesamten Prozesses. Der Browser beginnt gleich mit dem Parsen der ersten empfangenen Bytes des HTML-Dokuments.
• domInteractive: markiert den Punkt, an dem der Browser das Parsen der gesamten HTML- und DOM-Erstellung abgeschlossen hat.
• domContentLoaded: Gibt den Punkt an, an dem sowohl das DOM bereit ist und es keine Stylesheets gibt, die die JavaScript-Ausführung blockieren. Das bedeutet, dass wir (möglicherweise) jetzt die Renderingstruktur erstellen können.
  • Viele JavaScript-Frameworks warten auf dieses Ereignis, bevor sie ihre eigene Logik ausführen. Aus diesem Grund erfasst der Browser die Zeitstempel EventStart und EventEnd, damit wir nachvollziehen können, wie lange die 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. Das Ladesymbol dreht sich also 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 schreibt bestimmte Bedingungen für jedes einzelne Ereignis vor: wann es ausgelöst werden soll, welche Bedingungen erfüllt sein müssen usw. Für unsere Zwecke werden wir uns auf einige wichtige Meilensteine im Zusammenhang mit dem kritischen Rendering-Pfad konzentrieren:

• domInteractive gibt an, wann das DOM bereit ist.
• Mit domContentLoaded wird in der Regel angegeben, wann sowohl das DOM als auch das CSSOM bereit sind.
  • Wenn kein Parser das JavaScript blockiert, wird DOMContentLoaded sofort nach domInteractive ausgelöst.
• domComplete gibt an, wann die Seite und alle ihre 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 obige Beispiel mag auf den ersten Blick ein wenig einschüchternd wirken, ist in Wirklichkeit jedoch ziemlich einfach. Die Navigation Timing API erfasst alle relevanten Zeitstempel und unser Code wartet einfach darauf, dass das onload-Ereignis ausgelöst wird – erinnern Sie sich daran, dass das onload-Ereignis nach domInteractive, domContentLoaded und domComplete ausgelöst wird – und berechnet die Differenz zwischen den verschiedenen Zeitstempeln.

Fertig! Jetzt gibt es einige spezifische Meilensteine, die verfolgt werden müssen, und eine einfache Funktion, um diese Messungen auszugeben. Anstatt diese Messwerte auf der Seite auszudrucken, können Sie auch den Code ändern, um diese Messwerte an einen Analyseserver zu senden (Google Analytics erfolgt dies automatisch). Dadurch können Sie die Leistung Ihrer Seiten im Blick behalten und potenzielle Seiten finden, die von Optimierungsmaßnahmen profitieren könnten.

Was ist mit den Entwicklertools?

Obwohl in diesen Dokumenten manchmal der Bereich „Netzwerk“ der Chrome-Entwicklertools verwendet wird, um CRP-Konzepte zu veranschaulichen, eignet sich DevTools derzeit nicht gut für CRP-Messungen, da es keinen integrierten Mechanismus zur Isolierung kritischer Ressourcen hat. Führen Sie eine Lighthouse-Prüfung aus, um solche Ressourcen zu identifizieren.

Feedback