Network-Dependency-Tree in Lighthouse: Lesen und beheben

Was ist der Network-Dependency-Tree in PageSpeed Insights?

Der Network-Dependency-Tree in Lighthouse (vor Lighthouse 13: „Avoid chaining critical requests“) zeigt, welche Dateien deine Seite zuerst braucht und worauf jede einzelne warten musste: Jede Datei, die in einer anderen Datei steckt, erzeugt Wartezeit. Hoste deine Fonts auf deiner eigenen Domain, binde Stylesheets direkt im HTML ein statt per @import, und nutze Preconnect nur dort, wo eine kritische Datei von einer Domain stammt, die du nicht vermeiden kannst.

Du willst die schnelle Lösung? Spring zu Webfonts, WordPress-@import, Shopify oder Dateien, die ein Skript nachlädt.

Wie liest du den Network-Dependency-Tree?

Lighthouse 13 und PageSpeed Insights beschreiben den Hinweis so: „Avoid chaining critical requests by reducing the length of chains, reducing the download size of resources, or deferring the download of unnecessary resources to improve page load“. Er ersetzt „Avoid chaining critical requests“ (früher „Minimize critical requests depth“) und „Preconnect to required origins“. Deshalb stehen zwei Preconnect-Tabellen unter dem Baum.

Der folgende Report stammt von der Startseite einer Zahnarztpraxis, die ich wie eine WordPress-Site aufgebaut habe: Das Stylesheet des Child-Themes importiert das des Parent-Themes, dieses importiert Google Fonts, und die Icons kommen per CDN von Font Awesome.

Lighthouse 13.6 auf Mobilgeräten, DevTools-Throttling (Slow 4G, 4x CPU).

• Eine eingerückte Zeile steht für eine Datei, die der Browser erst in der Datei eine Ebene darüber gefunden hat. Er musste also auf diese Datei warten. Zeilen auf derselben Ebene laden parallel herunter, wie die drei Font-Dateien unter Googles css2-Stylesheet.
• Zeit und KiB in einer Zeile zeigen, wann diese Datei geladen war (ab Beginn des Seitenaufrufs gezählt) und wie groß sie ist.
• Maximum critical path latency ist die Dauer der langsamsten Kette, orange markiert. Auf der Zahnarztseite ist das der 155 KiB große Icon-Font zwei Ebenen tief: Er trifft erst nach den Google Fonts ein, die vier Ebenen tiefer liegen.
• LCP und Unscored: Der Hinweis fließt nicht in deinen Performance-Score ein. Aber seine Stylesheets blockieren den First Paint – und LCP kann niemals davor liegen.

PageSpeed Insights misst den Ladevorgang ohne Throttling: Sein Baum zeigt deutlich kürzere Zeiten als dieser Screenshot.

Warum verzögert eine Kette von Dateien die Seite?

Auf der Zahnarztseite blickt der Besucher zuerst auf einen weißen Bildschirm. Dann sieht er Text in einem Fallback-Font, der umspringt, sobald die Webfonts eintreffen – mit leeren Kreisen dort, wo die Icons hingehören.

Der Browser liest das HTML vorab ein (über den Preload-Scanner) und fordert alle dort gefundenen Dateien sofort an. Eine Datei, die erst in einer anderen Datei genannt wird, entdeckt er erst, wenn diese andere Datei angekommen ist: ein Font in einem Stylesheet, ein Stylesheet hinter einem @import, ein Skript, das ein anderes Skript nachlädt. Jede Ebene bedeutet einen weiteren Roundtrip zum Server, bevor der nächste Request überhaupt starten kann.

Eine Datei auf einer anderen Domain wartet noch länger: Der Browser baut zuerst eine Verbindung auf (DNS, TCP und TLS). Im Mobilfunknetz dauert das ein Vielfaches eines Requests über eine bestehende Verbindung. Auf der Zahnarztseite liegen die Google Fonts vier Ebenen unter dem HTML, hinter zwei @import-Regeln – die letzten beiden auf neuen Domains (fonts.googleapis.com, fonts.gstatic.com). Render-blocking requests erklärt, warum ein Stylesheet den First Paint aufhält.

Wie viel schneller ist die Seite mit einem flachen Baum?

Nach dem Fix rendert die Zahnarztseite eine Sekunde früher und zeigt ihre eigenen Fonts fast zwei Sekunden früher an. Ich habe drei Versionen gemessen. „Vorher“ nutzt die zwei @import-Regeln. „Links“ bindet dieselben Dateien direkt im HTML ein, wie WordPress es mit wp_enqueue_style ausgibt. „Nachher“ vereint Parent- und Child-Stylesheet in einer Datei, legt die Fonts auf die eigene Domain (alle drei per Preload geladen) und bindet die Icons als Inline-SVG ein.

Zeiten in Sekunden, auf einem gedrosselten Smartphone (Slow 4G, 4x langsamere CPU). Ebenen und langsamste Kette (Maximum critical path latency im Report) aus Lighthouse 13.6 mit derselben Drosselung.

Zwei Sekunden nach Ladestart auf demselben gedrosselten Smartphone.

„Links“ bringt bereits den Großteil des Gewinns beim First Paint, weil die zwei @import-Ebenen wegfallen – während Fonts und Icons noch auf ihre eigenen Domains warten. Der LCP (das Hero-Bild) ist nach dem Fix 0,4 s früher da. „Links“ erreicht den frühesten LCP, weil das Bild die Bandbreite fast für sich allein hat. In „Nachher“ teilen sich die drei per Preload geladenen Fonts die Bandbreite mit dem Bild. Deshalb lädt der Fix nur ein oder zwei vorab.

Um zu sehen, ob echte Besucher auf die Kette warten müssen, zerlege den mobilen LCP in CoreDash in seine Teilphasen: Späte Stylesheets und Fonts zeigen sich dort als langer Render Delay – die Wartezeit, nachdem das LCP-Bild oder bei Text das erste Byte eingetroffen ist.

CoreDash auf Mobilgeräten, p75, Text als LCP-Element: Vergleiche Render Delay mit Time To First Byte.

Was bedeuten Preconnected origins und Preconnect candidates?

Ein Preconnect (<link rel="preconnect">) öffnet die Verbindung zu einer Domain, bevor der Browser dort eine Datei anfordert. Preconnected origins listet die Domains auf, zu denen deine Seite vorab eine Verbindung aufbaut. Preconnect candidates zeigt Domains, deren Datei die Verbindung erst noch aufbauen musste – samt der Zeit, die ein Preconnect einsparen könnte (Est LCP savings).

Dieselbe Zahnarztseite mit einem großen Hero-Bild per Lazy Loading, Lighthouse 13.6 mit DevTools-Throttling.

• „Unused preconnect. Only use preconnect for origins that the page is likely to request.“ Die Seite hat von dieser Domain nichts geladen, hier maps.googleapis.com und www.youtube.com. Entferne den Eintrag, sobald du geprüft hast, dass kein anderes Template (wie der Checkout) ihn braucht.
• „Unused preconnect. Check that the crossorigin attribute is used properly.“ Ein Font braucht eine Verbindung mit crossorigin, ein Stylesheet oder Skript eine ohne. cdnjs.cloudflare.com liefert der Zahnarztseite das Stylesheet von Font Awesome und den Font. Das Stylesheet nutzte den Preconnect, der Font baute eine zweite Verbindung auf. Hoste den Font selbst. Nur wenn das nicht geht: Füge einen zweiten Preconnect zu dieser Domain mit crossorigin hinzu.
• „More than 4 preconnect connections were found.“ Jeder Preconnect baut eine Verbindung parallel zu den Dateien auf, die die Seite zuerst braucht. Hoste so viel wie möglich auf deiner eigenen Domain. Behalte einen Preconnect nur für kritische Dateien auf Domains, die du nicht vermeiden kannst.
• Eine Domain unter Preconnect candidates. Ziehe diese Datei auf deine eigene Domain um. Geht das nicht und die Datei ist kritisch: Setze einen Preconnect dorthin.

Falls du Google Fonts noch nicht selbst hosten kannst: Binde das Stylesheet direkt im HTML ein und setze einen Preconnect zu fonts.gstatic.com mit crossorigin. Zu fonts.googleapis.com verbindet sich der Browser, sobald er den Link liest. Eine Kette bleibt das trotzdem.

<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

Preconnect-Einstellungen in Plugins setzen crossorigin nicht immer richtig: DNS Preconnect in LiteSpeed Cache gibt es für keine Domain aus, Perfmatters nur dort, wo du das Häkchen setzt. Prüfe deinen Quelltext: Nur Font-Domains brauchen das Attribut.

Wie behebst du den Network-Dependency-Tree?

Beginne bei der langsamsten Kette – der orange markierten in Lighthouse – und dort bei der untersten Zeile. Frage dich bei jeder Datei darin: Kann diese Datei direkt im HTML stehen oder von der eigenen Domain kommen?

Google Fonts und andere Webfonts

Ohne Code aktivierst du einfach die Option, die Google Fonts auf deiner eigenen Domain hostet: „Self-host Google Fonts“ in WP Rocket oder FlyingPress, „Local Google Fonts“ in Perfmatters, „Load Google Fonts Locally“ in Elementor (Einstellungen, Leistung) oder über das Plugin OMGF. Die Einstellung in WP Rocket übersieht ein Google-Fonts-@import im Stylesheet des Themes. Taucht fonts.googleapis.com danach immer noch im Baum auf, entferne das @import (siehe nächster Abschnitt). Eine Option, die Google Fonts „asynchron“ über ein Font-Loader-Skript lädt (wie in LiteSpeed Cache und Autoptimize), fügt der Kette eine weitere Ebene hinzu: Hoste die Fonts stattdessen selbst.

Manuell trägst du die @font-face-Regeln in dein eigenes Stylesheet ein und legst die woff2-Dateien daneben in einen fonts-Ordner:

@font-face {
  font-family: "Poppins";
  font-style: normal;
  font-weight: 700;
  font-display: swap;
  src: url("fonts/poppins-v24-latin-700.woff2") format("woff2");
}

Ein Font lässt sich nur innerhalb eines Stylesheets referenzieren. Daher verkürzt nur ein Preload diese Kette. Nutze weniger Font-Dateien und lade dann ein oder zwei vorab – zuerst den Font für deinen größten Text im ersten sichtbaren Bereich. Prüfe danach den LCP:

<link rel="preload" href="/wp-content/themes/acme-smile/fonts/poppins-v24-latin-700.woff2" as="font" type="font/woff2" crossorigin>
<link rel="preload" href="/wp-content/themes/acme-smile/fonts/open-sans-v44-latin.woff2" as="font" type="font/woff2" crossorigin>
<link rel="stylesheet" href="/wp-content/themes/acme-smile/style.css?ver=2.5.0">

Der Preload braucht crossorigin, auch auf der eigenen Domain. Sonst lädt der Browser den Font doppelt herunter. Font display erklärt Font-Preloads.

Unter Next.js übernimmt next/font bereits das Hosting und den Preload der Fonts: Ersetze ein manuell geschriebenes @import url(https://fonts.googleapis.com/...) in einer CSS-Datei durch next/font.

WordPress-Themes mit @import

Wenn du ein Google-Fonts-@import aus dem Parent-Theme löschst, ist es beim nächsten Update wieder da: Suche nach einer Font-Einstellung im Theme oder bitte den Entwickler, die Fonts per Enqueue einzubinden.

Ein @import des Parent-Stylesheets in der style.css eines Child-Themes fügt eine Ebene hinzu. Bitte den Theme-Entwickler um ein Child-Theme ohne diesen Import – oder schicke einem Entwickler den Baum aus dem Report und diesen Code für die functions.php des Child-Themes, der das @import ersetzt:

add_action( 'wp_enqueue_scripts', function () {
    wp_enqueue_style( 'parent-style', get_template_directory_uri() . '/style.css' );
} );

Prüfe danach den Quelltext: Das Parent-Stylesheet sollte genau einmal laden.

Icon-Fonts

Font Awesome und die Icons von Elementor laden ein Stylesheet, das wiederum eine Font-Datei mit sämtlichen Icons lädt. Aktiviere in Elementor die Option „Inline Font Icons“: Sie ersetzt das Stylesheet und den Font durch Inline-SVG. Andernfalls ersetzt du die genutzten Icons durch Inline-SVG oder hostest Font Awesome auf deiner eigenen Domain.

Shopify

Wähle deine Schriften im Theme-Editor (Theme-Einstellungen, Typografie), statt Google-Fonts-Code in die theme.liquid einzufügen: Das Theme liefert sie dann über die eigene Domain deines Shops aus. Dawn und darauf aufbauende Themes laden sie per Preload vorab. App-Embeds, die ein Stylesheet einbinden, tauchen im Baum auf: Schalte sie nacheinander ab und starte Lighthouse erneut. Shopify sendet eigene Preconnect-Header für sein CDN und für die ersten drei externen Domains, von denen blockierende Dateien stammen. Lighthouse zählt diese zu seinem Limit von vier hinzu. Entferne einen alten Preconnect für cdn.shopify.com aus der theme.liquid. Setze eigene Preconnects nur für Domains, die dein Baum wirklich noch braucht. Jedes deaktivierte App-Embed kann einen von Shopifys Preconnects überflüssig machen. Bleibt „More than 4 preconnect connections“ stehen, obwohl nur noch Shopifys eigene Verbindungen übrig sind: Lass es so.

Dateien, die ein Skript nachlädt, und Dienste, die du nicht ändern kannst

Ein Stylesheet, das ein Skript nachlädt, wartet auf dieses Skript: Braucht der erste sichtbare Bereich das Stylesheet, binde es direkt im HTML ein. Wenn nicht, lade das Skript per defer. Ein Consent-Tool, das zuerst ausgeführt werden muss, bleibt render-blocking. Lädt es Dateien von einer zweiten Domain, die du nicht vermeiden kannst: Setze einen Preconnect dorthin. Braucht dein Server Zeit, um das HTML zu erstellen, schickt 103 Early Hints den Preconnect und den Font-Preload noch vor dem HTML selbst.

Warum ist der Baum nach dem Fix immer noch rot?

Lighthouse färbt den Hinweis rot, sobald das HTML auch nur ein einzelnes Stylesheet lädt. Eine Seite ganz ohne Ketten bleibt also rot. Dieses Rot darf bleiben: das HTML und die Dateien, die direkt darin stehen. Jede Zeile, die unter einer anderen Datei eingerückt ist, ist eine Kette, die du angehen musst:

• Fonts unter deinem eigenen Stylesheet. Nutze weniger Dateien und lade ein oder zwei vorab. Ein Font, der im ersten sichtbaren Bereich nicht gebraucht wird, ist die einzige Kette, die bleiben darf.
• Dateien, die ein Dienst nachlädt. Cloudflares Email Obfuscation (email-decode.min.js) und das Web-Analytics-Beacon oder guest.vary.php aus dem Guest Mode von LiteSpeed Cache. Schalte das Feature ab.

Ein bekannter Bug in PageSpeed Insights packt manchmal Requests fremder Websites in den Baum: Starte den Test einfach noch einmal.

Die Zahnarztseite ohne jede Kette, Lighthouse 13.6 mit DevTools-Throttling.

Wie prüfst du, ob der Baum kürzer geworden ist?

Starte Lighthouse erneut und vergleiche zuerst die Ebenen und die langsamste Kette, da die Maximum critical path latency von Lauf zu Lauf leicht schwankt. Die Spalte „Initiator“ im Network-Panel der Chrome DevTools zeigt dir, welche Datei welchen Request angefordert hat. Für echte Besucher beobachtest du FCP und LCP auf Mobilgeräten in CoreDash ab den nächsten Besuchen. Die Search Console braucht bis zu 28 Tage.

Stammt deine längste Kette aus einem Theme oder Page-Builder, den du nicht bearbeiten kannst – oder aus einer App, die eigene Fonts lädt? In einer Core-Web-Vitals-Power-Hour gehen wir deinen Baum Datei für Datei gemeinsam durch. Wir entscheiden, welche Dateien auf deine eigene Domain wandern, was direkt ins HTML gehört und welche Domain noch einen Preconnect braucht.