Die LCP Resource Load Delay optimieren

Dieser Leitfaden ist Teil des Largest Contentful Paint (LCP)-Hubs. Die Resource Load Delay ist häufig der größte einzelne Faktor für einen schlechten LCP-Wert. Die meisten Teams konzentrieren sich auf die Bildkomprimierung, während das eigentliche Problem darin besteht, dass der Browser das Bild zu spät gefunden hat.

Die LCP Resource Load Delay optimieren

Largest Contentful Paint (LCP) besteht aus vier Phasen: TTFB, Resource Load Delay, Resource Load Duration und Element Render Delay. Die Entwicklungsarbeit konzentriert sich oft auf die Reduzierung der Load Duration durch Dateikomprimierung, übersieht dabei aber die Resource Load Delay, die häufig eine größere Latenzquelle darstellt. Diese Verzögerung vor Beginn des Downloads kann Hunderte von Millisekunden zu Ihrem LCP hinzufügen und dazu führen, dass der Schwellenwert von 2,5 Sekunden für „Gut" überschritten wird.

Ein kurzer Tipp: Wenn Ihr LCP ein Bild ist, wird es fast immer schlechter sein als Text. Sie müssen Ihre LCP-Elementtypen in Ihren RUM-Daten verfolgen, andernfalls tappen Sie im Dunkeln.

Präzise Definition: Die kritische Wartezeit vor dem Download

Die Resource Load Delay ist die Zeit zwischen TTFB und dem Moment, in dem der Browser den Download der LCP-Ressource initiiert. Es ist nicht die Download-Zeit; es ist die Entdeckungslatenz, die auftritt, bevor der Abruf beginnt. Ein hoher Wert hier deutet auf ein architektonisches Problem hin, bei dem der Browser die Ressourcen-URL nicht im initialen HTML-payload finden kann. Diese Resource Load Delay kann als die Zeit betrachtet werden, die der Browser damit verbringt, festzustellen, dass die LCP-Ressource benötigt wird, und zu entscheiden, sie abzurufen.

Für LCP-Elemente, die textbasiert sind und mit einem Systemfont gerendert werden, ist diese Resource Load Delay typischerweise null, da keine externe Ressource abgerufen werden muss. Höhere Werte der Resource Load Delay treten spezifisch bei LCP-Elementen auf, die auf eine externe Netzwerkressource wie ein Bild oder eine Videodatei angewiesen sind.

Der Motor der Entdeckung: Preload Scanner vs. DOM Parser

Um die Resource Load Delay zu reduzieren, müssen Sie verstehen, wie Browser Ressourcen entdecken. Die Effizienz dieses Entdeckungsprozesses ist der primäre Faktor, der die Latenz bestimmt. Browser verwenden zwei Mechanismen: einen schnellen Pfad und einen langsamen Pfad.

• Der Preload Scanner (Der schnelle Pfad): Dies ist ein Hochgeschwindigkeits-Sekundärparser, der das rohe HTML nach Ressourcen-URLs durchsucht, wie sie in <img>- oder <link>-Tags vorkommen. Er reiht sie sofort zum Download ein, bevor CSS geparst oder JavaScript ausgeführt wird. Dies ist der optimale Pfad für jede kritische Ressource.
• Der DOM Parser (Langsamer Pfad): Dies ist der Hauptparser, der das vollständige Document Object Model (DOM) und das CSS Object Model (CSSOM) aufbaut. Ressourcen, die nicht im initialen HTML gefunden werden, wie ein CSS-background-image oder ein per JavaScript eingefügtes Element, werden erst von diesem Parser entdeckt. Dies ist der langsame Pfad, da er von anderen Dateien abhängt, die erst heruntergeladen und ausgeführt werden müssen, was eine Kette von Abhängigkeiten erzeugt, die hohe Latenz verursacht.

Die gesamte Strategie zur Optimierung der Resource Load Delay basiert auf einem Prinzip: Stellen Sie sicher, dass die URL der LCP-Ressource vom Preload Scanner entdeckbar ist. Jedes Muster, das die URL vor dem initialen HTML-Dokument verbirgt, zwingt den Browser, den langsamen Entdeckungspfad zu verwenden. Diese Wartezeit übersetzt sich direkt in Resource Load Delay. Jede wirksame Optimierung zielt darauf ab, Ihr HTML so zu strukturieren, dass die LCP-Ressource auf dem schnellen Pfad liegt. Für einen vollständigen Leitfaden zur Browser-Ressourcenpriorisierung lesen Sie unseren Artikel über Ressourcenpriorisierung.

Warum die Load Delay wichtig ist

Ein verbreiteter Irrtum ist, dass ein langsamer LCP ein „Dateigrößen"-Problem ist. Dies führt dazu, dass Teams sich nur auf Bildkomprimierung konzentrieren, um die Resource Load Duration zu reduzieren. Obwohl Asset-Optimierung ein Faktor ist, zeigt die Analyse realer Felddaten, dass bei vielen Websites mit schlechtem LCP die Resource Load Delay der primäre Performance-Engpass ist, nicht die Resource Load Duration.

Felddaten zeigen, dass die mediane Website mit einem schlechten LCP-Wert eine Resource Load Delay von 1,3 Sekunden hat. Das sind über die Hälfte des gesamten 2,5-Sekunden-Budgets für einen „Guten" LCP-Wert, vollständig verbraucht, bevor der Download der LCP-Ressource überhaupt beginnt. Die Daten zeigen, dass diese Websites fast viermal so lang auf den Beginn des Downloads warten wie der Download selbst dauert.

Diese Daten zeigen eine häufige Fehlleitung des Entwicklungsaufwands. Teams können Wochen damit verbringen, Kilobytes von Bildern zu entfernen, um die Load Duration um einige Millisekunden zu verkürzen, während ein architektonisches Problem, das eine 1,5-Sekunden-Load-Delay verursacht, unbehandelt bleibt. LCP ist ein sequenzieller Prozess; eine Verzögerung in einer frühen Phase kann nicht durch Optimierung einer späteren Phase ausgeglichen werden. Wenn ein Abruf um über eine Sekunde verzögert wird, ist ein Unterschied von 100ms in der Download-Zeit für den endgültigen LCP-Wert irrelevant. Die wirkungsvollsten Optimierungen beinhalten architektonische Änderungen, wie die Verbesserung der Ressourcen-Entdeckbarkeit, nicht nur Asset-Komprimierung. Der Fokus muss sich verschieben von kleineren Assets hin zu früherer Entdeckung.

Wie man die Resource Load Delay erkennt

Um die Resource Load Delay zu beheben, müssen Sie sie zunächst genau messen. Der professionelle Workflow besteht darin, das Problem zunächst mit echten Nutzerdaten (RUM) zu definieren und erst dann zu Chrome DevTools für die Tiefenanalyse zu wechseln.

Schritt 1: Felddaten analysieren (RUM)

Felddaten, oder Real User Monitoring (RUM), werden aus tatsächlichen Nutzersitzungen gesammelt. RUM-Tools wie der öffentliche Chrome User Experience Report (CrUX) oder mein eigenes Tool CoreDash beantworten die Frage: Was passiert in der realen Welt? Ein vollwertiges RUM-Tool liefert auch eine Aufschlüsselung der LCP-Unterteile und zeigt Ihnen die mediane Resource Load Delay über Ihre Nutzer hinweg. Diese Daten bestätigen, dass ein LCP-Problem existiert, zeigen, welche URLs betroffen sind, und offenbaren die häufigsten LCP-Elemente, die Ihre Nutzer tatsächlich sehen. Sie müssen hier beginnen, um zu bestätigen, dass Sie ein echtes Problem lösen.

Schritt 2: Mit DevTools diagnostizieren

Sobald Ihre RUM-Daten eine Zielseite und ein LCP-Element identifiziert haben, verwenden Sie Chrome DevTools zur Diagnose der Ursache. Das Ziel ist hier, das Problem zu reproduzieren und die LCP-Unterteile zu messen, um einen präzisen Wert der Resource Load Delay zu erhalten. DevTools ist auch der Ort, an dem Sie eine Main-Thread-Analyse durchführen, um genau zu sehen, welche Aufgaben laufen und möglicherweise den Rendering-Prozess blockieren.

Eine Schritt-für-Schritt-Anleitung zum Chrome DevTools Performance Panel

Das Performance Panel in Chrome DevTools ist ein unverzichtbares Werkzeug zur Analyse des LCP und zur Quantifizierung der Load Delay.

1. Einrichtung und Konfiguration:

• Öffnen Sie Chrome DevTools, indem Sie mit der rechten Maustaste auf die Seite klicken und „Untersuchen" wählen, oder verwenden Sie die Tastenkombination Ctrl+Shift+I (Windows/Linux) oder Cmd+Option+I (Mac).
• Navigieren Sie zum Tab Performance.
• Stellen Sie sicher, dass das Kontrollkästchen Web Vitals in den Aufnahmeeinstellungen aktiviert ist. Dies blendet Core Web Vitals-Informationen über der Performance-Zeitleiste ein.
• Um realistische Nutzerbedingungen zu simulieren, wenden Sie CPU- und Netzwerk-Throttling an. Eine „4-fache Verlangsamung" für die CPU und ein „Fast 3G"- oder „Slow 4G"-Netzwerkprofil sind übliche Ausgangspunkte für mobile Tests.

2. Ein Performance-Profil aufzeichnen:

• Klicken Sie auf die Schaltfläche „Aufzeichnen und Seite neu laden" (ein kreisförmiges Pfeilsymbol) im Performance Panel. Dies startet eine Aufzeichnung, lädt die Seite neu und stoppt die Aufzeichnung, sobald die Seite vollständig geladen ist.

3. Analyse und Interpretation:

• Timings-Track: Suchen Sie in der Hauptzeitansicht den Timings-Track. Sie werden eine Markierung mit der Bezeichnung LCP sehen. Wenn Sie mit der Maus über diese Markierung fahren, wird das entsprechende LCP-Element im Hauptansicht-Screenshot hervorgehoben und die gesamte LCP-Zeit angezeigt.
• LCP nach Phasen-Aufschlüsselung: Klicken Sie auf die LCP-Markierung im Timings-Track. Im Tab „Summary" am unteren Rand des Panels finden Sie eine detaillierte Aufschlüsselung des LCP-Timings. Diese Aufschlüsselung zeigt explizit die Dauer jeder der vier Unterteile, einschließlich der Load Delay, gemessen in Millisekunden. Dieser Wert ist die direkteste und präziseste Messung der Resource Load Delay für diesen spezifischen Seitenaufruf.
• Main-Thread-Analyse: Schauen Sie sich während der Untersuchung der Zeitleiste den Main Track auf Long Tasks (Aktivitätsblöcke, die mit einem roten Dreieck markiert sind) an. Wenn diese Long Tasks nach dem Laden der LCP-Ressource, aber vor der LCP-Markierung auftreten, tragen sie wahrscheinlich zur Element Render Delay bei, einem verwandten, aber eigenständigen Problem.

Häufige Ursachen und wirkungsvolle Lösungen

Eine hohe Resource Load Delay wird durch eines von zwei Dingen verursacht: Die LCP-Ressource wird spät entdeckt, oder sie erhält eine niedrige Abrufpriorität. Hier sind die häufigsten architektonischen Fehler und ihre Lösungen.

Ursache: LCP über CSS geladen

Das Problem: Der Preload Scanner parst keine CSS-Dateien. Wenn Ihr LCP-Bild mit einem CSS-background-image definiert ist, ist seine URL für diesen Hochgeschwindigkeitsscanner unsichtbar. Der Browser kann das Bild erst entdecken, nachdem er das HTML heruntergeladen, den CSS-Datei-Link gefunden, die CSS-Datei heruntergeladen, das CSSOM aufgebaut und dann den Stil angewendet hat. Diese Abhängigkeitskette verursacht direkt eine hohe Resource Load Delay. Für weitere Informationen zu diesem Muster lesen Sie unseren Leitfaden zum Aufschieben von Hintergrundbildern.

Die Lösung: Die korrekte Implementierung besteht darin, background-image für kein kritisches LCP-Element zu verwenden. Verwenden Sie stattdessen ein Standard-<img>-Tag. Dies platziert die Bild-URL direkt im HTML, wo der Preload Scanner sie sofort finden kann. Sie können das gleiche visuelle Ergebnis mit CSS erzielen.

Implementierungsbeispiel:

Anti-Pattern (Dies nicht tun):

    <!-- CSS -->
   .hero {
      background-image: url('hero-image.jpg');
      height: 500px;
      width: 100%;
    }

    <!-- HTML -->
    <div class="hero"></div>
    

Best Practice (Stattdessen dies tun):

    <!-- HTML -->
    <div class="hero-container">
      <img
        src="hero-image.jpg"
        alt="A descriptive alt text for the hero image"
        fetchpriority="high"
        class="hero-background-img"
        width="1200"
        height="500"
      />
      <div class="hero-content">
        <h1>Page Title</h1>
      </div>
    </div>

    <!-- CSS -->
   .hero-container {
      position: relative;
      height: 500px;
      width: 100%;
    }

   .hero-background-img {
      position: absolute;
      inset: 0; /* Equivalent to top: 0; right: 0; bottom: 0; left: 0; */
      width: 100%;
      height: 100%;
      object-fit: cover; /* This property mimics background-size: cover */
      z-index: -1; /* Places the image behind other content */
    }
    

Diese Implementierung liefert das gleiche visuelle Ergebnis, macht aber das LCP-Bild zum frühestmöglichen Zeitpunkt entdeckbar, was seine Load Delay minimiert.

Ursache: Client-Side Rendering und JavaScript-Injektion

Das Problem: Anwendungen, die Client-Side-Rendering-Frameworks (CSR) wie React oder Vue verwenden, liefern oft eine minimale HTML-Hülle aus. Der tatsächliche Inhalt, einschließlich des LCP-<img>-Tags, wird erst per JavaScript in das DOM eingefügt, nachdem große Framework-Bundles heruntergeladen, geparst und ausgeführt wurden. Dieser Prozess verbirgt die LCP-Ressource grundlegend vor dem Preload Scanner und erzeugt eine hohe Entdeckungslatenz.

Die Lösung: Die effektivste Lösung besteht darin, das initiale Rendering vom Client auf den Server zu verlagern.

• Server-Side Rendering (SSR) oder Static Site Generation (SSG): Architekturmuster wie SSR oder SSG erzeugen das vollständige HTML auf dem Server. Der Browser erhält ein vollständiges Dokument mit dem <img>-Tag und seinem src-Attribut, wodurch die LCP-Ressource sofort vom Preload Scanner entdeckbar wird. Dies ist die erforderliche Architektur für jede performance-kritische Seite.
• Framework-spezifische Optimierungen: Moderne Frameworks bieten auch eingebaute Optimierungen. Zum Beispiel hat die Next.js-<Image>-Komponente eine priority-Eigenschaft. Wenn diese auf true gesetzt wird, fügt das Framework automatisch die korrekten <link rel="preload">- und fetchpriority="high"-Attribute hinzu und stellt sicher, dass das Bild mit der richtigen Priorität entdeckt und abgerufen wird.

Ursache: Verwendung von loading="lazy" beim LCP-Bild

Das Problem: Dies ist ein häufiger und schwerwiegender Fehler. Das Attribut loading="lazy" ist eine direkte Anweisung an den Browser, das Abrufen eines Bildes zu verzögern, bis es sich in der Nähe des Viewports befindet. Obwohl dies die korrekte Optimierung für Bilder unterhalb des sichtbaren Bereichs ist, ist die Anwendung auf ein above-the-fold LCP-Element kontraproduktiv. Der Preload Scanner des Browsers ist darauf ausgelegt, Bilder mit loading="lazy" zu ignorieren, was eine späte Entdeckung und eine hohe Resource Load Delay garantiert.

Die Lösung: Die Lösung erfordert Sorgfalt.

• loading="lazy" vom LCP-Bild entfernen: Jedes Bild, das wahrscheinlich das LCP-Element ist, darf das Attribut loading="lazy" nicht haben. Das Standardverhalten des Browsers ist loading="eager", was die korrekte Einstellung für kritische above-the-fold-Inhalte ist. Das Weglassen des loading-Attributs hat den gleichen Effekt.
• Drittanbieter-Tools prüfen und konfigurieren: Sie müssen auch Drittanbieter-Tools prüfen. Viele CMS-Plattformen wie WordPress und verschiedene Bildoptimierungs-Plugins wenden automatisch Lazy Loading auf alle Bilder an. Es ist unerlässlich, diese Tools so zu konfigurieren, dass das LCP-Bild von diesem Verhalten ausgeschlossen wird. Dies beinhaltet oft das Erstellen einer Ausschlussregel für die ersten ein oder zwei Bilder auf der Seite.

Ursache: Suboptimale HTML-Struktur und große Dokumente

Das Problem: Der Preload Scanner verarbeitet das HTML-Dokument von oben nach unten. Wenn unkritische, aber bandbreitenintensive Ressourcen wie Header-Icons oder Chat-Widget-Skripte höher im <body> platziert sind als das LCP-Element, werden sie zuerst entdeckt und zum Download eingereiht. Dies verbraucht anfängliche Netzwerkbandbreite und kann den Download der LCP-Ressource verzögern. Ein großes HTML-Dokument kann ebenfalls problematisch sein; wenn das LCP-Element nicht im ersten Datenpaket enthalten ist, das der Browser empfängt (etwa 14KB), wird seine Entdeckung um mindestens einen Netzwerk-Roundtrip verzögert.

Die Lösung: Optimieren Sie die Struktur und Priorität der Inhalte innerhalb des HTML.

• HTML umstrukturieren: Stellen Sie nach Möglichkeit sicher, dass das <img>-Tag oder der Textblock für das LCP-Element so früh wie möglich innerhalb des <body>-Tags erscheint.
• Unkritische Bilder herabstufen: Für nicht-essentielle Bilder, die früh im HTML-Quellcode erscheinen müssen (wie Icons in einem Header), wenden Sie loading="lazy" an. Dies weist den Preload Scanner an, sie zu überspringen und die Download-Warteschlange für das LCP-Element freizuhalten.
• Nicht-essentielle Skripte aufschieben: Skripte für Analytics, Werbung oder Social-Media-Widgets sind selten kritisch für das initiale Rendering. Verschieben Sie ihre <script>-Tags an das Ende des <body> oder verwenden Sie das defer-Attribut. Dies verhindert, dass sie den Parser blockieren oder mit der LCP-Ressource um Netzwerkbandbreite konkurrieren.

Erweiterte Priorisierung mit Resource Hints

Sobald die LCP-Ressource im HTML entdeckbar ist, können Sie Resource Hints verwenden, um dem Browser explizitere Anweisungen zum Abrufen zu geben. Diese Hints bieten feingranulare Kontrolle über Entdeckung und Priorisierung.

Frühzeitige Entdeckung erzwingen mit <link rel="preload">

<link rel="preload"> ist kein Hint; es ist eine Direktive. Sie zwingt den Browser, eine Ressource mit hoher Priorität herunterzuladen, auch wenn sie vom Hauptparser noch nicht entdeckbar ist. Die Platzierung im <head> Ihres HTML ist der direkteste Weg, Probleme mit später Entdeckung für Ressourcen wie Fonts, CSS-Hintergrundbilder oder LCP-Bilder tief im DOM zu beheben. Für vollständige Implementierungsdetails und Beispiele lesen Sie unseren dedizierten Leitfaden zum Preloading des LCP-Bildes.

Mechanismus

Wenn ein preload-Link im <head> des HTML-Dokuments platziert wird, identifiziert der Preload Scanner ihn und reiht die angegebene Ressource sofort zum Download ein. Dies ist ideal für Ressourcen wie Fonts, die über @font-face in einem externen Stylesheet geladen werden, CSS-background-image-LCPs (obwohl ein <img>-Tag bevorzugt wird) oder ein LCP-Bild, das sich tief innerhalb einer komplexen DOM-Struktur befindet.

Responsives Preloading

Ein kritisches Implementierungsdetail ist erforderlich beim Preloading responsiver Bilder. Um sicherzustellen, dass der Browser das korrekt dimensionierte Bild für den Viewport des Nutzers vorlädt und einen verschwenderischen Doppel-Download vermeidet, muss das <link rel="preload">-Tag imagesrcset- und imagesizes-Attribute enthalten, die die Attribute des entsprechenden <img>-Tags exakt widerspiegeln.

Beispiel für responsives Preloading:

<link rel="preload" as="image"
      href="lcp-image-large.jpg"
      imagesrcset="lcp-image-small.jpg 400w, lcp-image-medium.jpg 800w, lcp-image-large.jpg 1200w"
      imagesizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"
      fetchpriority="high">

<img src="lcp-image-large.jpg"
     srcset="lcp-image-small.jpg 400w, lcp-image-medium.jpg 800w, lcp-image-large.jpg 1200w"
     sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"
     alt="A descriptive alt text"
     fetchpriority="high"
     width="1200" height="675">
    

Mögliche Fallstricke

Preloading löst das Abruf-Timing (Load Delay und Load Duration), aber nicht das Paint-Timing. Wenn der Main Thread durch schweres JavaScript oder render-blockierendes CSS blockiert ist, wenn das vorgeladene Bild ankommt, muss das Bild dennoch auf das Rendering warten, was den Engpass von der Load Delay zur Element Render Delay verschieben kann.

fetchpriority="high" und die Prioritätswarteschlange des Browsers

Das Attribut fetchpriority ist ein Hint, der die relative Wichtigkeit des Downloads einer Ressource signalisiert. Es ermöglicht Ihnen, die Priorität einer Ressource innerhalb der Download-Warteschlange des Browsers zu beeinflussen.

Wie die Browser-Priorisierung funktioniert

Wenn der Browser während des Seitenladens Ressourcen entdeckt, weist er jeder eine interne Prioritätsstufe zu. Standardmäßig starten Bilder im Viewport mit „Niedriger" Priorität und werden später auf „Hoch" heraufgestuft, sobald der Browser das Layout abgeschlossen hat und feststellt, dass sie sichtbar sind. Dieses Upgrade erfordert, dass der Browser zuerst CSS herunterlädt und parst, was eine Verzögerung erzeugt. Das Attribut fetchpriority="high" umgeht diesen Prozess vollständig, indem es das Bild ab dem Moment seiner Entdeckung auf „Hohe" Priorität setzt. Dies ist besonders wirkungsvoll für LCP-Bilder, da es die Verzögerung durch das Prioritäts-Upgrade eliminiert.

preload vs. fetchpriority

Diese beiden Hints dienen unterschiedlichen, aber komplementären Zwecken. preload beeinflusst, wann eine Ressource entdeckt und in die Warteschlange aufgenommen wird. fetchpriority beeinflusst ihre Prioritätsstufe, sobald sie in der Warteschlange ist. Das Verständnis dieser Unterscheidung ist entscheidend: Preload löst späte Entdeckung, während Fetchpriority niedrige Priorisierung löst. Für viele LCP-Bilder, die bereits im HTML vorhanden sind, kann Fetchpriority allein ausreichend sein. Für einen vollständigen Leitfaden zur Interaktion dieser Mechanismen lesen Sie unseren Artikel über Ressourcenpriorisierung.

Best Practice für LCP

Für das LCP-Bild ist die optimale Strategie, beide zusammen zu verwenden. Stellen Sie zunächst eine frühzeitige Entdeckung sicher, entweder indem Sie das <img>-Tag früh im HTML platzieren oder preload verwenden. Fügen Sie dann fetchpriority="high" direkt zum <img>-Tag hinzu (und zum preload-Link, falls verwendet). Diese Kombination stellt sicher, dass die Ressource nicht nur früh entdeckt wird, sondern auch die höchstmögliche Priorität erhält, um den Wettbewerb um Netzwerkbandbreite gegen andere Ressourcen wie Stylesheets oder Fonts zu gewinnen.

Beispiel:

<img src="lcp-image.jpg" fetchpriority="high" alt="A critical hero image">

Wann fetchpriority="low" verwenden

Das Attribut fetchpriority dient nicht nur der Prioritätserhöhung. Sie können auch fetchpriority="low" verwenden, um unkritische Ressourcen herabzustufen, die mit dem LCP-Bild um Bandbreite konkurrieren. Häufige Kandidaten sind above-the-fold-Bilder, die nicht das LCP-Element sind (wie kleine Icons oder Avatare im Header), und vorgeladene Ressourcen, die benötigt, aber nicht dringend sind. Durch explizites Herabstufen der Priorität dieser konkurrierenden Ressourcen schaffen Sie mehr Bandbreiten-Spielraum für das LCP-Bild.

<!-- LCP image: high priority -->
<img src="hero.jpg" fetchpriority="high" alt="Hero image" width="1200" height="600">

<!-- Non-critical above-fold image: low priority -->
<img src="avatar.jpg" fetchpriority="low" alt="Author avatar" width="48" height="48">

Nachgewiesene Wirkung

In einer Fallstudie mit Google Flights verbesserte das Hinzufügen von fetchpriority="high" zum LCP-Hintergrundbild die LCP-Zeit von 2,6 Sekunden auf 1,9 Sekunden – eine Verbesserung um 700ms.

Optimierung von Drittanbieter-Verbindungen: preconnect und dns-prefetch

Das Problem

Wenn Ihre LCP-Ressource auf einer Drittanbieter-Domain gehostet wird, wie einem Bild-CDN oder einem Font-Anbieter wie Google Fonts, muss der Browser eine neue Netzwerkverbindung zu dieser Domain aufbauen. Dieser Prozess umfasst einen DNS-Lookup, einen TCP-Handshake und eine TLS-Verhandlung, die alle abgeschlossen sein müssen, bevor das erste Byte der Ressource heruntergeladen werden kann. Diese Verbindungsaufbauzeit trägt direkt zur Resource Load Delay für Cross-Origin-Assets bei.

Die Lösungen

• preconnect: Dieser Hint weist den Browser an, den vollständigen Verbindungsaufbau (DNS, TCP und TLS) für eine angegebene Drittanbieter-Origin im Hintergrund vorab durchzuführen. Wenn die Ressource tatsächlich angefragt wird, ist die Verbindung bereits aufgewärmt, wodurch die Aufbaulatenz eliminiert wird. Dies ist sehr effektiv und wird für die ein oder zwei wichtigsten Drittanbieter-Domains empfohlen, die LCP-Ressourcen bereitstellen.
• dns-prefetch: Dies ist ein leichtgewichtigerer Hint, der nur den DNS-Lookup für eine Domain durchführt. Er spart weniger Zeit als preconnect, hat aber breitere Browser-Unterstützung und ist nützlich als fallback oder für weniger kritische Drittanbieter-Domains.

Implementierungs-Best-Practice

Um maximale Kompatibilität sicherzustellen, stellen Sie beide Hints bereit. Der Browser verwendet preconnect, wenn unterstützt, und fällt auf dns-prefetch zurück, wenn nicht. Das crossorigin-Attribut ist essentiell für Ressourcen, die mittels CORS abgerufen werden, wie Fonts.

<link rel="preconnect" href="https://my-image-cdn.com" crossorigin>
<link rel="dns-prefetch" href="https://my-image-cdn.com">

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

Tabelle: Resource-Hint-Vergleich für LCP-Optimierung

Um Missbrauch zu vermeiden und die unterschiedlichen Rollen dieser leistungsstarken Hints zu verdeutlichen, bietet die folgende Tabelle eine vergleichende Zusammenfassung.

Ganzheitliche und zukunftsorientierte Strategien

Über Resource Hints hinaus können breitere architektonische Entscheidungen die Resource Load Delay noch weiter reduzieren.

Die Rolle eines modernen CDN

Ein Content Delivery Network (CDN) ist eine grundlegende Technologie für Web-Performance, die die Resource Load Delay indirekt, aber signifikant reduziert, insbesondere für LCP-Ressourcen.

• Reduzierung des Verbindungs-Overheads: Durch die Verteilung von Assets über ein globales Servernetzwerk platziert ein CDN Inhalte geografisch näher beim Nutzer. Dies reduziert inhärent die Round-Trip-Time (RTT), die für den DNS-Lookup, TCP-Handshake und die TLS-Verhandlung erforderlich ist, die alle Bestandteile der Verbindungsaufbauzeit sind. Für ein auf einem CDN gehostetes LCP-Bild reduziert dies direkt die Load Delay.
• Bild-CDNs: Spezialisierte Bild-CDNs bieten einen doppelten Vorteil. Sie bieten den Nähe-Vorteil eines Standard-CDN und automatisieren gleichzeitig viele komplexe Optimierungen, die die Resource Load Duration reduzieren, wie Echtzeit-Bildgrößenanpassung, Komprimierung und Konvertierung in moderne Formate wie AVIF und WebP.
• Fortschrittliche Protokolle: Viele moderne CDNs verwenden HTTP/3, das QUIC statt TCP nutzt. HTTP/3 reduziert die Verbindungsaufbauzeit und mindert Head-of-Line-Blocking, was insgesamt zu schnellerer und effizienterer Ressourcenbereitstellung führt.

Verzögerung vollständig eliminieren mit Speculation Rules

Die Speculation Rules API kann die LCP-Verzögerung für nachfolgende Navigationen vollständig eliminieren.

Mechanismus

Diese API ermöglicht es Entwicklern, dem Browser deklarativ mitzuteilen, zu welchen URLs der Nutzer wahrscheinlich als Nächstes navigieren wird. Basierend auf diesen Regeln kann der Browser eine Zielseite in einem versteckten Hintergrund-Tab vorrendern, bevor der Nutzer überhaupt auf den Link klickt.

Auswirkung auf LCP

Wenn der Nutzer auf einen Link zu einer vorgerenderten Seite klickt, ist die Navigation praktisch sofort. Die Seite wurde bereits vollständig im Hintergrund geladen und gerendert. Für diese Navigation werden TTFB, Resource Load Delay, Resource Load Duration und Element Render Delay aus Nutzerperspektive effektiv auf nahezu null reduziert.

Beispiel-Anwendungsfall

Auf einer E-Commerce-Kategorieseite könnten Speculation Rules verwendet werden, um die Produktdetailseiten für die ersten Artikel in der Liste vorzurendern. Wenn ein Nutzer auf eines dieser Produkte klickt, erscheint die Seite sofort.

Fallstudien-Synthese: Von der Theorie zur Praxis

Diese Optimierungen haben messbare reale Auswirkungen.

• Fall 1: Die transformative Kraft des Preloading: Ein von DebugBear durchgeführtes Experiment auf einer Seite mit hoher Load Delay liefert ein dramatisches Beispiel. Das LCP-Bild war in einer Anfragekette versteckt, wodurch die Resource Load Delay beeindruckende 75% der gesamten LCP-Zeit ausmachte. Durch die Implementierung eines einzigen <link rel="preload">-Hints, um das Bild frühzeitig entdeckbar zu machen, wurde die Resource Load Delay auf nur 2% der LCP-Zeit reduziert. Dies zeigt, wie ein einfacher architektonischer Fix einen massiven Performance-Engpass lösen kann.
• Fall 2: Das reale loading="lazy"-Anti-Pattern: Ein Entwickler auf Stack Overflow berichtete von einem Desktop-LCP mit einer rätselhaften Load Delay von 1.430ms trotz schnellem Netzwerk. Die Ursache wurde auf ein Bildoptimierungs-Plugin zurückgeführt, das fälschlicherweise Lazy Loading auf das LCP-Bild anwendete, indem es sein src-Attribut durch ein transparentes Platzhalter-SVG ersetzte. Die definitive Lösung war, dieses Verhalten für das LCP-Element zu deaktivieren, damit es frühzeitig entdeckt und geladen werden konnte. Dies zeigt, wie Drittanbieter-Tools versehentlich schwere Load Delays einführen können.
• Fall 3: Der fetchpriority-Performance-Boost: Die Google-Flights-Fallstudie liefert klare Belege für die Wirkung expliziter Priorisierung. Durch das einfache Hinzufügen von fetchpriority="high" zum LCP-Hintergrundbild der Seite verbesserte sich der LCP-Wert um 700ms, von 2,6 Sekunden auf 1,9 Sekunden. Dies zeigt, dass selbst wenn eine Ressource entdeckbar ist, das Signalisieren ihrer hohen Wichtigkeit an den Browser ein kritischer Schritt ist, um den Wettbewerb um Netzwerkbandbreite zu gewinnen.

Netzwerkinspektion in Chrome DevTools: Verwenden Sie die Tastenkombination Ctrl + Shift + I, um die Chrome-Entwicklertools zu öffnen, wählen Sie dann den Tab „Network" und laden Sie die Seite neu. Schauen Sie sich die Ladereihenfolge an. Ihre LCP-Ressource sollte eines der ersten Elemente sein, die zum Download eingereiht werden. Wenn sie hinter anderen Elementen zurückbleibt, liegt ein Problem mit der Resource Load Delay vor. Nachfolgend ein Beispiel einer Website, bei der die Resource Load Delay nicht optimiert wurde.

Real User Monitoring (RUM)-Daten verwenden: Real User Monitoring-Tools protokollieren oft LCP-Attributionsdaten. Mit RUM können Sie die Aufschlüsselung der LCP-Unterteile visualisieren (über Zeit oder nach Seite) und erhalten ein klares Bild der Load Delay für LCP-Elemente über Ihre gesamte Website oder pro Seite. Das folgende Beispiel zeigt eine globale LCP-Aufschlüsselung zusammen mit der entsprechenden Load Delay.

Wie man die Load Delay verbessert

Eine Resource Load Delay tritt auf, wenn die Download-Reihenfolge und das Timing von Ressourcen nicht optimal sind. Es gibt im Wesentlichen zwei direkte Wege, dies zu beheben: Die LCP-Ressource priorisieren oder Nicht-LCP-Ressourcen herabstufen. Sehen wir uns einige gängige Muster an:

LCP-Tipp: Den Preload Scanner verstehen: Moderne Browser verwenden einen Mechanismus namens Preload Scanner, der das HTML schnell durchsucht und Ressourcen zum Download einreiht. Wenn eine Ressource nicht vom Preload Scanner eingereiht werden kann, muss sie auf den langsameren DOM Parser warten, was zu Verzögerungen führt. Sicherzustellen, dass Ihre LCP-Ressourcen vom Preload Scanner entdeckbar sind, kann einen großen Unterschied bei der Reduzierung der Load Delay machen.

1. HTML-Struktur optimieren

Der Browser (oder der Preload Scanner) verarbeitet Ihr HTML von oben nach unten und reiht Ressourcen in der Reihenfolge ein, in der sie erscheinen. Das bedeutet, je höher die LCP-Ressource im HTML erscheint, desto früher wird sie eingereiht. Um dies zu optimieren, entfernen oder verschieben Sie unnötige Ressourcen vom oberen Bereich des HTML:

• Unwichtige oder versteckte Bilder lazy laden: Manchmal befinden sich Bilder (zum Beispiel Flaggen für sprachspezifische Versionen Ihrer Website oder Bilder im Menü) ganz oben im HTML Ihrer Website. Diese Bilder sind bei Weitem nicht so wichtig wie das LCP-Element. Durch Lazy Loading dieser Bilder werden sie vom Preload Scanner übersprungen und etwas später während des Ladeprozesses eingereiht.
• Unwichtige Skripte an das Ende der Seite verschieben: Verschieben Sie Skripte, die für das initiale Laden absolut unwichtig sind, an das Ende der Seite, um zu verhindern, dass sie kritische Ressourcen verzögern. Zum Beispiel ein Chat-Widget. Niemand in der Geschichte des Internets musste jemals chatten, bevor die Seite sichtbar war!

2. Hintergrundbilder vermeiden

Hintergrundbilder sind für den Preload Scanner unsichtbar, was bedeutet, dass sie immer vom viel langsameren DOM Parser eingereiht werden. Um diese Verzögerung zu vermeiden, verwenden Sie ein reguläres <img>-Tag in Kombination mit der CSS-Eigenschaft object-fit: cover, um das Erscheinungsbild eines Hintergrundbildes nachzuahmen. So kann der Preload Scanner das Bild sofort erkennen und einreihen.

3. Fetch Priority verwenden

Fügen Sie das Attribut fetchpriority="high" zu Ihrem LCP-Element hinzu, um dem Browser zu signalisieren, dass er diese Ressource von Anfang an priorisieren soll. Normalerweise laden Bilder mit einer Standard-niedrigen oder mittleren Priorität. Während der Layout-Phase stuft der Browser sichtbare Elemente auf hohe Priorität hoch. Durch das Setzen von fetchpriority="high" beginnt der Download sofort mit hoher Priorität, was einen schnelleren LCP gewährleistet.

Fetchpriority ist normalerweise weniger eingreifend (und weniger effektiv) als Preloading, da es die relative Priorität eines Elements setzt (in diesem Fall ist das Bild relativ wichtiger als andere Bilder), es aber nicht wichtiger macht als beispielsweise Stylesheets oder nicht-blockierende Skripte.

<img src="hero-image.jpg" alt="Hero Image" fetchpriority="high">

4. Preloading implementieren

Preloading ändert die Reihenfolge, in der der Preload Scanner Dateien einreiht. Platzieren Sie das <link rel="preload">-Tag im head der Seite, um den Browser anzuweisen, kritische Ressourcen wie das LCP-Bild so früh wie möglich abzurufen. Preloads können verwendet werden, um Ressourcen vorzuladen, die später im HTML referenziert werden (und daher später eingereiht werden), oder sogar um Ressourcen vorzuladen, die noch nicht im HTML referenziert sind (wie bei einigen Slidern). Für maximale Effektivität wird empfohlen, Preloads nach Stylesheets und vor Skripten im Head der Seite zu platzieren.

<link rel="preload" as="image" href="hero-image.jpg">

5. Styles optimieren

Stylesheets werden normalerweise vor der LCP-Ressource eingereiht, und das aus gutem Grund. Ohne Stylesheets weiß der Browser nicht, wie die Seite aussehen wird, und kann die Rendering-Phase nicht starten. Übermäßige CSS-Größe und eine übermäßige Anzahl von Stylesheets konkurrieren jedoch mit der LCP-Ressource um frühe Bandbreite.

6. Effizientes Lazy-Loading implementieren

Das loading-Attribut kann ein zweischneidiges Schwert sein. Verwenden Sie loading="eager" (oder lassen Sie das Attribut einfach weg, da „eager" der Browser-Standard ist) für Ihre LCP-Ressource, während Sie loading="lazy" für Offscreen-Bilder anwenden.

• LCP-Element eager laden: Wenn das LCP-Element lazy geladen wird, wird es nicht vom Preload Scanner eingereiht und lädt viel später, was die Performance negativ beeinflusst.
• Viewport-Bilder lazy laden: Für Bilder, die im sichtbaren Viewport sind, aber keine LCP-Ressourcen darstellen, verwenden Sie loading="lazy", um sie etwas später zum Download einzureihen. Dies reduziert die Bandbreitenkonkurrenz mit der LCP-Ressource.
• Offscreen-Bilder lazy laden vermeiden: Bilder, die nicht im sichtbaren Viewport sind, lösen überhaupt keinen Download aus und eliminieren so die Bandbreitenkonkurrenz vollständig.

7. Browser-Caching

Browser-Caching ermöglicht es, Netzwerkanfragen für Ressourcen zu überspringen, die bereits lokal auf dem Gerät des Nutzers gespeichert sind. Obwohl es den ersten Seitenaufruf nicht beschleunigt, verbessert es die Ladezeiten für nachfolgende Seitenaufrufe und wiederkehrende Besucher. So hilft Browser-Caching bei der Resource Load Delay:

• Konkurrierende Ressourcen cachen: Während das Caching der LCP-Ressource selbst eine großartige Strategie ist, verbessert Browser-Caching LCP Resource Load Delays, indem Netzwerkressourcen gespeichert werden, die mit der LCP-Ressource konkurrieren oder sie verzögern könnten, wie Skripte, Stylesheets und Bilder.
• Serverlast reduzieren: Caching reduziert die Anzahl der Anfragen an Ihren Server, was die Performance anderer Ressourcen verbessern kann, indem Bandbreite freigesetzt und Server-CPU-Zyklen reduziert werden.

8. Speculation Rules verwenden

Speculation Rules ermöglichen es Browsern, Webseiten basierend auf vorhergesagter Nutzernavigation vorzuladen oder vorzurendern. Prefetching eliminiert effektiv den Time to First Byte-Unterteil des LCP und hat keinen Einfluss auf die Resource Load Delay. Prerendering rendert die nächste Seite in einem versteckten Tab und lädt alle Seitenressourcen herunter. Dies eliminiert alle Load Delays für das LCP-Element, wie in diesem Beispiel einer LCP-Aufschlüsselung einer vorgerenderten Seite gezeigt.

9. Client-Side Rendering vermeiden

Nächste Schritte: LCP weiter optimieren

Die Resource Load Delay ist eine von vier LCP-Phasen. Sobald Sie die Entdeckungslatenz minimiert haben, fahren Sie mit diesen Leitfäden fort:

• LCP-Probleme finden und beheben: Die vollständige Diagnosemethodik zum Finden und Beheben aller LCP-Probleme.
• Das LCP-Bild optimieren: Bildformat-Auswahl, responsive Bilder, Preloading und häufige Bildfehler.
• Resource Load Duration: Nachdem der Browser die Ressource entdeckt hat, reduzieren Sie die Download-Dauer durch Komprimierung, moderne Formate und CDN-Optimierung.
• Element Render Delay: Nach dem Ressourcen-Download stellen Sie sicher, dass der Browser sie sofort darstellen kann, indem Sie den Main Thread freigeben.