Optimierung der Website-Leistung und des kritischen Rendering-Pfads

Entspricht die Darstellungsleistung Ihrer Webseite den heutigen Standards? Beim Rendern wird die Antwort eines Servers in das Bild übersetzt, das der Browser „malt“, wenn ein Benutzer eine Website besucht. Eine schlechte Renderleistung kann zu einer relativ hohen Absprungrate führen.

Es gibt verschiedene Serverantworten, die bestimmen, ob eine Seite gerendert wird oder nicht. In diesem Artikel konzentrieren wir uns auf das anfängliche Rendern der Webseite, das mit dem Analysieren von HTML beginnt (vorausgesetzt, der Browser hat erfolgreich HTML als Antwort des Servers empfangen). Wir untersuchen die Dinge, die zu hohen Renderzeiten führen können, und wie man sie behebt.

Kritischer Renderpfad

Der Critical Rendering Path (CRP) ist der Prozess, den Ihr Browser durchläuft, um den Code in anzeigbare Pixel auf Ihrem Bildschirm umzuwandeln. Es hat mehrere Stufen, von denen einige parallel ausgeführt werden könnten, um Zeit zu sparen, aber einige Teile müssen konsequent ausgeführt werden. Hier wird es visualisiert:

Sobald der Browser die Antwort erhält, beginnt er mit der Analyse. Wenn es auf eine Abhängigkeit stößt, versucht es, es herunterzuladen.

Wenn es sich um eine Stylesheet-Datei handelt, muss der Browser sie vollständig parsen, bevor die Seite gerendert wird, und deshalb wird CSS als Rendering-Blockierung bezeichnet .

Wenn es sich um ein Skript handelt, muss der Browser: das Parsen stoppen, das Skript herunterladen und ausführen. Erst danach kann es mit dem Parsen fortfahren, denn JavaScript-Programme können den Inhalt einer Webseite (insbesondere HTML) verändern. Und deshalb heißt JS Parser Blocking .

Sobald die gesamte Analyse abgeschlossen ist, hat der Browser das Document Object Model (DOM) und das Cascading Style Sheets Object Model (CSSOM) erstellt. Wenn Sie sie miteinander kombinieren, erhalten Sie den Render-Baum. Die nicht angezeigten Teile der Seite schaffen es nicht in den Render Tree, da er nur die Daten enthält, die zum Zeichnen der Seite erforderlich sind.

Der vorletzte Schritt besteht darin, den Render-Baum in das Layout zu übersetzen. Diese Stufe wird auch Reflow genannt. Dort wird jede Position des Knotens jedes Render-Baums sowie seine Größe berechnet.

Schließlich ist der letzte Schritt Paint. Dabei werden die Pixel buchstäblich entsprechend den Daten eingefärbt, die der Browser in den vorherigen Phasen berechnet hat.

Optimierungsbezogene Schlussfolgerungen

Wie Sie sich vorstellen können, umfasst der Prozess der Website-Leistungsoptimierung Änderungen an der Website, die Folgendes reduzieren:

• Die zu übertragende Datenmenge
• Die Anzahl der Ressourcen, die der Browser herunterladen muss (insbesondere die blockierenden)
• Die Länge von CRP

Außerdem werden wir in die Details eintauchen, wie es gemacht wird, aber zuerst gibt es eine wichtige Regel zu beachten.

So messen Sie die Leistung

Eine wichtige Optimierungsregel lautet: Erst messen, nach Bedarf optimieren . Die Entwicklertools der meisten Browser haben eine Registerkarte namens Performance , und dort finden die Messungen statt. Bei der Optimierung für das schnellste anfängliche (erste) Rendering ist der Zeitpunkt der folgenden Ereignisse am wichtigsten:

• Erste Farbe
• Erste zufriedene Farbe
• Erste sinnvolle Farbe

Hier bedeutet „Paint“ das erfolgreiche Rendern einer Seite, die letzte Stufe im kritischen Rendering-Pfad. Einige Renderings können nacheinander erfolgen, da Browser versuchen, etwas so schnell wie möglich anzuzeigen und später zu aktualisieren.

Neben der Renderzeit müssen noch andere Dinge berücksichtigt werden – vor allem, wie viele blockierende Ressourcen verwendet werden und wie lange es dauert, sie herunterzuladen. Diese Informationen finden Sie auf der Registerkarte Leistung, nachdem die Messungen durchgeführt wurden.

Strategien zur Leistungsoptimierung

Angesichts dessen, was wir oben gelernt haben, gibt es drei Hauptstrategien für die Optimierung der Website-Performance:

1. Minimierung der über das Kabel zu übertragenden Datenmenge,
2. Reduzieren der Gesamtzahl der über die Leitung zu übertragenden Ressourcen und
3. Verkürzung des kritischen Renderpfades

1. Minimieren Sie die zu übertragende Datenmenge

Entfernen Sie zunächst alle nicht verwendeten Teile, wie z. B. nicht erreichbare Funktionen in JavaScript, Stile mit Selektoren, die niemals mit einem Element übereinstimmen, und HTML-Tags, die mit CSS für immer versteckt sind. Zweitens entfernen Sie alle Duplikate.

Dann empfehle ich, einen automatischen Minifizierungsprozess einzurichten. Beispielsweise sollte es alle Kommentare aus dem, was Ihr Backend bereitstellt (aber nicht den Quellcode), und alle Zeichen entfernen, die keine zusätzlichen Informationen enthalten (z. B. Leerzeichen in JS).

Nachdem dies erledigt ist, können wir als Text übrig bleiben. Dies bedeutet, dass wir einen Komprimierungsalgorithmus wie GZIP (den die meisten Browser verstehen) sicher anwenden können.

Schließlich gibt es Caching. Es hilft nicht, wenn ein Browser die Seite zum ersten Mal rendert, aber es spart viel bei späteren Besuchen. Es ist jedoch wichtig, zwei Dinge im Auge zu behalten:

• Wenn Sie ein CDN verwenden, stellen Sie sicher, dass Caching unterstützt wird und dort richtig eingestellt ist.
• Anstatt auf das Ablaufdatum der Ressourcen zu warten, möchten Sie vielleicht eine Möglichkeit haben, es früher von Ihrer Seite aus zu aktualisieren. Betten Sie die „Fingerabdrücke“ von Dateien in ihre URLs ein, um den lokalen Cache ungültig zu machen.

Natürlich sollten Caching-Richtlinien pro Ressource definiert werden. Einige ändern sich möglicherweise nur selten oder überhaupt nicht. Andere ändern sich schneller. Einige enthalten vertrauliche Informationen, andere könnten als öffentlich angesehen werden. Verwenden Sie die Direktive „private“, um zu verhindern, dass CDNs private Daten zwischenspeichern.

Die Optimierung von Webbildern könnte ebenfalls durchgeführt werden, obwohl Bildanfragen weder das Parsen noch das Rendern blockieren.

2. Reduzieren Sie die Gesamtzahl der kritischen Ressourcen

„Kritisch“ bezieht sich nur auf Ressourcen, die für die ordnungsgemäße Darstellung der Webseite erforderlich sind. Daher können wir alle Stile überspringen, die nicht direkt am Prozess beteiligt sind. Und alle Skripte auch.

Stylesheets

Um dem Browser mitzuteilen, dass bestimmte CSS-Dateien nicht benötigt werden, sollten wir media für alle Links festlegen, die auf Stylesheets verweisen. Bei diesem Ansatz behandelt der Browser nur die Ressourcen, die zu den aktuellen media (Gerätetyp, Bildschirmgröße) passen, wenn nötig, während er die Priorität aller anderen Stylesheets herabsetzt (sie werden trotzdem verarbeitet, aber nicht als Teil des kritischen Renderings). Weg). Wenn Sie beispielsweise das media="print" -Attribut zum style -Tag hinzufügen, das auf die Stile zum Ausdrucken der Seite verweist, stören diese Stile Ihren kritischen Rendering-Pfad nicht, wenn Medien nicht print werden (d. h. wenn die Seite in einem Browser).

Um den Prozess weiter zu verbessern, können Sie einige der Stile auch inline machen. Dies erspart uns mindestens einen Roundtrip zum Server, der sonst erforderlich gewesen wäre, um das Stylesheet zu erhalten.

Skripte

Wie oben erwähnt, blockieren Skripte den Parser, da sie DOM und CSSOM ändern können. Daher sollten die Skripte, die sie nicht ändern, nicht blockweise analysiert werden, was uns Zeit spart.

Um das zu implementieren, müssen alle script-Tags mit Attributen gekennzeichnet werden – entweder async oder defer .

Mit async gekennzeichnete Skripte blockieren nicht die DOM-Konstruktion oder CSSOM, da sie ausgeführt werden können, bevor CSSOM erstellt wird. Denken Sie jedoch daran, dass Inline-Skripte CSSOM sowieso blockieren, es sei denn, Sie platzieren sie über CSS.

Mit defer gekennzeichnete Skripte werden hingegen am Ende des Seitenladevorgangs ausgewertet. Daher sollten sie sich nicht auf das Dokument auswirken (andernfalls wird ein erneutes Rendern ausgelöst).

Mit anderen Worten, mit defer wird das Skript erst ausgeführt, nachdem das Seitenladeereignis ausgelöst wurde, während async das Skript im Hintergrund laufen lässt, während das Dokument geparst wird.

3. Verkürzen Sie die kritische Renderpfadlänge

Schließlich sollte die CRP-Länge auf das mögliche Minimum verkürzt werden. Teilweise werden die oben beschriebenen Ansätze dies tun.

Medienabfragen als Attribute für die Style-Tags reduzieren die Gesamtzahl der herunterzuladenden Ressourcen. Die script-Tag-Attribute defer und async verhindern, dass die entsprechenden Skripte die Analyse blockieren.

Die Minimierung, Komprimierung und Archivierung von Ressourcen mit GZIP reduziert die Größe der übertragenen Daten (wodurch auch die Datenübertragungszeit verkürzt wird).

Das Inlining einiger Stile und Skripte kann die Anzahl der Roundtrips zwischen dem Browser und dem Server reduzieren.

Was wir noch nicht besprochen haben, ist die Option, den Code zwischen den Dateien neu anzuordnen. Nach der neuesten Vorstellung von bester Performance sollte eine Website als Erstes am schnellsten ATF-Inhalte anzeigen. ATF steht für „above the fold“. Dies ist der Bereich, der sofort ohne Scrollen sichtbar ist. Daher ist es am besten, alles, was mit dem Rendern zu tun hat, so neu zu ordnen, dass die erforderlichen Stile und Skripte zuerst geladen werden und alles andere gestoppt wird - weder das Parsen noch das Rendern. Und denken Sie immer daran, vor und nach der Änderung zu messen.

Fazit: Die Optimierung umfasst Ihren gesamten Stack

Zusammenfassend umfasst die Website-Leistungsoptimierung alle Aspekte Ihrer Website-Reaktion, wie z. B. Caching, Einrichtung eines CDN, Refactoring, Ressourcenoptimierung und andere, jedoch kann all dies schrittweise erfolgen. Als Webentwickler sollten Sie diesen Artikel als Referenz verwenden und immer daran denken, die Leistung vor und nach Ihren Experimenten zu messen.

Browser-Entwickler tun ihr Bestes, um die Website-Performance für jede von Ihnen besuchte Seite zu optimieren, weshalb Browser normalerweise den sogenannten „Preloader“ implementieren. Dieser Teil des Programms scannt vor einer Ressource, die Sie in HTML angefordert haben, um mehrere Anforderungen gleichzeitig zu stellen und sie parallel auszuführen. Aus diesem Grund ist es besser, style-Tags in HTML (zeilenweise) und script-Tags nahe beieinander zu halten.

Versuchen Sie außerdem, die HTML-Aktualisierungen zu stapeln, um mehrere Layout-Ereignisse zu vermeiden, die nicht nur durch eine Änderung in DOM oder CSSOM, sondern auch durch eine Änderung der Geräteausrichtung und eine Fenstergröße ausgelöst werden.

Nützliche Ressourcen und weiterführende Literatur:

• PageSpeed-Einblicke
• Caching-Checkliste
• Eine Möglichkeit zu testen, ob GZIP für Ihre Website aktiviert ist
• High Performance Browser Networking: Ein Buch von Ilya Grigorik