Optimiere die Ladeverzögerung der LCP-Ressource.

Dieser Leitfaden ist Teil des Largest Contentful Paint (LCP)-Hubs. Die Resource Load Delay ist häufig der größte Einzelfaktor für einen schlechten LCP-Wert, besonders bei SPA-Seiten! 

Optimiere die LCP Resource Load Delay

Der Largest Contentful Paint (LCP) ist eine der 4 von vier LCP-Unterphasen: TTFB, Resource Load Delay, Resource Load Duration und Element Render Delay. 

Ein kurzer Tipp: Wenn dein LCP ein Bild ist, ist der Wert fast immer schlechter als bei Text. Du musst deine LCP-Elementtypen in deinen RUM-Daten tracken, sonst fliegst du im Blindflug.

Was ist die Resource Load Delay?

Die Resource Load Delay ist die Zeit zwischen der TTFB und dem Moment, in dem der Browser den Download der LCP-Ressource startet. Im Grunde sollte ein Browser eine LCP-Ressource (zum Beispiel das LCP-Bild)  so schnell wie möglich in die Warteschlange einreihen. Passiert das nicht sofort, liegt das meist daran, dass der Browser sie nicht gleich findet oder nicht als wichtig genug einstuft.

Ein hoher Wert deutet hier auf ein Architekturproblem hin (bei dem der Browser die Ressourcen-URL nicht im anfänglichen HTML-Payload findet. Diese Resource Load Delay kann als die Zeit betrachtet werden, die der Browser braucht, um zu erkennen, dass die LCP-Ressource benötigt wird, und um den Abruf zu beschließen.

Es ist auch wichtig zu verstehen, dass die Resource Load Delay vor dem eigentlichen Laden der Ressource passiert. Deshalb hat sie nichts mit responsiven Bildern oder neuen Bildformaten wie WebP oder AVIF zu tun.

Bei textbasierten LCP-Elementen, die mit einem Systemfont gerendert werden, beträgt diese Resource Load Delay in der Regel null, da keine externe Ressource abgerufen werden muss. Höhere Werte bei der Resource Load Delay treten spezifisch bei LCP-Elementen auf, die auf eine externe Netzwerkressource wie ein Bild oder eine Videodatei angewiesen sind.

Wie findet ein Browser das LCP-Element?

Um die Resource Load Delay zu reduzieren, musst du verstehen, wie Browser Ressourcen (oder zumindest das LCP-Element) entdecken. Browser nutzen zwei Mechanismen: einen schnellen und einen langsamen Pfad. Zuerst musst du sicherstellen, dass sich das LCP-Element auf dem schnellen Pfad befindet.

• Der DOM-Parser (Langsamer Pfad): Das ist der Haupt-Parser des Browsers und er ist ein Biest. Er baut die komplette Seite auf,  indem er das HTML und die Stylesheets liest und mit JavaScript interagiert. Das ist der langsame Pfad, weil er durch das Herunterladen und Ausführen anderer Dateien verzögert und angehalten werden kann. Das erzeugt eine Abhängigkeitskette, die Verzögerungen mit sich bringt.
• Der Preload Scanner (Der schnelle Pfad): Weil der DOM-Parser (relativ) langsam ist, haben Browser einen blitzschnellen zweiten Scanner, der die Seite sehr schnell nach herunterladbaren Ressourcen durchsucht und sich von nichts aufhalten lässt.  Findet er <script>-, non-lazy <img>- oder <link>-Tags, reiht er sie sofort für den Download ein, bevor CSS geparst oder JavaScript ausgeführt wird. Das ist der optimale Pfad für jede kritische Ressource.

Die gesamte Strategie zur Optimierung der Resource Load Delay basiert auf einem Prinzip: Stelle sicher, dass die LCP-Ressourcen-URL so früh wie möglich vom Preload Scanner gefunden werden kann.

Für ein LCP-Element bedeutet das 2 Dinge:

1. Sorge dafür, dass der Preload Scanner es findet, indem du ein normales Image-Tag nutzt, das nicht das loading="lazy"-Attribut hat.
2. Sorge dafür, dass der Preload Scanner nicht zu viele unwichtigere Ressourcen priorisiert.

Warum die Load Delay für die Core Web Vitals wichtig ist

Entwickler-Anfänger denken oft, LCP sei ein Problem der Dateigröße. Das führt dazu, dass sich Teams auf Bildkomprimierung, moderne Bildformate und responsive Bilder konzentrieren. Das ist ein Fehler. Unsere eigene Core Web Vitals-Forschung zeigt, dass der größte Engpass beim LCP die TTFB (48 %) ist, gefolgt von der Load Delay, die 24 % ausmacht. Die Ladezeit macht nur 10 % aus, gefolgt von der Render Delay mit 17 %.

Der Clou ist nun, dass sich die Load Delay fast vollständig beheben lässt, während die TTFB immer existieren wird. Das macht die Load Delay zum Element mit dem höchsten Optimierungspotenzial.

Wie du die Resource Load Delay erkennst

Um die Resource Load Delay zu beheben, musst du sie zuerst genau messen. Der Workflow ist immer: Prüfe mit CrUX, um das Problem zuerst mit echten Nutzerdaten (RUM) zu definieren, und wechsle erst danach für eine tiefe Analyse in die Chrome DevTools.

Schritt 1: Prüfe mit CrUX.

CrUX sind die öffentlich verfügbaren Field Data echter Chrome-Nutzer von Google. Sie werden als gleitender 28-Tage-Schnitt deiner Core Web Vitals beim 75. Perzentil angegeben. Sie sagen dir, ob eine Zahl gut oder schlecht ist, aber nicht wer, was oder warum. Da sich Google auf CrUX-Daten verlässt, ist das deine beste Datenquelle für den Start.

Gehe auf cruxvis.withgoogle.com, gib deine Website ein, navigiere zu Loading Performance und klicke auf  Largest Contentful Paint (LCP) image subparts

Schritt 2: Analysiere die Field Data (RUM)

RUM sammelt die Core Web Vitals all deiner echten Nutzer und liefert dir eine viel spezifischere, detaillierte Sicht. Es sagt dir, wer und was, beliebig aufgeschlüsselt (und diese Information ist Gold wert), aber nicht warum.

Dieser CoreDash-Screenshot zeigt dir zum Beispiel, welche URLs unter einer Resource Load Delay leiden (in Grün)

Schritt 3: Diagnose mit DevTools

Sobald deine RUM-Daten eine Zielseite und ein LCP-Element identifiziert haben, nutzt du die Chrome DevTools, um die Ursache zu diagnostizieren. Das Ziel hierbei ist, das Problem zu reproduzieren und die LCP-Unterphasen zu messen, um einen präzisen Resource Load Delay-Wert zu erhalten. In den DevTools führst du auch eine Main Thread-Analyse durch, um genau zu sehen, welche Tasks laufen und den Renderprozess potenziell blockieren.

Schritt-für-Schritt-Anleitung: Wir haben einen vollständigen Walkthrough für diesen Workflow geschrieben: LCP mit dem Performance-Panel der Chrome DevTools diagnostizieren. Er deckt das Throttling-Setup, das Aufzeichnen eines Traces und das Ablesen des genauen Resource Load Delay-Wertes aus dem LCP-Breakdown-Insight ab.

Häufige Ursachen und wirkungsvolle Lösungen

Eine hohe Resource Load Delay hat eine von zwei Ursachen: Die LCP-Ressource wird spät entdeckt oder sie erhält eine niedrige Fetch-Priorität. Hier sind die häufigsten Architekturfehler und ihre Lösungen.

Ursache: LCP via CSS geladen

Das Problem: Der Preload Scanner parst keine CSS-Dateien. Wenn dein LCP-Bild mit einem CSS-background-image definiert ist, ist seine URL für diesen High-Speed-Scanner unsichtbar. Der Browser kann das Bild erst entdecken, nachdem er das HTML heruntergeladen, den Link zur CSS-Datei gefunden, die CSS-Datei heruntergeladen, das CSSOM aufgebaut und dann das Styling angewendet hat. Diese Abhängigkeitskette verursacht direkt eine hohe Resource Load Delay. Mehr zu diesem Muster findest du in unserem Leitfaden über das Verzögern von Hintergrundbildern.

Die Lösung: Die korrekte Implementierung verzichtet auf background-image für jedes kritische LCP-Element. Nutze stattdessen ein Standard-<img>-Tag. Dadurch steht die Bild-URL direkt im HTML, wo der Preload Scanner sie sofort finden kann. Das gleiche visuelle Ergebnis erreichst du mit CSS.

Implementierungsbeispiel:

Anti-Pattern (Mach das nicht):

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

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

Best Practice (Mach stattdessen das hier):

    <!-- 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 das LCP-Bild aber zum frühestmöglichen Zeitpunkt auffindbar, was seine Load Delay minimiert.

Ursache: Client-Side Rendering und JavaScript-Injection

Das Problem: Anwendungen, die Client-Side Rendering (CSR)-Frameworks wie React oder Vue nutzen, liefern oft nur ein minimales HTML-Gerüst aus. Der eigentliche Inhalt, einschließlich des LCP-<img>-Tags, wird erst durch JavaScript ins DOM eingefügt, nachdem große Framework-Bundles heruntergeladen, geparst und ausgeführt wurden. Dieser Prozess versteckt die LCP-Ressource grundlegend vor dem Preload Scanner und erzeugt eine hohe Entdeckungslatenz.

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

• Server-Side Rendering (SSR) oder Static Site Generation (SSG): Architekturmuster wie SSR oder SSG generieren das vollständige HTML auf dem Server. Der Browser empfängt ein komplettes Dokument mit dem <img>-Tag und seinem src-Attribut. Das macht die LCP-Ressource sofort für den Preload Scanner auffindbar. Das ist die erforderliche Architektur für jede leistungskritische Seite.
• Framework-spezifische Optimierungen: Moderne Frameworks bieten auch integrierte Optimierungen. Die Next.js-<Image>-Komponente hat zum Beispiel eine priority-Eigenschaft. Setzt man diese auf true, weist das Framework an, automatisch die richtigen <link rel="preload">- und fetchpriority="high"-Attribute hinzuzufügen. Das stellt sicher, dass das Bild entdeckt und mit der richtigen Priorität abgerufen wird.

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

Das Problem: Das ist ein häufiger Fehler mit großen Auswirkungen. Das loading="lazy"-Attribut ist eine direkte Anweisung an den Browser, den Abruf eines Bildes zu verzögern, bis es sich nahe am Viewport befindet. Obwohl das die richtige Optimierung für Below-the-fold-Bilder ist, bewirkt es bei einem Above-the-fold-LCP-Element genau das Gegenteil. Der Preload Scanner des Browsers ist so konzipiert, dass er Bilder mit loading="lazy" ignoriert. Das garantiert eine späte Entdeckung und eine hohe Resource Load Delay.

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

• Entferne loading="lazy" vom LCP-Bild: Kein Bild, das wahrscheinlich das LCP-Element ist, darf das loading="lazy"-Attribut haben. Das Standardverhalten des Browsers ist loading="eager". Das ist die korrekte Einstellung für kritische Above-the-fold-Inhalte. Das Weglassen des loading-Attributs hat denselben Effekt.
• Überprüfe und konfiguriere Drittanbieter-Tools: Du musst auch Drittanbieter-Tools prüfen. Viele CMS-Plattformen wie WordPress und verschiedene Bildoptimierungs-Plugins wenden lazy loading automatisch auf alle Bilder an. Es ist essenziell, diese Tools so zu konfigurieren, dass sie das LCP-Bild von diesem Verhalten ausschließen. Das erfordert 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 nicht-kritische, aber bandbreitenintensive Ressourcen wie Header-Icons oder Chat-Widget-Skripte im <body> höher platziert sind als das LCP-Element, werden sie zuerst entdeckt und für den Download eingereiht. Das verbraucht anfängliche Netzwerkbandbreite und kann den Download der LCP-Ressource verzögern. Ein großes HTML-Dokument kann ebenfalls ein Problem sein; wenn das LCP-Element nicht im ersten Datenpaket steckt, das der Browser empfängt (etwa 14 KB), verzögert sich seine Entdeckung um mindestens einen Network Round Trip.

Die Lösung: Optimiere die Struktur und Priorität der Inhalte im HTML.

• HTML neu anordnen: Stelle, wenn möglich, sicher, dass das <img>-Tag oder der Textblock für das LCP-Element so früh wie möglich im <body>-Tag erscheint.
• Nicht-kritische Bilder de-priorisieren: Wende bei unwichtigen Bildern, die früh im HTML-Quelltext erscheinen müssen (wie Icons im Header), loading="lazy" an. Das weist den Preload Scanner an, sie zu überspringen, und hält die Download-Warteschlange für das LCP-Element frei.
• Nicht-essenzielle Skripte zurückstellen: Skripte für Analytics, Werbung oder Social-Media-Widgets sind selten kritisch für den ersten Render. Verschiebe ihre <script>-Tags ans Ende des <body> oder nutze das defer-Attribut. Das 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 auffindbar ist, kannst du Resource Hints nutzen, um dem Browser explizitere Anweisungen für den Abruf zu geben. Diese Hints bieten eine feingranulare Kontrolle über Entdeckung und Priorisierung.

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

<link rel="preload"> ist kein Hint, sondern eine Direktive. Es zwingt den Browser, eine Ressource mit hoher Priorität herunterzuladen, auch wenn der Main-Parser sie noch nicht entdecken kann. Die Platzierung im <head> deines HTMLs ist der direkteste Weg, um Probleme mit später Entdeckung zu beheben – etwa bei Fonts, CSS-Hintergrundbildern oder LCP-Bildern tief im DOM. Für vollständige Implementierungsdetails und Beispiele, schau in unseren speziellen Leitfaden: Wie man das LCP-Bild preloadet.

Mechanismus

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

Responsives Preloading

Beim Preloaden von responsiven Bildern ist ein kritisches Implementierungsdetail erforderlich. Um sicherzustellen, dass der Browser das Bild in der richtigen Größe für den Viewport des Nutzers preloadet und einen unnötigen doppelten Download vermeidet, muss das <link rel="preload">-Tag die Attribute imagesrcset und imagesizes enthalten. Diese müssen die Attribute auf dem entsprechenden <img>-Tag perfekt spiegeln.

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

Potenzieller Stolperstein

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

fetchpriority="high" und die Prioritäts-Warteschlange des Browsers

Das fetchpriority-Attribut ist ein Hint, der die relative Wichtigkeit des Downloads einer Ressource signalisiert. Damit kannst du die Priorität einer Ressource innerhalb der Download-Warteschlange des Browsers beeinflussen.

Wie die Browser-Priorität funktioniert

Wenn der Browser beim Laden der Seite Ressourcen entdeckt, weist er jeder eine interne Prioritätsstufe zu. Standardmäßig starten Bilder im Viewport mit der Priorität „Low“ und werden später auf „High“ hochgestuft, sobald der Browser das Layout abschließt und feststellt, dass sie sichtbar sind. Für dieses Upgrade muss der Browser zuerst CSS herunterladen und parsen, was eine Verzögerung erzeugt. Das Attribut fetchpriority="high" umgeht diesen Prozess komplett, indem es das Bild vom Moment der Entdeckung an auf Priorität „High“ setzt. Das ist für LCP-Bilder besonders wirkungsvoll, da es die Verzögerung durch das Prioritäts-Upgrade eliminiert.

preload vs. fetchpriority

Diese beiden Hints erfüllen unterschiedliche, aber sich ergänzende Zwecke. preload beeinflusst, wann eine Ressource entdeckt und zur Warteschlange hinzugefügt wird. fetchpriority beeinflusst ihre Prioritätsstufe, sobald sie in der Warteschlange ist. Diesen Unterschied zu verstehen, ist kritisch: Preload löst eine späte Entdeckung, während fetchpriority eine niedrige Priorisierung löst. Bei vielen LCP-Bildern, die bereits im HTML stehen, kann fetchpriority allein ausreichen. Für einen vollständigen Leitfaden, wie diese interagieren, lies unseren Artikel über Ressourcen-Priorisierung.

Best Practice für den LCP

Beim LCP-Bild ist die optimale Strategie, sie zusammen zu verwenden. Sorge erstens für eine frühe Entdeckung, indem du das <img>-Tag weit oben im HTML platzierst oder preload verwendest. Füge zweitens 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 du fetchpriority="low" nutzen solltest

Das fetchpriority-Attribut dient nicht nur zum Anheben der Priorität. Du kannst auch fetchpriority="low" nutzen, um nicht-kritische Ressourcen zu depriorisieren, die mit dem LCP-Bild um Bandbreite konkurrieren. Häufige Kandidaten dafür sind Above-the-fold-Bilder, die nicht das LCP-Element sind (wie kleine Icons oder Avatare im Header), sowie preloaded Ressourcen, die zwar benötigt werden, aber nicht dringend sind. Indem du die Priorität dieser konkurrierenden Ressourcen explizit senkst, schaffst du 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">

Erwiesene 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 700 ms.

Third-Party-Verbindungen optimieren: preconnect und dns-prefetch

Das Problem

Wenn deine LCP-Ressource auf einer Third-Party-Domain gehostet wird, zum Beispiel einem Image-CDN oder einem Font-Anbieter wie Google Fonts, muss der Browser eine neue Netzwerkverbindung zu dieser Domain herstellen. Dieser Prozess umfasst einen DNS-Lookup, einen TCP-Handshake und eine TLS-Negotiation. All das muss abgeschlossen sein, bevor das erste Byte der Ressource heruntergeladen werden kann. Diese Verbindungsaufbauzeit trägt bei Cross-Origin-Assets direkt zur Resource Load Delay bei.

Die Lösungen

• preconnect: Dieser Hint weist den Browser an, den vollständigen Verbindungsaufbau (DNS, TCP und TLS) für eine bestimmte Third-Party-Origin vorab im Hintergrund durchzuführen. Wenn die Ressource tatsächlich angefordert wird, ist die Verbindung bereits warm, was die Setup-Latenz eliminiert. Das ist sehr effektiv und für die ein oder zwei kritischsten Third-Party-Domains zu empfehlen, die LCP-Ressourcen ausliefern.
• dns-prefetch: Das ist ein leichtgewichtigerer Hint, der nur den DNS-Lookup für eine Domain ausführt. Er spart weniger Zeit als preconnect, hat aber eine breitere Browser-Unterstützung und ist nützlich als Fallback oder für weniger kritische Third-Party-Domains.

Implementierungs-Best-Practice

Um maximale Kompatibilität zu gewährleisten, gibst du beide Hints an. Der Browser nutzt preconnect, falls unterstützt, und fällt ansonsten auf dns-prefetch zurück. Das crossorigin-Attribut ist für Ressourcen essenziell, die über CORS abgerufen werden, wie zum Beispiel 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 vorzubeugen und die unterschiedlichen Rollen dieser mächtigen Hints zu klären, liefert die folgende Tabelle eine vergleichende Zusammenfassung.

Ganzheitliche und zukunftsweisende Strategien

Über Resource Hints hinaus können umfassendere Architektur-Entscheidungen die Resource Load Delay noch weiter reduzieren.

Die Rolle eines modernen CDNs

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

• Verbindungs-Overhead reduzieren: Indem ein CDN Assets über ein globales Netzwerk von Servern verteilt, rückt es Inhalte geografisch näher an den Nutzer. Das verringert von Natur aus die Round-Trip Time (RTT), die für den DNS-Lookup, den TCP-Handshake und die TLS-Negotiation erforderlich ist – alles Bestandteile der Verbindungsaufbauzeit. Für ein LCP-Bild, das auf einem CDN gehostet wird, reduziert dies direkt seine Load Delay.
• Image-CDNs: Spezialisierte Image-CDNs bieten einen doppelten Vorteil. Sie liefern den Nähe-Vorteil eines Standard-CDNs und automatisieren gleichzeitig viele komplexe Optimierungen, die die Resource Load Duration reduzieren, wie etwa die On-the-fly-Bildgrößenanpassung, Komprimierung und Konvertierung in moderne Formate wie AVIF und WebP.
• Fortschrittliche Protokolle: Viele moderne CDNs nutzen HTTP/3, welches QUIC anstelle von TCP verwendet. HTTP/3 reduziert die Verbindungsaufbauzeit und entschärft das Head-of-Line-Blocking, was insgesamt zu einer schnelleren und effizienteren Ressourcenauslieferung führt.

Verzögerungen mit Speculation Rules komplett eliminieren

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

Mechanismus

Diese API erlaubt es Entwicklern, den Browser deklarativ darüber zu informieren, zu welchen URLs ein Nutzer wahrscheinlich als Nächstes navigieren wird. Basierend auf diesen Regeln kann der Browser entscheiden, eine Zielseite in einem versteckten Hintergrund-Tab zu prerendern, noch bevor der Nutzer auf den Link klickt.

Auswirkung auf den LCP

Klickt der Nutzer auf einen Link zu einer geprerenderten Seite, erfolgt die Navigation praktisch augenblicklich. Die Seite wurde bereits vollständig geladen und im Hintergrund gerendert. Bei dieser Navigation sind die TTFB, die Resource Load Delay, die Resource Load Duration und die Element Render Delay aus Nutzersicht effektiv auf nahezu null reduziert.

Beispiel-Anwendungsfall

Auf einer E-Commerce-Kategorieseite könnten Speculation Rules genutzt werden, um die Produktdetailseiten für die ersten paar Artikel in der Liste zu prerendern. Klickt ein Nutzer auf eines dieser Produkte, erscheint die Seite sofort.

Fallstudien-Synthese: Von der Theorie in die Praxis

Diese Optimierungen haben messbare Auswirkungen in der echten Welt.

• Fall 1: Die transformative Kraft des Preloadings: Ein Experiment von DebugBear auf einer Seite mit hoher Load Delay liefert ein dramatisches Beispiel. Das LCP-Bild war in einer Request-Kette versteckt, was dazu führte, dass die Resource Load Delay sagenhafte 75 % der gesamten LCP-Zeit ausmachte. Durch die Implementierung eines einzigen <link rel="preload">-Hints, um das Bild frühzeitig auffindbar zu machen, wurde die Resource Load Delay auf nur 2 % der LCP-Zeit reduziert. Das zeigt, wie eine simple Architektur-Korrektur einen massiven Performance-Engpass lösen kann.
• Fall 2: Das echte loading="lazy"-Anti-Pattern: Ein Entwickler auf Stack Overflow meldete einen Desktop-LCP mit einer verblüffenden Load Delay von 1.430 ms trotz schnellem Netzwerk. Die Ursache wurde auf ein Bildoptimierungs-Plugin zurückgeführt, das fälschlicherweise lazy loading auf das LCP-Bild anwandte, indem es dessen src-Attribut durch ein transparentes Platzhalter-SVG ersetzte. Die endgültige Lösung bestand darin, dieses Verhalten für das LCP-Element zu deaktivieren, sodass es entdeckt und eager geladen werden konnte. Das veranschaulicht, wie Drittanbieter-Tools unbeabsichtigt gravierende Load Delays verursachen können.
• Fall 3: Der fetchpriority-Performance-Boost: Die Google Flights-Fallstudie liefert klare Beweise für die Wirkung expliziter Priorisierung. Durch einfaches Hinzufügen von fetchpriority="high" zum LCP-Hintergrundbild der Seite verbesserte sich der LCP-Wert um 700 ms und sank von 2,6 Sekunden auf 1,9 Sekunden. Das demonstriert, dass selbst bei einer auffindbaren Ressource das Signalisieren ihrer hohen Wichtigkeit an den Browser ein kritischer Schritt ist, um das Rennen um Netzwerkbandbreite zu gewinnen.

Network Inspection in den Chrome DevTools: Nutze das Kürzel Strg + Umschalt + I, um die Developer Tools von Chrome zu öffnen, wähle dann den Tab „Network“ und lade die Seite neu. Sieh dir die Ladesequenz an. Deine LCP-Ressource sollte eines der ersten Elemente sein, die für den Download eingereiht werden. Hinkt sie hinter anderen Elementen her, gibt es ein Problem mit der Resource Load Delay. Unten siehst du ein Beispiel einer Seite, bei der die Resource Load Delay nicht optimiert wurde.

Nutze Real User Monitoring (RUM)-Daten: Real User Monitoring-Tools protokollieren oft LCP-Attribution-Daten. Mit RUM kannst du den Breakdown der LCP-Unterphasen visualisieren (im Zeitverlauf oder nach Seite) und erhältst so ein klares Bild der Load Delay für LCP-Elemente auf deiner gesamten Seite oder pro Seite. Das Beispiel unten zeigt einen globalen LCP-Breakdown zusammen mit der entsprechenden Load Delay.

Wie du die Load Delay verbesserst

Eine Resource Load Delay entsteht, wenn die Download-Reihenfolge und das Timing der Ressourcen nicht optimal sind. Im Grunde gibt es zwei direkte Wege, das zu beheben: Priorisiere die LCP-Ressource oder de-priorisiere Non-LCP-Ressourcen. Lass uns einige häufige Muster ansehen:

LCP-Tipp: Verstehe den Preload Scanner: Moderne Browser nutzen einen Mechanismus namens Preload Scanner, der das HTML schnell scannt und Ressourcen für den Download einreiht. Kann eine Ressource nicht vom Preload Scanner eingereiht werden, muss sie auf den langsameren DOM-Parser warten, was zu Verzögerungen führt. Sicherzustellen, dass deine LCP-Ressourcen vom Preload Scanner auffindbar sind, kann einen großen Unterschied bei der Reduzierung der Load Delay machen.

1. Optimiere die HTML-Struktur

Der Browser (oder der Preload Scanner) verarbeitet dein HTML von oben nach unten und reiht Ressourcen in der Reihenfolge ein, in der sie erscheinen. Das heißt: Je weiter oben die LCP-Ressource im HTML steht, desto früher wird sie eingereiht. Um das zu optimieren, entferne oder verzögere nicht benötigte Ressourcen aus dem oberen Bereich des HTMLs:

• Lade unwichtige oder versteckte Bilder lazy: Manchmal befinden sich Bilder (zum Beispiel Flaggen für sprachspezifische Versionen deiner Seite oder Bilder im Menü) ganz oben im HTML deiner Seite. Diese Bilder sind nicht ansatzweise so wichtig wie das LCP-Element. Wenn du diese Bilder lazy lädst, werden sie vom Preload Scanner übersprungen und erst etwas später im Ladeprozess eingereiht.
• Verschiebe unwichtige Skripte ans Ende der Seite: Verschiebe Skripte, die für das initiale Laden absolut unwichtig sind, ans Ende der Seite. Das verhindert, dass sie kritische Ressourcen verzögern. Ein Beispiel ist ein Chat-Widget. Niemand in der Geschichte des Internets musste jemals chatten, bevor die Seite sichtbar war!

2. Vermeide Hintergrundbilder

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, nutze stattdessen ein reguläres <img>-Tag, kombiniert mit der CSS-Eigenschaft object-fit: cover, um das Aussehen eines Hintergrundbildes nachzuahmen. Auf diese Weise kann der Preload Scanner das Bild sofort erkennen und einreihen.

3. Nutze Fetch Priority

Füge das fetchpriority="high"-Attribut zu deinem LCP-Element hinzu. Das ist ein Hint für den Browser, dass er diese Ressource von Anfang an priorisieren soll. Normalerweise laden Bilder mit einer niedrigen oder mittleren Standardpriorität. Während der Layout-Phase stuft der Browser sichtbare Elemente auf eine hohe Priorität hoch. Wenn du fetchpriority="high" setzt, beginnt der Download sofort mit hoher Priorität. Das sorgt für einen schnelleren LCP.

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

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

4. Implementiere Preloading

Preloading ändert die Reihenfolge, in der der Preload Scanner Dateien einreiht. Platziere 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 genutzt werden, um Ressourcen vorzuladen, die später im HTML referenziert werden (und daher später eingereiht werden), oder sogar für Ressourcen, die noch gar nicht im HTML stehen (wie bei manchen Slidern). Für maximale Effektivität empfiehlt es sich, Preloads nach den Stylesheets und vor den Skripten im Head der Seite zu platzieren.

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

5. Optimiere Styles

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 Render-Phase nicht starten. Allerdings konkurrieren übermäßige CSS-Größe und eine zu hohe Anzahl an Stylesheets mit der LCP-Ressource um die frühe Bandbreite.

6. Implementiere effizientes Lazy-Loading

Das loading-Attribut kann ein zweischneidiges Schwert sein. Nutze loading="eager" (oder lass das Attribut einfach weg, da "eager" der Browser-Standard ist) für deine LCP-Ressource, während du loading="lazy" für Offscreen-Bilder anwendest.

• Lade das LCP-Element eager: Wenn das LCP-Element lazy geladen wird, reiht der Preload Scanner es nicht ein. Es lädt viel später, was sich negativ auf die Performance auswirkt.
• Lade Viewport-Bilder lazy: Nutze für Bilder, die im sichtbaren Viewport sind, aber keine LCP-Ressourcen darstellen, loading="lazy". So werden sie etwas später für den Download eingereiht. Das reduziert den Bandbreiten-Wettbewerb mit der LCP-Ressource.
• Vermeide Lazy-Loading bei Offscreen-Bildern: Bilder, die nicht im sichtbaren Viewport sind, lösen überhaupt keinen Download aus, was den Bandbreiten-Wettbewerb komplett eliminiert.

7. Browser-Caching

Browser-Caching erlaubt es dir, Netzwerk-Requests für Ressourcen zu überspringen, die bereits lokal auf dem Gerät des Nutzers gespeichert sind. Auch wenn 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 Cachen der LCP-Ressource selbst eine großartige Strategie ist, verbessert Browser-Caching die LCP Resource Load Delays, indem es Netzwerkressourcen speichert, die mit der LCP-Ressource konkurrieren oder sie verzögern könnten, wie etwa Skripte, Stylesheets und Bilder.
• Serverlast reduzieren: Caching verringert die Anzahl der an deinen Server gesendeten Requests. Das kann die Performance anderer Ressourcen verbessern, indem es Bandbreite freigibt und Server-CPU-Zyklen reduziert.

8. Nutze Speculation Rules

Speculation Rules ermöglichen es Browsern, Webseiten basierend auf der vorhergesagten Nutzer-Navigation zu prefetchen oder zu prerendern. Prefetching eliminiert effektiv die Time to First Byte-Unterphase des LCPs 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. Das eliminiert alle Load Delays für das LCP-Element, wie dieser beispielhafte LCP-Breakdown einer geprerenderten Seite zeigt.

9. Vermeide Client-Side Rendering

Nächste Schritte: Optimiere den LCP weiter

Die Resource Load Delay ist eine von vier LCP-Phasen. Sobald du die Entdeckungslatenz minimiert hast, mach mit diesen Leitfäden weiter:

• LCP-Probleme finden &amp;amp; beheben: Die komplette Diagnose-Methodik, um alle LCP-Probleme zu finden und zu beheben.
• Das LCP-Bild optimieren: Auswahl von Bildformaten, responsive Bilder, Preloading und häufige Bildfehler.
• Resource Load Duration: Reduziere die Download-Dauer nach der Entdeckung der Ressource durch Komprimierung, moderne Formate und CDN-Optimierung.
• Element Render Delay: Stelle nach dem Ressourcen-Download sicher, dass der Browser das Element sofort zeichnen kann, indem du den Main Thread freimachst.