Den kritischen Rendering-Pfad messen

Ilya Grigorik

Veröffentlicht: 31. März 2014

Die Grundlage jeder soliden Leistungsstrategie sind gute Analysen und Messinstrumente. Was nicht gemessen werden kann, kann nicht optimiert werden. 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.
• Der Ansatz der Navigation Timing API erfasst echte Nutzer Monitoring (RUM) Messwerte. Wie der Name schon sagt, werden diese Messwerte von echten Nutzern mit Ihrer Website interagieren und einen genauen Überblick reale CRP-Leistung, wie sie Ihre Nutzer bei einer Vielzahl von von Geräten und Netzwerkbedingungen.

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.

Seite 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. Ich kann Lighthouse als Chrome-Erweiterung oder NPM-Modul ausgeführt werden. nützlich für die Einbindung von Lighthouse in Continuous-Integration-Systeme.

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

Wenn Sie Lighthouse als Chrome-Erweiterung ausführen, erhalten Sie wie im folgenden Screenshot.

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

Code mit der Navigation Timing API instrumentieren

Die Kombination aus der Navigation Timing API und anderen ausgegebenen Browserereignissen während die Seite geladen wird, können Sie das reale CRP erfassen und aufzeichnen. die Leistung einer beliebigen Seite.

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 speziellen Fall zeigen wir nur einen Bruchteil der verschiedenen Zeitstempel. Derzeit überspringen wir alle netzwerkbezogenen Zeitstempel, werden aber in einer späteren Lektion darauf zurückkommen.

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: markiert den Punkt, an dem das DOM bereit ist und es keine Stylesheets gibt, die die JavaScript-Ausführung blockieren. Das bedeutet, dass wir jetzt (potenziell) die Rendering-Struktur erstellen können.
  • Viele JavaScript-Frameworks warten auf dieses Ereignis, bevor sie damit beginnen, ihre eigene Logik auszuführen. 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: Bei jedem Seitenaufbau löst der Browser den folgenden letzten Schritt aus: onload-Ereignis, das zusätzliche Anwendungslogik auslösen kann.

Die HTML-Spezifikation gibt spezifische Bedingungen für jedes Ereignis vor: wann es ausgelöst werden soll, welche Bedingungen erfüllt sein müssen und andere wichtige Überlegungen. Für unsere Zwecke konzentrieren wir uns auf einige wichtige Meilensteine in Bezug auf den 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 markiert, wenn 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 vorherige Beispiel mag auf den ersten Blick etwas abschreckend wirken, aber in Wirklichkeit ist es ziemlich einfach. Die Navigation Timing API erfasst alle relevanten Zeitstempel und unser Code wartet, bis das onload-Ereignis ausgelöst wird. Denken Sie daran, dass das onload-Ereignis nach domInteractive, domContentLoaded und domComplete ausgelöst wird. Anschließend wird die Differenz zwischen den verschiedenen Zeitstempeln berechnet.

Jetzt haben wir einige Meilensteine und eine Grundfunktion zur Ausgabe dieser Messungen. Anstatt diese Messwerte auf der Seite auszudrucken, können Sie auch den Code ändern, um diese Messwerte an einen Analyseserver zu senden. Dies geschieht automatisch in Google Analytics. So können Sie die Leistung Ihrer Seiten ganz einfach im Blick behalten und Seiten ermitteln, die von einigen Optimierungsmaßnahmen profitieren könnten.

Was ist mit den DevTools?

In diesen Dokumenten wird manchmal der Netzwerkbereich des Chrome-Entwicklertools verwendet, um CRP-Konzepte veranschaulichen, sind die Entwicklertools nicht gut für CRP geeignet. da es keinen integrierten Mechanismus zum Isolieren kritischen Ressourcen. Mit einem Lighthouse-Audit können Sie herausfinden, um solche Ressourcen zu identifizieren.

Feedback