"Avoid Chaining Critical Requests" in Lighthouse beheben

Wie die Download-Priorität bestimmt wird

Kritische Anfragen sind die Ressourcen, die beim ersten Laden der Seite mit hoher Priorität heruntergeladen werden. Wie wird diese Priorität bestimmt?

Die Download-Priorität wird vom Browser selbst bestimmt. Der Browser folgt einer Reihe von Regeln, 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 für notwendig hält, erhalten die höchste Priorität.

Ihr Browser trifft zunächst eine fundierte Vermutung darüber, 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, Schriftarten, AJAX-Anfragen, Bilder oben auf der Seite, Bilder weiter unten auf der Seite und dann asynchrones JavaScript.

Sie können diese Prioritäten mit dem fetchpriority-Attribut überschreiben. Das Setzen von fetchpriority="high" teilt dem Browser mit, dass eine Ressource wichtiger ist, als er normalerweise annehmen würde. Das Setzen von fetchpriority="low" bewirkt das Gegenteil. Dieses Attribut hat mittlerweile eine Browser-Unterstützung von 93%. Für eine vollständige Anleitung siehe Ressourcen-Priorisierung und die Core Web Vitals.

Sie können sehen, welche Ressourcen auf Ihrer Seite eine hohe Priorität erhalten. Öffnen Sie DevTools mit Strg+Umschalt+J. Navigieren Sie zur Registerkarte "Network" (Netzwerk), klicken Sie mit der rechten Maustaste auf die Spaltennamen und wählen Sie "Priority" (Priorität).

Wie wirkt sich die Kette kritischer Anfragen auf die Ladezeit der Seite aus?

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

Ein Browser beginnt erst (vollständig) mit dem Rendern der Seite, wenn alle kritischen Ressourcen heruntergeladen wurden. Also kann jede kritische Ressource das erste Rendern einer Seite blockieren.

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

Laut dem 2025 Web Almanac bestehen nur 15% der mobilen Seiten das Audit für Render-blockierende Ressourcen. Das bedeutet, dass 85% des Internets immer noch Probleme mit kritischen Ketten lösen müssen. Dies ist einer der Hauptgründe, warum nur 55% der mobilen Origins bei First Contentful Paint "gut" abschneiden. Bei Websites, die von CoreDash überwacht werden, haben Origins mit weniger als 3 Anfragen in der kritischen Kette einen mittleren FCP von 1,2 Sekunden, verglichen mit 2,4 Sekunden für Origins mit 8 oder mehr Anfragen in der Kette.

Hinweis: Ab Lighthouse 13 (Oktober 2025) wurde dieses Audit in den Insight "Network Dependency Tree" umbenannt. Das Konzept ist dasselbe: Lighthouse analysiert die Kette von Netzwerkanfragen mit hoher Priorität und markiert sie, wenn sie zu tief ist.

Wie man "Avoid Chaining Critical Requests" in Lighthouse behebt

Sie können die Auswirkungen kritischer Anfragen auf drei Arten reduzieren:

1. Reduzieren Sie die Anzahl kritischer Ressourcen. Wandeln Sie kritische Ressourcen in nicht-kritische Ressourcen um, indem Sie sie entfernen oder zurückstellen (defer).
2. Reduzieren Sie die Anzahl kritischer Bytes. Die Reduzierung der Größe von Ressourcen im kritischen Pfad lässt sie schneller herunterladen. Gzip- oder Brotli-Komprimierung, JavaScript Tree Shaking, Bildoptimierung und Font Subsetting helfen alle.
3. Verbessern Sie die Download-Reihenfolge des kritischen Pfads. Verwenden Sie Resource Hints wie Preloading, um die Ressourcenentdeckung zu überspringen und sicherzustellen, dass die kritischen Ressourcen so schnell wie möglich heruntergeladen werden. Verwenden Sie HTTP 103 Early Hints, um mit dem Preloading von Ressourcen zu beginnen, bevor das HTML überhaupt ankommt.

Welche Option die beste ist, hängt vom Dateityp der Ressource ab:

1. HTML

Das HTML selbst wird immer mit der höchsten Priorität heruntergeladen. Die Seite ist immer Teil der kritischen Anfragekette. Deshalb ist die Seite selbst das Erste, was bei der Optimierung berücksichtigt werden muss.

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

Minifizieren: Kleiner ist immer schneller. Verwenden Sie HTML-Minifizierung, um Kommentare, Leerzeichen und Leerzeilen aus der Seite zu entfernen.

Komprimierung: Komprimieren Sie Ihr HTML mit Brotli oder Gzip. Brotli erreicht typischerweise eine 15 bis 20% bessere Komprimierung als Gzip.

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 standardmäßiger Teil der kritischen Anfragekette.

Critical CSS: Der effektivste Weg, die CSS-Kette zu durchbrechen, besteht darin, Ihr Critical CSS direkt in einem <style>-Tag im <head> zu inlinen. Dies eliminiert die Render-blockierende Netzwerkanfrage vollständig. Sie können Critical CSS durch NodeJS-Tools oder durch den Critical CSS Generator generieren. Platzieren Sie Critical CSS inline und laden Sie den Rest mit einer niedrigeren Priorität:

<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 ohne Styles angezeigt, und erst nach dem Laden des CSS wird das Styling angewendet. Der gesamte Inhalt blitzt von ungestylt zu gestylt auf (Flash of Unstyled Content). Deshalb brauchen Sie Critical CSS: Die CSS-Regeln für den sichtbaren Teil der Seite werden ge-inlined, sodass die Seite sofort korrekt aussieht, und der Rest des CSS lädt, ohne das Rendern zu blockieren.

Vermeiden Sie CSS @import-Ketten: Wenn Ihre CSS-Dateien @import verwenden, um andere CSS-Dateien zu laden, erstellen Sie eine Kette, bei der der Browser Datei A herunterladen muss, bevor er überhaupt entdeckt, dass er Datei B benötigt. Ersetzen Sie @import-Anweisungen durch separate <link>-Tags oder verketten Sie die Dateien zur Build-Zeit. Dies ist eine der häufigsten Ursachen für unnötig tiefe kritische Ketten.

Media Queries: Laden Sie nur die Styles, die Ihr Gerät benötigt. Wenn ein Besucher auf dem Handy ist, muss er die Desktop- oder Druck-Styles nicht herunterladen. Verwenden Sie das Media-Attribut, um Stylesheets für Geräte, die nicht übereinstimmen, nicht-blockierend zu machen:

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

Der Browser lädt nur Stylesheets mit hoher Priorität herunter, deren Media-Attribut mit dem aktuellen Gerät übereinstimmt. Nicht übereinstimmende Stylesheets werden mit niedriger Priorität heruntergeladen und blockieren das Rendern nicht.

Minifizieren: Entfernen Sie ungenutztes CSS. Viele Websites verwenden CSS-Bibliotheken wie Bootstrap. Diese Bibliotheken sind oft überkomplett und nicht alle Stil-Deklarationen werden verwendet. Bearbeiten Sie diese Bibliotheken über einen CSS-Präprozessor (wie Sass), um ungenutzte Stil-Gruppen zu entfernen. Präprozessoren minifizieren Ihr CSS auch, indem sie alle Leerzeichen und Zeilenumbrüche entfernen. Siehe auch Wie man 'remove unused CSS' behebt.

Komprimierung: Komprimieren Sie Stylesheets mit Brotli- oder Gzip-Komprimierung.

3. JavaScript

JavaScript-Dateien im Head der Seite werden standardmäßig mit hoher Priorität heruntergeladen und blockieren das Rendern der Seite, während sie heruntergeladen und ausgeführt werden. JavaScript ist daher ein standardmäßiger Teil der kritischen Anfragekette.

Defer und Async: Passen Sie die Priorität von JavaScript-Dateien an, indem Sie sie asynchron über das async- oder defer-Attribut laden. Async-Skripte werden parallel mit niedrigerer Priorität heruntergeladen. Deferred-Skripte werden ebenfalls parallel heruntergeladen und ihre Ausführung wird verzögert, bis das HTML geparst wurde. Für einen vollständigen Vergleich siehe async vs defer und wie sie die Core Web Vitals beeinflussen.

// blockiert Laden und Ausführung
<script src="normalscript.js"></script>
// async blockiert nicht beim Laden, aber es blockiert während der Ausführung
<script async src="asyncscript.js"></script>
// defer blockiert weder beim Laden noch bei der Ausführung
<script defer src="deferscript.js"></script>

Für weitere Techniken zum Zurückstellen von JavaScript, siehe 16 Methoden, um JavaScript zurückzustellen oder zu planen. Wenn Sie ungenutztes JavaScript haben, das nicht zurückgestellt werden kann, siehe Wie man ungenutztes JavaScript reduziert.

Code Splitting und Preloading: Wenn die Seite es nicht zulässt, dass JavaScript asynchron geladen wird, teilen Sie JavaScript in mehrere Dateien auf. Platzieren Sie den Teil, der während des Ladens der Seite kritisch ist, in einer kleinen Datei und preloaden Sie sie. Platzieren Sie das nicht-kritische JavaScript in einer anderen Datei und lassen Sie es deferred oder async laden.

Minifizieren: Verringern Sie die Anzahl der Bytes durch einen JavaScript-Minifier. Moderne Bundler wie webpack, Rollup und Vite verwenden unter der Haube terser, um JavaScript zu analysieren und es so klein wie möglich zu machen.

Komprimierung: Reduzieren Sie die Anzahl der Bytes durch Komprimierung von JavaScript via Gzip oder Brotli.

4. Web Fonts

Web Fonts sind normalerweise die letzten Dateien in der kritischen Anfragekette. Dies liegt daran, dass Web Fonts auf Entdeckung angewiesen sind: Sie werden erst geladen, wenn ein Browser herausfindet, dass sie benötigt werden. Dafür muss ein Browser zuerst das HTML analysieren und im Stylesheet nachschlagen, welche Schriftart verwendet wird.

Preloading: Wenn Sie wissen, dass Sie eine Schriftart verwenden werden, ist es schneller, diese Schriftart zu preloaden. Die Schriftart wird dann so früh wie möglich heruntergeladen, was den Einfluss auf die kritische Anfragekette minimiert. Preloaden Sie eine Schriftart, 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: Es gibt viele andere Möglichkeiten, Schriftarten schneller laden zu lassen. Siehe Wie man Google Fonts selbst hostet und Wie man sicherstellt, dass Text während des Ladens von Webfonts sichtbar bleibt.

• Verwenden Sie immer selbst gehostete Web Fonts, niemals remote gehostete Schriftarten wie Google Fonts.
• Verkleinern Sie die Schriftart mit Font Subsetting.
• Laden Sie nicht-kritische Schriftarten über die FontFace API.
• Verwenden Sie font-display: swap, um zu vermeiden, dass Schriftarten das anfängliche Rendern blockieren.
• Lassen Sie Browser ihre eigenen Schriftvarianten durch Font Synthesis generieren.

5. Bilder

Bilder, die während des Ladens der Seite im sichtbaren Viewport erscheinen, können ebenfalls eine hohe Priorität erhalten und können den kritischen Pfad beeinträchtigen. Wenn Sie sicher sind, dass ein Bild immer im sichtbaren Teil der Website erscheinen wird, preloaden Sie dieses Bild. Fügen Sie fetchpriority="high" hinzu, um dem Browser mitzuteilen, dass es das wichtigste Bild auf der Seite ist:

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

Für alle Bilder, die nicht sofort sichtbar sind, wenden Sie Lazy Loading an. Verwenden Sie loading="lazy", um das Laden des Bildes bis kurz bevor es sichtbar wird zu verzögern:

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

6. AJAX-Anfragen

AJAX-Anfragen wird immer eine hohe Priorität zugewiesen. Verschieben Sie AJAX-Anfragen daher, bis die Seite das Rendern abgeschlossen hat. Warten Sie, bis die Seite das "load"-Ereignis gesendet hat:

window.addEventListener('load', (event)=>{
  console.log('dies ist ein guter Zeitpunkt für eine AJAX-Anfrage');
});

Wenn es nicht möglich ist, die AJAX-Anfrage zu verschieben, können Sie die Ressource preloaden, um sie dem Browser früher zur Verfügung zu stellen.

7. Iframes

Iframes werden normalerweise mit hoher Priorität heruntergeladen. Da ein Iframe eigentlich eine Seite innerhalb einer Seite ist, kann ein Iframe eine erhebliche Verzögerung der Seitenladezeiten verursachen. Die Ressourcen, die der Iframe benötigt, können ebenfalls mit hoher Priorität heruntergeladen werden und ihre eigene kritische Anfragekette bilden. Die Verwendung von Iframes kann sich daher erheblich auf Ihre Core Web Vitals auswirken.

Sie können das Laden eines Iframes über das loading="lazy"-Attribut verzögern. Das macht oft einen großen Unterschied, wenn der Iframe beim Laden nicht sofort sichtbar ist. Für mehr Kontrolle über das Timing injizieren Sie den Iframe über JavaScript, um sicherzustellen, dass er nicht in der kritischen Anfragekette landet. Siehe Wie man Google Maps einbettet, ohne den PageSpeed zu beeinträchtigen und Wie man YouTube mit perfekten Core Web Vitals einbettet für Beispiele dieser Technik.

Überprüfen Sie Ihre Verbesserungen

Nach der Optimierung Ihrer kritischen Kette überprüfen Sie die Verbesserung mit Real User Monitoring. Ihr FCP und LCP sollten sich beide verbessern. Lab-Tools wie Lighthouse geben Ihnen sofortiges Feedback, aber Felddaten von echten Benutzern sind das, was für die Core Web Vitals zählt.