Laden von Ressourcen optimieren

Im vorherigen Modul haben wir uns mit einer Theorie hinter dem kritischen Rendering-Pfad befasst und wie Ressourcen, die das Rendering blockieren und den Parser blockieren, das erste Rendering einer Seite. Jetzt kennen Sie einige der Theorien hinter den sind Sie bereit, einige Techniken zur Optimierung der wichtigsten Rendering-Pfad.

Beim Laden einer Seite wird im HTML-Code auf viele Ressourcen verwiesen, die ein Seite mit ihrem Aussehen und Layout über CSS und ihrer Interaktivität über JavaScript. In diesem Modul werden einige wichtige Konzepte und ihre Auswirkungen auf die Ladezeit einer Seite behandelt.

Rendering-Blockierung

Wie im vorherigen Modul erläutert, ist CSS eine Ressource, die das render-blocking soll. da es den Browser daran hindert, Inhalte zu rendern, bis das CSS-Objektmodell (CSSOM) erstellt wird. Der Browser blockiert das Rendering, um ein Flash- Unstyled Content (FOUC), was aus Sicht der Nutzerfreundlichkeit nicht erwünscht ist.

Im vorherigen Video gibt es einen kurzen FOUC, in dem Sie die Seite sehen können, ohne für jeden Stil. Anschließend werden alle Stile angewendet, sobald der CSS-Code der Seite vollständig aus dem Netzwerk geladen wurde und die Version der Seite ohne Design sofort durch die Version mit benutzerdefiniertem Stil ersetzt.

Im Allgemeinen ist ein FOUC etwas, das man normalerweise nicht sieht, aber das Konzept ist es wichtig zu verstehen, damit Sie wissen, warum der Browser das Rendering blockiert. bis CSS heruntergeladen und auf die Seite angewendet wurde. Rendering-Blockierung ist nicht unbedingt unerwünscht, aber Sie sollten die Lebensdauer Ihres Geräts und dafür sorgen, dass Ihr Preisvergleichsportal optimiert wird.

Parserblockierung

Eine Ressource, die den Parser blockiert, unterbricht den HTML-Parser, z. B. ein <script>. -Element ohne async- oder defer-Attribute. Wenn der Parser auf eine <script>-Element enthält, muss der Browser das Skript vor dem Ausführen mit dem Parsen des restlichen HTML-Codes. Dies ist beabsichtigt, da Skripte möglicherweise das DOM während der Erstellung ändern oder darauf zugreifen.

<!-- This is a parser-blocking script: -->
<script src="/script.js"></script>

Wenn externe JavaScript-Dateien (ohne async oder defer) verwendet werden, ist der Parser bis zum Herunterladen, Parsen und Entfernen der Datei blockiert wird. ausgeführt haben. Bei Verwendung von Inline-JavaScript wird der Parser ebenfalls blockiert, bis wird das Inline-Skript geparst und ausgeführt.

<ph type="x-smartling-placeholder">

Preload Scanner

Der Preload Scanner ist eine Browseroptimierung in Form eines sekundären HTML-Codes. Parser, der die HTML-Rohantwort scannt, um diese zu finden und spekulativ abzurufen. bevor der primäre HTML-Parser sie erkennen würde. Für Der Preload-Scanner ermöglicht dem Browser beispielsweise, Ressource, die in einem <img>-Element angegeben ist, auch wenn der HTML-Parser blockiert ist beim Abrufen und Verarbeiten von Ressourcen wie CSS und JavaScript.

Um den Preload-Scanner nutzen zu können, sollten wichtige Ressourcen einbezogen werden. in HTML-Markup, das vom Server gesendet wird. Die folgenden Lademuster für Ressourcen sind vom Preload-Scanner nicht erkannt werden:

  • Bilder, die von CSS mithilfe der Eigenschaft background-image geladen werden. Dieses Bild Referenzen befinden sich in CSS und können nicht vom Preload-Scanner erkannt werden.
  • Dynamisch geladene Skripts in Form von eingefügtem <script>-Element-Markup in das DOM mithilfe von JavaScript oder Modulen, die mit dynamischen import() geladen werden.
  • Mit JavaScript auf dem Client gerendertes HTML. Solche Auszeichnungen sind in in JavaScript-Ressourcen enthält und beim Vorabladen nicht sichtbar ist Scanner.
  • CSS-@import-Deklarationen.

Bei diesen Lademustern handelt es sich alle um spät entdeckte Ressourcen. profitieren nicht vom Preload Scanner. Vermeiden Sie sie nach Möglichkeit. Wenn solche Muster zu vermeiden, ist nicht möglich. Sie könnten aber Mit dem preload-Hinweis lassen sich Verzögerungen bei der Ressourcenerkennung vermeiden.

<ph type="x-smartling-placeholder">

CSS

CSS bestimmt die Darstellung und das Layout einer Seite. Wie bereits erwähnt, ist eine Ressource, die das Rendering blockiert, sodass die Optimierung Ihres CSS Auswirkungen auf die Seitenladezeit insgesamt.

Minimierung

Durch das Reduzieren von CSS-Dateien wird die Dateigröße einer CSS-Ressource reduziert, sodass sie schneller herunterladen zu können. Dies geschieht in erster Linie, indem Inhalte aus einem Quelldatei wie Leerzeichen und andere unsichtbare Zeichen das Ergebnis in eine neu optimierte Datei:

/* Unminified CSS: */

/* Heading 1 */
h1 {
  font-size: 2em;
  color: #000000;
}

/* Heading 2 */
h2 {
  font-size: 1.5em;
  color: #000000;
}
/* Minified CSS: */
h1,h2{color:#000}h1{font-size:2em}h2{font-size:1.5em}
<ph type="x-smartling-placeholder">

In ihrer einfachsten Form ist die CSS-Reduzierung eine effektive Optimierung, den FCP-Wert Ihrer Website und in einigen Fällen sogar den LCP verbessern. Tools wie Bundler können diese Optimierung in der Produktion automatisch für dich durchführen. baut.

Nicht verwendete CSS entfernen

Vor dem Rendern von Inhalten muss der Browser alle Stylesheets hinzugefügt. Die für das Parsing erforderliche Zeit umfasst auch Stile, auf der aktuellen Seite nicht verwendet werden. Wenn Sie einen Bundler verwenden, der alle in einer einzigen Datei zusammenfassen, laden Ihre Nutzer wahrscheinlich mehr CSS- die zum Rendern der aktuellen Seite erforderlich sind.

Mit dem Abdeckungstool in Chrome können Sie nicht verwendeten CSS-Code für die aktuelle Seite finden. Entwicklertools.

<ph type="x-smartling-placeholder">
</ph> Screenshot des Abdeckungstools in den Chrome-Entwicklertools. Im unteren Bereich wird eine CSS-Datei ausgewählt, die eine erhebliche Menge an CSS enthält, die vom aktuellen Seitenlayout nicht verwendet wird. <ph type="x-smartling-placeholder">
</ph> Das Abdeckungstool in den Chrome-Entwicklertools ist nützlich, um CSS zu erkennen (und JavaScript), das von der aktuellen Seite nicht verwendet wird. Damit lassen sich CSS-Dateien aufteilen, in mehrere Ressourcen aufzuteilen, die von verschiedenen Seiten geladen werden, viel größeres CSS-Set ausliefern, das das Rendern der Seite verzögern kann.

Wenn Sie nicht verwendetes CSS entfernen, reduziert sich nicht nur die Downloadgröße, sondern auch die Anzahl der Downloads gleich doppelt. optimieren Sie die Konstruktion der Rendering-Struktur, da der Browser weniger CSS-Regeln verarbeiten.

<ph type="x-smartling-placeholder">

CSS-@import-Deklarationen vermeiden

Auch wenn es praktisch erscheint, sollten Sie @import-Deklarationen in CSS vermeiden:

/* Don't do this: */
@import url('style.css');

Ähnlich wie das Element <link> in HTML funktioniert auch die Deklaration @import in CSS können Sie eine externe CSS-Ressource aus einem Stylesheet importieren. Die Der Hauptunterschied zwischen diesen beiden Ansätzen besteht darin, dass das HTML-Element <link> ist Teil der HTML-Antwort und daher viel früher erkannt als ein CSS-Code Datei, die durch eine @import-Deklaration heruntergeladen wurde.

Der Grund dafür ist, dass eine @import-Deklaration gefunden wird, muss die CSS-Datei, in der sie enthalten ist, zuerst heruntergeladen werden. Dieses zu einer sogenannten Anfragekette, die – im Fall von Preisvergleichsportalen – wie lange es dauert, bis eine Seite zum ersten Mal gerendert wird. Ein weiterer Nachteil ist, Mit einer @import-Deklaration geladene Stylesheets können vom den Scanner vorab laden, sodass sie zu spät entdeckten Ressourcen werden, die das Rendering blockieren.

<!-- Do this instead: -->
<link rel="stylesheet" href="style.css">

In den meisten Fällen können Sie das @import durch einen <link rel="stylesheet">-Element. <link>-Elemente ermöglichen die Verwendung von gleichzeitig heruntergeladen und die Gesamtladezeit reduziert (im Gegensatz zu @import) -Deklarationen verwenden, mit denen Stylesheets nacheinander heruntergeladen werden.

<ph type="x-smartling-placeholder">

Wichtiges CSS inline einbinden

Die Zeit, die für das Herunterladen von CSS-Dateien benötigt wird, kann den FCP einer Seite erhöhen. Inliner kritische Stile im Dokument <head> eliminiert die Netzwerkanfrage für CSS-Ressource und kann bei korrekter Anwendung die anfänglichen Ladezeiten verbessern, wenn ein Der Browser-Cache des Users ist nicht aufgefüllt. Das verbleibende CSS kann geladen werden asynchron oder wird am Ende des <body>-Elements angehängt.

<ph type="x-smartling-placeholder">
<head>
  <title>Page Title</title>
  <!-- ... -->
  <style>h1,h2{color:#000}h1{font-size:2em}h2{font-size:1.5em}</style>
</head>
<body>
  <!-- Other page markup... -->
  <link rel="stylesheet" href="non-critical.css">
</body>
<ph type="x-smartling-placeholder">

Der Nachteil ist, dass beim Inline-Formatieren einer großen Menge von CSS mehr Bytes zum ersten HTML-Antwort. Da HTML-Ressourcen häufig nicht sehr lange im Cache gespeichert werden können, Dies bedeutet, dass das eingefügte CSS nicht für nachfolgende Seiten, die möglicherweise in externen Stylesheets denselben CSS-Code. Testen und analysieren Sie die Leistung um sicherzustellen, dass sich die Nachteile lohnen.

CSS-Demos

JavaScript

Der Großteil der Interaktivität im Web ist auf JavaScript zurückzuführen, aber es hat seinen Preis. Wenn Sie zu viel JavaScript senden, reagiert Ihre Webseite möglicherweise nur langsam zu laden, und kann sogar zu Reaktionsproblemen führen, die Interaktionen verlangsamen. was für Nutzende frustrierend sein kann.

JavaScript, das das Rendering blockiert

Beim Laden von <script>-Elementen ohne die Attribute defer oder async wird das Attribut blockiert der Browser das Parsing und Rendern, bis das Skript heruntergeladen, geparst und ausgeführt haben. Ebenso blockieren Inline-Skripts den Parser, bis das Skript geparst wird. und ausgeführt werden.

async im Vergleich zu defer

Mit async und defer können externe Skripts geladen werden, ohne den HTML-Code zu blockieren parser, während Skripts (einschließlich Inline-Skripts) mit type="module" automatisch aufgeschoben werden. Es gibt jedoch einige Unterschiede zwischen async und defer, sind wichtig zu verstehen.

<ph type="x-smartling-placeholder">
</ph> Darstellung verschiedener Mechanismen zum Laden von Skripts, die alle Details zu den Parser-, Abruf- und Ausführungsrollen basierend auf verschiedenen verwendeten Attributen wie async, defer und type=&#39;module&#39; enthalten und eine Kombination aus allen drei. <ph type="x-smartling-placeholder">
</ph> Quelle: https://html.spec.whatwg.org/multipage/scripting.html

Mit async geladene Skripts werden sofort nach dem Download geparst und ausgeführt. Mit defer geladene Skripts werden dagegen ausgeführt, wenn das Parsen von HTML-Dokumenten ein abgeschlossen – geschieht gleichzeitig mit dem DOMContentLoaded-Ereignis des Browsers. Außerdem können async-Scripts falsch ausgeführt werden, defer-Scripts jedoch nicht. in der Reihenfolge ausgeführt, in der sie im Markup angezeigt werden.

<ph type="x-smartling-placeholder">

Clientseitiges Rendering

Im Allgemeinen sollten Sie JavaScript nicht verwenden, um kritische Inhalte oder LCP-Element der Seite. Dies wird als clientseitiges Rendering bezeichnet und ist eine Technik, wird häufig in Single-Page-Anwendungen (SPAs) eingesetzt.

Von JavaScript gerendertes Markup umgeht den Preload-Scanner, da die Ressourcen die im vom Client gerenderten Markup enthalten sind, sind dadurch nicht sichtbar. Dieses kann der Download wichtiger Ressourcen wie eines LCP-Bilds verzögern. Der Browser der Download des LCP-Bildes beginnt, nachdem das Skript ausgeführt wurde, zum DOM. Das Skript kann wiederum erst ausgeführt werden, nachdem es gefunden, heruntergeladen und geparst. Dies wird als kritische Anfrage bezeichnet und sollten vermieden werden.

Beim Rendern von JavaScript-Code ist außerdem die Wahrscheinlichkeit höher, langen Aufgaben als Markup, das als Reaktion auf eine Navigation vom Server heruntergeladen wird. Eine häufige Verwendung des clientseitigen HTML-Renderings kann sich negativ auf Interaktionslatenz. Dies gilt insbesondere, wenn das DOM einer Seite Sehr groß, was zu erheblichen Rendering-Aufwand führt, wenn JavaScript Änderungen daran vornimmt das DOM.

Minimierung

Ähnlich wie bei CSS wird durch das Reduzieren von JavaScript die Dateigröße einer Skriptressource reduziert. Dies kann zu schnelleren Downloads führen, das schnellere Parsen und Kompilieren von JavaScript.

Außerdem geht die Komprimierung von JavaScript noch einen Schritt weiter anderer Assets wie CSS. Wenn JavaScript minimiert wird, wird es nicht nur entfernt. von Dingen wie Leerzeichen, Tabulatoren und Kommentaren, aber Symbole in der Quelle JavaScript gekürzt werden. Dieser Vorgang wird auch als Uglifizierung bezeichnet. Bis sehen Sie den Unterschied, sehen Sie sich den folgenden JavaScript-Quellcode an:

// Unuglified JavaScript source code:
export function injectScript () {
  const scriptElement = document.createElement('script');
  scriptElement.src = '/js/scripts.js';
  scriptElement.type = 'module';

  document.body.appendChild(scriptElement);
}

Wenn der vorherige JavaScript-Quellcode uglifiziert ist, sieht das Ergebnis möglicherweise so aus: etwa das folgende Code-Snippet:

// Uglified JavaScript production code:
export function injectScript(){const t=document.createElement("script");t.src="/js/scripts.js",t.type="module",document.body.appendChild(t)}

Im obigen Snippet sehen Sie, dass die menschenlesbare Variable scriptElement in der Quelle wird zu t gekürzt. Bei Anwendung auf eine große können die Einsparungen beträchtlich sein, ohne dass die Funktionen, die vom JavaScript einer Website für die Produktion bereitgestellt werden.

Wenn Sie einen Bundler zur Verarbeitung des Quellcodes Ihrer Website verwenden, wird bei Produktions-Builds häufig automatisch ausgeführt. Uglifier, z. B. Terser, zum Beispiel hochgradig konfigurierbar sind, sodass Sie Aggressivität des Glifizierungsalgorithmus an, um maximale Einsparungen zu erzielen. In der Regel reichen die Standardeinstellungen der Gruppierungstools jedoch aus, das richtige Gleichgewicht zwischen Ausgabegröße und Beibehaltung der Kapazitäten.

JavaScript-Demos

Wissen testen

Wie lassen sich am besten mehrere CSS-Dateien in den Browser laden?

Mehrere <link>-Elemente.
Die CSS-Deklaration (@import).

Was macht der Browser Preload Scanner?

Erkennt <link rel="preload"> Elemente in eine HTML-Ressource.
Es ist ein sekundärer HTML-Parser, der Roh-Markup untersucht, um diese zu erkennen. , bevor der DOM-Parser sie finden kann, um sie schneller zu ermitteln.

Warum blockiert der Browser das Parsen von HTML vorübergehend standardmäßig, wenn JavaScript-Ressourcen herunterladen?

Weil Skripts das DOM ändern oder anderweitig darauf zugreifen können.
Weil die Auswertung von JavaScript eine sehr CPU-intensive Aufgabe ist und Durch das HTML-Parsing erhält die CPU mehr Bandbreite, um das Laden der Skripts abzuschließen.
Um zu verhindern, dass ein „Flash of Unstyled Content“ (FOUC) angezeigt wird

Nächster Schritt: Browser mit Ressourcenhinweisen unterstützen

Sie wissen jetzt, wie im <head>-Element geladene Ressourcen auf den anfänglichen Seitenaufbau und verschiedene Messwerte auswirken. Im nächsten werden Hinweise zu Ressourcen erläutert. Sie erfahren, wie Sie diese Hinweise im Browser, um Ressourcen zu laden und ursprungsübergreifende Verbindungen zu öffnen schneller als der Browser ohne sie.