„Avoid Chaining Critical Requests“ in Lighthouse beheben.

Wie die Download-Priorität bestimmt wird

Critical Requests sind die Ressourcen, die beim initialen Seitenaufruf mit hoher Priorität heruntergeladen werden. Wie wird diese Priorität bestimmt?

Die Download-Priorität wird vom Browser selbst bestimmt. Der Browser folgt einem Regelwerk, um die Priorität jedes Assets zu bestimmen. Welche Elemente letztendlich die höchste Priorität erhalten, hängt von der Struktur der Seite ab. Die Elemente, die Ihr Browser für das erste Rendern der Seite als notwendig erachtet, erhalten die höchste Priorität.

Ihr Browser macht zunächst eine fundierte Einschätzung, welche Elemente am wichtigsten sind. Im Allgemeinen funktioniert die Download-Priorität so: HTML hat immer die höchste Priorität, dann Stylesheets, synchrones JavaScript, Fonts, Ajax Requests, Bilder am oberen Rand der Seite, Bilder weiter unten auf der Seite und dann asynchrones JavaScript.

Sie können selbst sehen, welche Quellen auf Ihrer Seite eine hohe Priorität erhalten. Öffnen Sie die Dev-Console mit Strg + Umschalt + J. Navigieren Sie zum Network-Tab, klicken Sie mit der rechten Maustaste auf die Spaltennamen und wählen Sie ‘Priority’

Wie beeinflusst die Critical Request Chain die Ladezeit der Seite?

Beim Laden einer Seite startet ein Browser im ‘Display Blocking’-Modus. In diesem Modus werden die wichtigsten Quellen mit hoher Priorität heruntergeladen. Das sind die kritischen Ressourcen.

Ein Browser beginnt nicht (vollständig) mit dem Rendern der Seite, bis alle kritischen Ressourcen heruntergeladen wurden. Jede kritische Ressource kann also das erste Rendern einer Seite blockieren.

Je weniger kritische Ressourcen eine Seite hat, desto weniger Arbeit muss der Browser leisten, um den ersten Inhalt auf den Bildschirm zu bringen, und desto weniger Konkurrenz gibt es um die CPU und andere Ressourcen.

Wie behebt man „Avoid Chaining Critical Requests“ in Lighthouse?

Sie können den Einfluss kritischer Anfragen auf drei Arten reduzieren:

1. Reduzieren Sie die Anzahl der kritischen Ressourcen . Wandeln Sie kritische Ressourcen in nicht-kritische Ressourcen um, indem Sie sie entfernen oder verzögert laden.
2. Reduzieren Sie die Anzahl der kritischen Bytes . Es mag offensichtlich sein, aber die Reduzierung der Bytes der Critical-Path-Ressourcen beschleunigt den Download der kritischen Ressourcen. Zum Beispiel durch Gzip-Komprimierung, JavaScript Tree Shaking, Bildoptimierung oder Font Subsetting.
3. Verbessern Sie die Download-Reihenfolge des Critical Path . Verwenden Sie Resource Hints wie Preloading, um die Resource Discovery zu überspringen und sicherzustellen, dass die kritischen Ressourcen so schnell wie möglich heruntergeladen werden.

Es gibt viele Optionen. Welche Option die beste ist, hängt vom Dateityp der Ressource ab:

1. HTML

Das HTML, also die Seite, die Sie besuchen, wird immer mit der höchsten Priorität heruntergeladen. Die Seite selbst ist immer Teil der Critical Request Chain. Deshalb ist die Seite selbst das Erste, was bei der Optimierung der Critical Request Chain berücksichtigt werden sollte.

Verzögertes Laden von Inhalten: Viele große Websites, wie Google selbst, nutzen diese Technik, um die Critical Request Chain zu reduzieren. Auf der Suchergebnisseite werden beispielsweise Teile des Inhalts, die nicht sofort benötigt werden, erst später über eine AJAX-Anfrage geladen.

Minify: Kleiner ist immer schneller, verwenden Sie HTML-Minifizierung, um Kommentare, Leerzeichen und leere Zeilen von der Seite zu entfernen.

Komprimierung : Schließlich ist es wichtig, Stylesheets ordnungsgemäß mit Brotli- oder GZIP-Komprimierung zu komprimieren

2. Stylesheets

Stylesheets im Head der Seite sind immer kritisch. Ohne Styles weiß ein Browser nicht, wie die Seite aussehen wird. Stylesheets sind daher ein Standardbestandteil der Critical Request Chain in Lighthouse.

Critical CSS: Stylesheets können mit einem einfachen Trick nicht-kritisch gemacht werden, bei dem das Stylesheet über Resource Hints vorgeladen und nach dem Preloading als Stylesheet hinzugefügt wird.
Fügen Sie den folgenden Code auf der Seite hinzu: Ihr Browser wird das Stylesheet nun mit einer niedrigeren Priorität herunterladen und das CSS als nicht-render-blocking behandeln. Er wird mit dem Rendern beginnen, ohne auf das CSS zu warten.

<link rel="preload"
      href="css.css"
      type="text/css"
      as="style"
      onload="this.onload=null;this.rel='stylesheet';"/>

Beobachten Sie, wie nun etwas Seltsames auf der Seite passiert. Zuerst wird die Seite angezeigt und erst nach dem Laden des CSS wird das Styling angewandt. Alle Inhalte werden nun von ungestyltem zu gestyltem Inhalt wechseln. Wir können dies mit Critical CSS beheben.
Critical CSS ist eine Sammlung aller CSS-Regeln, die Sie für den sichtbaren Teil der Seite benötigen. Sie können Critical CSS selbst über NodeJS oder über eine Reihe von Online-Tools generieren. Platzieren Sie dieses Critical CSS im Head der Seite und laden Sie den Rest des CSS mit einer niedrigeren Priorität.

Media Queries : Laden Sie nur die Styles für Ihr Gerät. Ihre Seite wird oft auf Mobilgeräten besucht. Sie müssen also die Styles für Desktop und Print gar nicht herunterladen. Das spart Zeit und verkürzt somit die Critical Request Chain in Lighthouse.

Verwenden Sie das media-Attribut. Das media-Attribut stellt sicher, dass ein Stylesheet nur heruntergeladen wird, wenn das Medium nicht mit dem aktuell verwendeten Medium übereinstimmt.

<link href="all.css" rel="stylesheet" media="all">
<link href="print.css" rel="stylesheet" media="print">
<link href="desktop.css" rel="stylesheet" media="screen and (min-device-width: 1024px)">

Minify: Entfernen Sie ungenutztes CSS. Viele Websites verwenden CSS-Bibliotheken wie Bootstrap. Diese Bibliotheken sind oft überkomplett und nicht alle Style-Deklarationen werden verwendet.
Es ist einfach, diese Bibliotheken über einen CSS-Präprozessor (wie SASS) zu bearbeiten. Entfernen Sie einfach die ungenutzten Style-Gruppen, indem Sie ändern, was eingebunden werden soll, um sie deutlich kleiner zu machen. Diese Präprozessoren bieten Ihnen auch die Möglichkeit, Ihr CSS zu minifizieren, indem alle Leerzeichen und Zeilenumbrüche entfernt werden.">

Komprimierung : Schließlich ist es wichtig, Stylesheets ordnungsgemäß mit Brotli- oder GZIP-Komprimierung zu komprimieren

3. Javascript

JavaScript-Dateien im Head der Seite werden standardmäßig mit hoher Priorität heruntergeladen und blockieren das Rendern der Seite während des Downloads und der Ausführung. JavaScript ist daher ein Standardbestandteil der Critical Request Chain.

Defer und Async : Passen Sie die Priorität der JavaScript-Dateien an, indem Sie sie asynchron über das async- oder defer-Attribut laden. Asynchrone Skriptdateien werden parallel mit einer niedrigeren Priorität heruntergeladen. Deferred JavaScript wird ebenfalls parallel geladen und die Ausführung der JavaScript-Datei wird verzögert, sodass die JavaScript-Ausführung auch das initiale Laden der Seite nicht blockiert.

// blocks loading and execution
<script src="normalscript.js">
// async does not block during load, but it does block during execution
<script async src="asyncscript.js">
// defer does not block both during load nor execution
<script defer src="deferscript.js">

Code Splitting und Preloading: Wenn die Seite es nicht erlaubt, JavaScript asynchron zu laden, könnte es eine gute Idee sein, JavaScript in mehrere Dateien aufzuteilen. Platzieren Sie den Teil des JavaScript, der beim Seitenaufruf kritisch ist, in einer kleinen Datei und laden Sie diese Datei vor. Platzieren Sie das nicht-kritische JavaScript in einer anderen Datei und lassen Sie es deferred oder async laden und ausführen.

Minify : Reduzieren Sie die Anzahl der Bytes auf zwei Arten durch ein JavaScript-Uglifier-Tool. Dies ist ein intelligentes Tool, das JavaScript analysiert und so klein wie möglich macht. ">

Komprimierung : Reduzieren Sie zusätzlich die Anzahl der Bytes, indem Sie JavaScript über Gzip oder Brotli komprimieren.

4. WebFonts

Webfonts sind normalerweise die letzten Dateien in der Critical Request Chain. Das liegt daran, dass Webfonts auf Discovery angewiesen sind. Sie werden erst geladen, wenn ein Browser feststellt, dass sie benötigt werden. Dafür muss ein Browser zunächst das HTML analysieren und im Stylesheet nachschlagen, welche Schriftart verwendet wird.

Preloading : Wenn Sie sicher sind, dass Sie eine Schriftart verwenden werden, ist es normalerweise schneller, diese Schriftart vorzuladen. Die Schriftart wird dann so früh wie möglich heruntergeladen, was den Einfluss auf die Critical Request Chain minimiert. Laden Sie eine Schriftart vor, indem Sie diesen Code so früh wie möglich im Head der Seite hinzufügen

<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>

Font-Strategie : Darüber hinaus gibt es viele weitere Möglichkeiten, Schriftarten schneller zu laden.

• Verwenden Sie immer lokale Webfonts und niemals remote gehostete Schriftarten wie Google Fonts.
• Verkleinern Sie die Schriftart mit Font Subsetting
• Laden Sie nicht-kritische Schriftarten über das JavaScript <a href="https://developer.mozilla.org/en-US/docs/Web/API/FontFace">FontFace Interface</a>
• Verwenden Sie display = swap, um zu verhindern, dass die Schriftart das initiale Rendern blockiert
• Lassen Sie Browser ihre eigenen Schriftvarianten durch Font Synthesis generieren

Images

Bilder, die während des Seitenladens im sichtbaren Viewport erscheinen, können ebenfalls eine hohe Priorität erhalten und den Critical Path beeinträchtigen. Wenn Sie sicher sind, dass ein Bild immer im sichtbaren Teil der Website erscheint, kann es nützlich sein, dieses Bild ebenfalls vorzuladen.

<link rel="preload" as="image" href="important-image.webp">

Für alle Bilder, die nicht sofort sichtbar sind, gehen Sie auf Nummer sicher und laden Sie diese Bilder lazy. Verwenden Sie loading = "lazy", um das Laden des Bildes zu verzögern, bis kurz bevor das Bild sichtbar wird.

<img loading="lazy" src="lazy-image.webp" width="20" height="20" alt="...">

5. AJAX Request

Ajax-Anfragen erhalten immer eine hohe Priorität. Verschieben Sie Ajax-Anfragen daher vorzugsweise, bis die Seite fertig gerendert ist. Warten Sie, bis die Seite das „load“-Event gesendet hat.

Wenn es nicht möglich ist, die AJAX-Anfrage zu verschieben, können Sie sicherstellen, dass die Ajax-Anfrage dem Browser zur Verfügung steht, indem Sie sie vorladen.

window.addEventListener('load', (event)=>{
  console.log('this is a good time for an AJAX request');
});

6. iframes

Iframes werden normalerweise mit hoher Priorität heruntergeladen. Da ein Iframe tatsächlich eine Seite innerhalb einer Seite ist, kann ein Iframe eine sehr signifikante Verzögerung bei den Seitenladezeiten verursachen. Die Ressourcen, die der Iframe benötigt, können ebenfalls mit hoher Priorität heruntergeladen werden und ihre eigene Critical Request Chain bilden. Die Verwendung von Iframes kann daher Ihren Lighthouse-Score erheblich beeinflussen.

Sie können das Laden eines Iframes über das loading = "lazy"-Attribut verzögern. Das macht oft einen Unterschied, wenn der Iframe beim Laden nicht sofort sichtbar ist. Es ist oft schneller, den Iframe über JavaScript in die Seite zu injizieren. Dies gibt Ihnen mehr Kontrolle über das Timing, um sicherzustellen, dass er nicht in der Critical Request Chain landet.