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.

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.

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}

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> <ph type="x-smartling-placeholder">

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.

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.

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.

<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>

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> <ph type="x-smartling-placeholder">

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.

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

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.