Die Optimierung des Critical Rendering Path ist der Prozess der Minimierung der Zeit, die der Browser ben\u00f6tigt, um jeden Schritt der Sequenz auszuf\u00fchren, wobei der Anzeige von Inhalten, die mit der aktuellen Benutzeraktion in Zusammenhang stehen, Priorit\u00e4t einger\u00e4umt wird.<\/p><\/blockquote>\n
Ein Gro\u00dfteil dieses Prozesses bezieht sich auf den Teil der Seite, der sichtbar ist, ohne im Browserfenster nach unten zu scrollen. Dieser Abschnitt wird auch als Above the Fold<\/strong> bezeichnet. F\u00fcr eine bessere Benutzbarkeit sollte der ATF so bald wie m\u00f6glich gerendert werden, und dies kann durch die Reduzierung der Anzahl der Netzwerk-Roundtrips auf ein Minimum erreicht werden. Die Ressourcen, die zum Rendern des ATF ben\u00f6tigt werden, gelten als kritisch, und die Optimierung des Above the Fold bedeutet, die Auswirkungen kritischer Ressourcen auf die Renderzeit der ersten Seite zu minimieren.<\/p>\n In diesem Beitrag gehen wir durch die Optimierungssequenz des Critical Rendering Path.<\/p>\n Hier ist die Abfolge der Schritte, die der Browser durchf\u00fchrt, um eine Seite zu rendern:<\/p>\n Wie in Googles Leitfaden zur Optimierung des Critical Rendering Path<\/a> erl\u00e4utert, baut der Browser das Dokumentobjektmodell in einer vierstufigen Sequenz auf:<\/p>\n Wichtig dabei ist, dass der Browser das DOM inkrementell aufbaut. Dies gibt uns die M\u00f6glichkeit, die Darstellung der Seite durch die Schaffung effizienter DOM-Strukturen zu beschleunigen.<\/p>\n Wenn der Parser auf ein Im Gegensatz zur DOM-Konstruktion ist die CSSOM-Konstruktion nicht inkrementell. Der Browser kann einen Teil eines Stylesheets nicht verwenden, da Stile im selben Stylesheet verfeinert und neu deklariert werden k\u00f6nnen. Aus diesem Grund blockiert der Browser den Rendering-Prozess, bis er das gesamte CSS empfangen und analysiert hat. Dies bedeutet, dass CSS eine Rendering-Blockierung darstellt.<\/p>\n Der Browser kombiniert DOM und CSSOM im Render Tree, der die endg\u00fcltige Baumstruktur darstellt, die alle Knoten und Eigenschaften enth\u00e4lt, die zum Rendern der Seite auf dem Bildschirm verwendet werden.<\/p>\n \u201cDer Render Tree enth\u00e4lt nur die Knoten, die zum Rendern einer Seite erforderlich sind. Infolgedessen werden unsichtbare Knoten ausgelassen.\u201d<\/p><\/blockquote>\n Der Browser verwendet den Renderbaum, um die Abmessungen und die Position der Nodes als Input f\u00fcr den Painting-Prozess zu berechnen.<\/p>\n In der Layoutphase berechnet der Browser die Abmessungen und die Position jedes Knotens des Render-Trees. In dieser Phase durchquert der Browser den Render-Tree ausgehend von seiner Wurzel und erzeugt ein Box-Modell. Diese Informationen werden schlie\u00dflich dazu verwendet, jeden Knoten des Rendern-Trees in tats\u00e4chliche Pixel auf dem Bildschirm umzuwandeln.<\/p>\n Die zur Ausf\u00fchrung des gesamten Prozesses erforderliche Zeit kann variabel sein. Sie h\u00e4ngt von vielen Faktoren ab, wie z.B. der Dokumentgr\u00f6\u00dfe, der Anzahl der Anfragen, den verwendeten Stilen, dem Benutzerger\u00e4t usw.<\/p>\n Eine der wichtigsten Google-Empfehlungen ist die Priorisierung von sichtbarem Inhalt, um Above the Fold so schnell wie m\u00f6glich zu erstellen, und enth\u00e4lt zwei Hauptregeln, die zu befolgen sind:<\/p>\n Wie in Googles Leitfaden PageSpeed<\/a> gut erkl\u00e4rt wird, sind zus\u00e4tzliche Netzwerk-Roundtrips zwischen Server und Browser erforderlich, wenn die zum Rendern der ATF erforderliche Datenmenge das anf\u00e4ngliche Staufenster (14,6kb) \u00fcberschreitet. In Mobilfunknetzen mit hohen Latenzen w\u00fcrde dies das Laden der Seite erheblich verz\u00f6gern (lies mehr \u00fcber Latenz)<\/a>.<\/p>\n Der Browser baut das DOM inkrementell auf, und dies gibt uns die M\u00f6glichkeit, die zum Rendern des ATF erforderliche Zeit zu reduzieren, indem wir den HTML-Code so strukturieren, dass der obige Teil zuerst geladen und der Rest der Seite verschoben wird.<\/p>\n Aber die Optimierung endet nicht mit dem Aufbau einer effektiven DOM-Struktur. Es ist vielmehr ein Prozess der Verbesserung und Messung, der die gesamte Sequenz des Critical Rendering Path umfasst.<\/p>\n Lasst uns detaillierte werden.<\/p>\n Wir k\u00f6nnen die Datenmenge, die der Browser herunterladen wird, reduzieren, indem wir HTML-, CSS- und JavaScript-Ressourcen verkleinern, komprimieren und zwischenspeichern:<\/p>\n Jetzt wissen wir, dass der Browser warten muss, bis er den CSS-Code geholt und verarbeitet hat, bevor er die Seite rendern kann (CSS ist Render-Blocking<\/a>). Aber nicht alle CSS-Ressourcen sind render-blockierend.<\/strong><\/p>\n CSS kann an bestimmte Bedingungen angepasst werden, und wir k\u00f6nnen es mit Hilfe von Medientypen und Medienabfragen optimieren. Wenn du eine Webseite auf dem Bildschirm betrachtest, sendet der Browser eine Anfrage nach einem Printmedientyp, aber er blockiert nicht das Rendern der Seite f\u00fcr diese Ressource.<\/p>\n Nimm das folgende Das referenzierte Stylesheet dieses Tags gilt unter allen Bedingungen, unabh\u00e4ngig vom aktuellen media-typ, der Bildschirmaufl\u00f6sung, der Ger\u00e4teausrichtung usw. Das bedeutet, dass die CSS-Ressource immer render-blockierend ist.<\/p>\n Gl\u00fccklicherweise k\u00f6nnen wir unter bestimmten Bedingungen eine Anfrage f\u00fcr eine CSS-Ressource senden. Wir k\u00f6nnten Druckstile in eine separate Datei verschieben und das media-Attribut verwenden, um dem Browser mitzuteilen, dass das angegebene Stylesheet nur beim Seitenaufbau geladen werden soll und die Darstellung auf dem Bildschirm nicht blockiert werden muss:<\/p>\n Der Browser l\u00e4dt immer noch das print.css-Stylesheet herunter, aber es blockiert die Darstellung nicht. Au\u00dferdem muss der Browser weniger Daten f\u00fcr die Haupt-CSS-Datei herunterladen, was uns helfen w\u00fcrde, den Download zu beschleunigen. Wir k\u00f6nnen jede beliebige Medienabfrage auf dem Stelle sicher, dass deine Stile zum Rendern der Seite tats\u00e4chlich ben\u00f6tigt werden. Wenn dies nicht der Fall ist, kannst du dem Media-Tag-Attribut einen entsprechenden Wert hinzuf\u00fcgen und die Blockierung des Renderings aufheben.<\/p>\n Medientypen und Abfragen k\u00f6nnen uns helfen, das Rendern der Seite zu beschleunigen, aber wir k\u00f6nnen noch viel mehr tun.<\/p>\n Du kannst deine Seite schnell und einfach verbessern, indem du deinen Code direkt von deinem MyKinsta Dashboard<\/a> aus minifizierst. Nutze einfach die f\u00fcr dich angebotene Funktion zur Code-Minifizierung<\/a>, um die automatische \u00c4nderung von CSS und Javascript mit einem Klick zu aktivieren.<\/p>\n Die Zeit, die der Browser f\u00fcr das Layout des Dokuments ben\u00f6tigt, h\u00e4ngt von der Anzahl der zu layoutender DOM-Elemente und von der Komplexit\u00e4t dieser Layouts ab.<\/p>\n Die Gr\u00f6\u00dfe und Position von Rechenelementen erfordert Zeit und verringert die Leistung. Eine m\u00f6glichst einfache Gestaltung des DOM und der Verzicht auf den Einsatz von JavaScript zur Vorwegnahme des Layout-Prozesses w\u00fcrde dem Browser helfen, das Rendering der Seite zu beschleunigen (lies mehr zur Layout-Optimierung)<\/a>.<\/p>\n Streng mit dem Layout verbunden ist der Paint-Prozess, der wahrscheinlich die zeitaufwendigste Phase in der Sequenz des Critical Rendering Path ist, denn jedes Mal, wenn man das Layout eines Elements oder eine nicht-geometrische Eigenschaft \u00e4ndert, l\u00f6st der Browser ein Painting-Ereignis aus. Wenn man die Dinge in dieser Phase so einfach wie m\u00f6glich gestaltet, k\u00f6nnte der Browser den Malprozess beschleunigen. So w\u00fcrde z.B. eine Box-Shadow-Eigenschaft, die eine Art von Berechnungen erfordert, l\u00e4nger zum Zeichnen ben\u00f6tigen als eine einfarbige Randfarbe.<\/p>\n Die Optimierung des Malprozesses ist m\u00f6glicherweise nicht so einfach, und man sollte die Entwicklerwerkzeuge des Browsers nutzen, um zu messen, wie lange der Browser braucht, um jedes Malereignis auszul\u00f6sen. Weitere Informationen zu diesem Thema bietet Google\u2019s Rendering Performance Guide.<\/a><\/p>\n Wenn der Browser auf ein Skript-Tag trifft, muss er das Parsen des HTML-Codes beenden. Inline-Skripts werden genau an der Stelle ausgef\u00fchrt, an der sie sich im Dokument befinden, und blockieren die DOM-Konstruktion, bis die JS-Engine fertig l\u00e4uft. Mit anderen Worten: Inline-JavaScript kann das anf\u00e4ngliche Rendern der Seite erheblich verz\u00f6gern. Aber JavaScript erm\u00f6glicht auch die Manipulation von CSS-Eigenschaften, so dass der Browser die Skriptausf\u00fchrung pausieren muss, bis er das Herunterladen und den Aufbau des CSSOM abgeschlossen hat. Dies bedeutet, dass JavaScript die Parser blockiert<\/strong>.<\/p>\n Im Falle von externen JS-Dateien muss der Parser auch warten, bis die Ressource aus dem Cache oder vom Remote-Server geholt wurde, was die Zeit bis zum ersten Rendern der Seite stark verlangsamen k\u00f6nnte.<\/p>\n Was k\u00f6nnen wir jedoch tun, um die Zeit zu minimieren, die der Browser zum Laden und Ausf\u00fchren von JavaScript ben\u00f6tigt?<\/p>\n Das ist eine Menge Zeug, nicht wahr? Atmen wir erst einmal durch und schreiben eine Liste der bisher beschriebenen Optimierungsaktionen auf.<\/p>\n Nun, da wir die grundlegenden Konzepte der Critical Rendering Path Optimierung kennen, k\u00f6nnen wir einen Blick auf einige beliebte Optimierungs-Plugins von WordPress werfen.<\/p>\n WordPress-Benutzer k\u00f6nnen eine Reihe von Plugins nutzen, die fast jeden Aspekt des Optimierungsprozesses abdecken. Du kannst ein Plugin mit vollem Funktionsumfang installieren, oder du kannst mehrere Plugins auf einmal installieren, die jeweils spezifische Optimierungsfunktionen bieten.<\/p>\n \u201cWenn deine Webseite bei Kinsta gehostet wird, brauchst du kein Caching-Plugin, da bei Kinsta keine WordPress-Caching-Plugins ben\u00f6tigt werden.<\/a>\u201d<\/p><\/blockquote>\n Dieses einzelne Plugin deckt fast jede Phase des Optimierungsprozesses des Critical Rendering Path ab. Auf den ersten Blick kann die Plugin-Konfiguration \u00fcberw\u00e4ltigend sein, aber sobald du mit der Sequenz des Critical Rendering Path besser vertraut bist, wirst du in der Lage sein, die Vorteile eines leistungsstarken Performance-Toolsets zu nutzen.<\/p>\n Hier ist eine Liste einiger Plugin-Funktionen:<\/p>\n Dies sind nur einige der vielen Features von W3TC. Du kannst mehr \u00fcber alle Funktionen, Einstellungen und Optionen des Plugins<\/a> in dieser ausf\u00fchrlichen Anleitung lesen.<\/p>\n WP Super Cache<\/a> ist ein weiteres beliebtes Plugin f\u00fcr die Webseiten-Performance.<\/p>\n Er verf\u00fcgt \u00fcber eine gute Anzahl von Optimierungsfunktionen, ist aber weniger umfangreich als der vorherige W3 Total Cache und mag f\u00fcr Anf\u00e4nger und fortgeschrittene Benutzer erschwinglicher aussehen.<\/p>\n Im Wesentlichen bietet es Caching-Funktionen und HTTP-Komprimierung, aber es fehlt die Ressourcenminimierung und JavaScript-Optimierung mit Mit \u00fcber 1.000.000 aktiven Installationen ist Autoptimize<\/a> eines der beliebtesten kostenlosen Plugins f\u00fcr die Minifizierung.<\/p>\n Es wird mit einer Optionsseite geliefert, die in mehrere Abschnitte unterteilt ist, auf denen der Seiten-Administrator die HTML-, CSS- und JavaScript-Minifikation separat konfigurieren kann.<\/p>\n Du kannst auch unabh\u00e4ngige Skripte oder Stylesheets aggregieren und Ausnahmen f\u00fcr bestimmte Ressourcen festlegen. Dar\u00fcber hinaus erm\u00f6glicht Autoptimize die Zwischenspeicherung von minimierten Ressourcen auf der Festplatte oder im CDN und die Speicherung optimierter Assets als statische Dateien. Um die besten Einstellungen f\u00fcr Ihre WordPress-Site zu finden, k\u00f6nnen Sie unserem detaillierten Autoptimize-Leitfaden<\/a> hier folgen.<\/p>\n Andere Optimierungs-Plugins, die du vielleicht ausprobieren m\u00f6chtest:<\/p>\n Swift Performance<\/a> ist ein weiteres Plugin, das du dir vielleicht ansehen solltest. Hierbei handelt es sich um ein Premium-Plugin, das dir helfen kann, deine Leistungswerte zu steigern, und das speziell entwickelt wurde, damit du versuchen kannst, die 100\/100 Google PageSpeed Insights-Ergebnisse<\/a> zu erreichen.<\/p>\n Einige seiner Hauptmerkmale sind<\/p>\n Einen tieferen Einblick in die WordPress-Optimierungs-Plugins findest du unter Wie man Render-Blockierungen von JavaScript und CSS eliminiert.<\/a><\/p>\n Die Optimierung des Critical Rendering Path ist ein Prozess der Verbesserung und Messung, der ein klares Verst\u00e4ndnis jeder Aufgabe erfordert, die der Browser ausf\u00fchrt, um Code in Pixel umzuwandeln und so eine Seite auf dem Bildschirm zu rendern. Du kannst mehr \u00fcber den Critical Rendering Path im Optimierungsleitfaden von Google<\/a> erfahren.<\/p>\n Hier im Kinsta-Blog versuchen wir, jeden Aspekt der Leistungsoptimierung abzudecken. Hier findest du eine Liste weiterer Artikel:<\/p>\n Wie lange dauert es, den Critical Rendering Path deiner Webseiten zu optimieren? Und welche Aspekte des Optimierungsprozesses sind f\u00fcr dich am schwierigsten zu meistern? Lasst es uns in den folgenden Kommentaren wissen.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":" Der Critical Rendering Path ist die Abfolge von Aufgaben, die der Browser ausf\u00fchrt, um eine Seite zun\u00e4chst auf dem Bildschirm zu rendern, d.h. HTML-, CSS- und …<\/p>\n","protected":false},"author":36,"featured_media":34159,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_kinsta_gated_content":false,"_kinsta_gated_content_redirect":"","footnotes":""},"tags":[30,29],"topic":[999,1005],"class_list":["post-34088","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","tag-webperf","tag-wordpress","topic-wordpress-entwicklung","topic-wordpress-leistung"],"yoast_head":"\n\n
Die Abfolge des Critical Rendering Path<\/h2>\n
\n
Das DOM<\/h3>\n
\n
![\"DOM](\"https:\/\/kinsta.com\/de\/wp-content\/uploads\/sites\/5\/2017\/11\/dom.png\")
Die CSSOM<\/h3>\n
link<\/code>-Tag st\u00f6\u00dft, das auf ein externes CSS-Stylesheet verweist, blockiert er das Parsen und sendet eine Anforderung f\u00fcr diese Ressource aus. Sobald die CSS-Datei empfangen wurde, beginnt der Browser mit dem Aufbau einer Baumdatenstruktur aus CSS-Knoten.<\/p>\n\n
![\"CSSOM](\"https:\/\/kinsta.com\/de\/wp-content\/uploads\/sites\/5\/2017\/11\/cssom.png\")
Der Render Tree<\/h3>\n
![\"Render](\"https:\/\/kinsta.com\/de\/wp-content\/uploads\/sites\/5\/2017\/11\/render-tree.png\")
Layout und Paint<\/h3>\n
Critical Rendering Path Optimierung<\/h2>\n
\n
![\"Der](\"https:\/\/kinsta.com\/de\/wp-content\/uploads\/sites\/5\/2017\/11\/above-the-fold.png\")
Ressourcendimensionen minimieren<\/h2>\n
\n
CSS optimieren<\/h2>\n
link<\/code>-Tag:<\/p>\n<link rel=\"stylesheet\" href=\"style.css\" \/><\/code><\/pre>\n<link rel=\"stylesheet\" href=\"print.css\" media=\"print\" \/><\/code><\/pre>\nlink<\/code>-Attribut angeben, so dass wir das CSS in mehrere Dateien aufteilen und diese bedingt laden k\u00f6nnen:<\/p>\n<link rel=\"stylesheet\" href=\"style.css\" media=\"screen\" \/>\n<link rel=\"stylesheet\" href=\"portrait.css\" media=\"orientation:portrait\" \/>\n<link rel=\"stylesheet\" href=\"widescreen.css\" media=\"(min-width: 42rem)\" \/><\/code><\/pre>\n\n
Beschleunigung von Layout- und Zeichenprozessen<\/h2>\n
\n
![\"-Chrome](\"https:\/\/kinsta.com\/de\/wp-content\/uploads\/sites\/5\/2017\/11\/paint-flashing-1024x491.png\")
JavaScript-Blockierung aufheben<\/h2>\n
\n
async<\/code> Attribut des skript<\/code>-Tags weist den Browser an, das Skript m\u00f6glichst async<\/code> auszuf\u00fchren, ohne die DOM-Konstruktion zu blockieren. Der Browser sendet die HTTP-Anforderung f\u00fcr das Skript und f\u00e4hrt mit dem Parsen des DOM fort. Das Skript blockiert auch nicht die CSSOM-Konstruktion, d.h. es blockiert auch nicht den Critical Rendering Path (weitere Informationen \u00fcber Skript-Tag-Attribute findest du in den MDN-Docs<\/a>).<\/li>\ndefer<\/code>-Attribut des script<\/code>-Tags weist den Browser an, das Script auszuf\u00fchren, nachdem das Dokument geparst wurde, aber bevor das DOMContentLoaded<\/code>-Ereignis ausgel\u00f6st wird. Dieses Attribut darf nicht verwendet werden, wenn das src-Attribut nicht vorhanden ist, d.h. bei Inline-Skripten (lies mehr \u00fcber Mozilla-Hacks<\/a>)<\/li>\nZusammenfassung der Optimierungsregeln<\/h2>\n
\n
\n
link<\/code> tags<\/li>\n\n
defer<\/code>-Attribut in den Skript-Tags verwenden<\/li>\nasync<\/code>-Attribut in den Skript-Tags verwenden<\/li>\nskript<\/code>-Tags an den unteren Rand des Dokuments verschieben<\/li>\n<\/ul>\n<\/li>\n<\/ul>\nOptimierung des Critical Rendering Path in WordPress<\/h2>\n
W3 Total Cache<\/h3>\n
![\"W3](\"https:\/\/kinsta.com\/de\/wp-content\/uploads\/sites\/5\/2020\/08\/total-cache-wordpress-plugin-deu.jpg\")
<\/a>\n
async<\/code> und defer<\/code><\/li>\n![\"W3](\"https:\/\/kinsta.com\/de\/wp-content\/uploads\/sites\/5\/2017\/11\/w3tc-js-minify.png\")
WP Super Cache<\/h3>\n
![\"WP](\"https:\/\/kinsta.com\/de\/wp-content\/uploads\/sites\/5\/2017\/11\/wp-super-cache-wordpress-plugin.png\")
<\/a>![\"WordPress](\"https:\/\/kinsta.com\/de\/wp-content\/uploads\/sites\/5\/2017\/11\/wp-super-cache.png\")
async<\/code>– und defer<\/code>-Attributen. Mehr als eine Million aktive Installationen beweisen jedoch, dass das Plugin einen Versuch wert ist.<\/p>\n![\"GZIP-Option](\"https:\/\/kinsta.com\/de\/wp-content\/uploads\/sites\/5\/2017\/11\/wpsc-gzip.png\")
Autoptimize<\/h3>\n
![\"Autoptimize](\"https:\/\/kinsta.com\/de\/wp-content\/uploads\/sites\/5\/2017\/11\/autoptimize-wordpress-plugin.jpg\")
<\/a>![\"Option](\"https:\/\/kinsta.com\/de\/wp-content\/uploads\/sites\/5\/2017\/11\/optimize-html.png\")
\n
Swift Performance<\/h3>\n
![\"Swift](\"https:\/\/kinsta.com\/de\/wp-content\/uploads\/sites\/5\/2017\/11\/swift-performance-wordpress-plugin.png\")
<\/a>\n
Fazit<\/h2>\n
\n