Optimiere die LCP-Ressourcen-Ladeverzögerung

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, insbesondere bei SPA-Websites! 

Optimiere die LCP Resource Load Delay

Der Largest Contentful Paint (LCP) besteht aus vier Teilphasen: TTFB, Resource Load Delay, Resource Load Duration und Element Render Delay. 

Ein kurzer Tipp: Wenn dein LCP ein Bild ist, ist er fast immer schlechter als bei Text. Du musst die LCP-Elementtypen in deinen RUM-Daten erfassen, sonst fliegst du blind.

Was ist die Resource Load Delay?

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

Ein hoher Wert deutet auf ein Architekturproblem hin, bei dem der Browser die Ressourcen-URL im initialen HTML-payload nicht finden kann. Diese Resource Load Delay entspricht der Zeit, die der Browser benötigt, um zu erkennen, dass die LCP-Ressource benötigt wird, und um deren Abruf zu beschließen.

Es ist auch wichtig zu verstehen, dass die Resource Load Delay auftritt, bevor die Ressource tatsächlich geladen wird. Deshalb hat sie nichts mit responsiven Bildern oder neuen Bildformaten wie WebP oder AVIF zu tun.

Bei textbasierten LCP-Elementen, die eine Systemschriftart nutzen, ist diese Resource Load Delay normalerweise null, da keine externe Ressource geladen werden muss. Höhere Werte bei der Resource Load Delay treten nur bei LCP-Elementen auf, die von einer externen Netzwerkressource wie einem Bild oder einer Videodatei abhängen.

Wie findet ein Browser das LCP-Element?

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

• Der DOM-Parser (langsamer Pfad): Das ist der Hauptparser des Browsers, und er ist extrem mächtig. Er baut die gesamte Seite auf,  indem er HTML und Stylesheets liest und mit JavaScript interagiert. Das ist der langsame Pfad, da er durch das Laden und Ausführen anderer Dateien verzögert und gestoppt werden kann. Dadurch entsteht eine Abhängigkeitskette, die Verzögerungen verursacht.
• Der Preload-Scanner (schneller Pfad): Da der DOM-Parser (verhältnismäßig) langsam ist, nutzen Browser einen blitzschnellen sekundären Scanner. Dieser scannt die Seite sehr schnell nach ladbaren Ressourcen und lässt sich durch nichts aufhalten. Wenn er <script>-, nicht-lazy <img>- oder <link>-Tags findet, reiht er sie sofort für den Download ein – noch bevor CSS analysiert 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 einzigen Prinzip: Stelle sicher, dass die URL der LCP-Ressource so früh wie möglich für den Preload-Scanner auffindbar ist.

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

1. Stelle sicher, dass der Preload-Scanner es finden kann, indem du ein normales Bild-Tag verwendest, das nicht das Attribut loading="lazy" besitzt.
2. Stelle sicher, dass der Preload-Scanner nicht zu viele weniger wichtige Ressourcen priorisiert.

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

Einsteiger-Entwickler denken oft, dass der LCP ein „Dateigrößen“-Problem ist. 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 einzelne Flaschenhals beim LCP der 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, dass die Load Delay fast vollständig behebbar ist, während ein TTFB immer existieren wird. Das macht die Load Delay zum Element mit dem höchsten Optimierungspotenzial.

So erkennst du die Resource Load Delay

Um die Resource Load Delay zu beheben, musst du sie zuerst genau messen. Der Workflow ist immer gleich: Überprüfe die Werte mit CrUX, um das Problem zunächst mit echten Nutzerdaten (RUM) zu definieren, und wechsle erst dann für eine Tiefenanalyse zu den Chrome DevTools.

Schritt 1: Mit CrUX prüfen

CrUX sind Googles öffentlich zugängliche field data von berechtigten Chrome-Nutzern, dargestellt als rollierende 28-Tage-Ansicht deiner Core Web Vitals beim 75. Perzentil. Sie verraten dir, ob ein Wert gut oder schlecht ist, aber nicht wer, was oder warum. Da Google sich auf CrUX-Daten verlässt, ist dies dein bester Ausgangspunkt.

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

Schritt 2: Field data analysieren (RUM)

RUM erfasst die Core Web Vitals all deiner echten Nutzer und bietet dir eine viel spezifischere, detailliertere Ansicht. RUM sagt dir, wer und was betroffen ist, beliebig segmentiert (und diese Information ist Gold wert), aber nicht warum.

Schritt 3: Diagnose mit den 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 ist es, das Problem zu reproduzieren und die LCP-Teilphasen zu messen, um einen präzisen Wert für die Resource Load Delay zu erhalten. In den DevTools führst du auch eine Analyse des main threads durch, um genau zu sehen, welche Tasks laufen und eventuell den Rendering-Prozess blockieren.

Schritt-für-Schritt-Anleitung für das Chrome DevTools Performance Panel

Das Performance Panel in den Chrome DevTools ist ein unverzichtbares Werkzeug, um den LCP zu zerlegen und die Load Delay zu beziffern.

1. Einrichtung und Konfiguration:

• Öffne die Chrome DevTools per Rechtsklick auf die Seite und Auswahl von „Untersuchen“ oder mit dem Tastenkürzel Strg+Shift+I (Windows/Linux) bzw. Cmd+Option+I (Mac).
• Navigiere zum Reiter „Performance“.
• Stelle sicher, dass das Kontrollkästchen „Web Vitals“ in den Aufnahme-Einstellungen aktiviert ist. Dadurch werden Core Web Vitals-Informationen auf der Performance-Timeline eingeblendet.
• Um realistische Nutzerbedingungen zu simulieren, aktiviere CPU- und Netzwerk-Throttling. Eine „4-fache Verlangsamung“ (4x slowdown) für die CPU und ein Netzwerkprofil wie „Fast 3G“ oder „Slow 4G“ sind gängige Ausgangspunkte für mobile Tests.

2. Aufzeichnen eines Performance-Profils:

• Klicke 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-Spur: Suche in der Haupt-Timeline-Ansicht nach der Spur „Timings“. Dort findest du eine mit „LCP“ beschriftete Markierung. Wenn du den Mauszeiger über diese Markierung bewegst, wird das entsprechende LCP-Element im Screenshot des viewports hervorgehoben und die LCP-Gesamtzeit angezeigt.
• Aufteilung des LCP nach Phasen: Klicke auf die LCP-Markierung in der Timings-Spur. Im Reiter „Summary“ unten im Panel findest du eine detaillierte Aufteilung der LCP-Zeit. Diese zeigt explizit die Dauer jeder der vier Teilphasen in Millisekunden, einschließlich der Load Delay. Dieser Wert ist die direkteste und präziseste Messung der Resource Load Delay für diesen spezifischen Seitenaufruf.
• Analyse des main threads: Achte beim Betrachten der Timeline in der Spur „Main“ auf long tasks (Aktivitätsblöcke, die mit einem roten Dreieck gekennzeichnet sind). Wenn diese long tasks auftreten, nachdem das Laden der LCP-Ressource abgeschlossen ist, aber vor der LCP-Markierung liegen, 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 hat eine von zwei Ursachen: Die LCP-Ressource wird zu spät entdeckt oder sie erhält eine zu niedrige Priorität beim Abruf. Hier sind die häufigsten Architekturfehler und ihre Lösungen.

Ursache: LCP wird über CSS geladen

Das Problem: Der Preload-Scanner parst keine CSS-Dateien. Wenn dein LCP-Bild über ein CSS-background-image definiert ist, bleibt seine URL für diesen schnellen 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 schließlich den Style angewendet hat. Diese Abhängigkeitskette verursacht direkt eine hohe Resource Load Delay. Weitere Informationen zu diesem Pattern findest du in unserem Leitfaden über das Aufschieben von Hintergrundbildern.

Die Lösung: Die richtige Implementierung besteht darin, background-image für kritische LCP-Elemente zu vermeiden. Verwende stattdessen ein standardmäßiges <img>-Tag. Dadurch wird die Bild-URL direkt im HTML platziert, wo der Preload-Scanner sie sofort finden kann. Das gleiche visuelle Ergebnis lässt sich mit CSS erzielen.

Implementierungsbeispiel:

Anti-Pattern (tu das nicht):

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

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

Best Practice (mach es stattdessen so):

    <!-- 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>Seitentitel</h1>
      </div>
    </div>

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

   .hero-background-img {
      position: absolute;
      inset: 0; /* Entspricht top: 0; right: 0; bottom: 0; left: 0; */
      width: 100%;
      height: 100%;
      object-fit: cover; /* Diese Eigenschaft imitiert background-size: cover */
      z-index: -1; /* Platziert das Bild hinter anderen Inhalten */
    }
    

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

Ursache: Client-Side Rendering und JavaScript-Injektion

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 – inklusive des LCP-<img>-Tags – wird erst nach dem Herunterladen, Parsen und Ausführen großer Framework-Bundles per JavaScript in das DOM eingefügt. Dieser Prozess verbirgt die LCP-Ressource prinzipiell vor dem Preload-Scanner, was zu einer hohen Verzögerung bei der Erkennung führt.

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): Architektur-Patterns wie SSR oder SSG erzeugen das vollständige HTML auf dem Server. Der Browser erhält ein fertiges Dokument, das das <img>-Tag und sein src-Attribut bereits enthält. Dadurch kann der Preload-Scanner die LCP-Ressource sofort finden. Dies ist die notwendige Architektur für jede performance-kritische Seite.
• Framework-spezifische Optimierungen: Moderne Frameworks bieten auch integrierte Optimierungen. Beispielsweise besitzt die <Image>-Komponente von Next.js ein „priority“-Attribut. Wenn dieses auf true gesetzt wird, fügt das Framework automatisch die korrekten Attribute <link rel="preload"> und fetchpriority="high" hinzu. So wird sichergestellt, dass das Bild mit der richtigen Priorität erkannt und abgerufen wird.

Ursache: Verwendung von loading="lazy" auf dem LCP-Bild

Das Problem: Dies ist ein häufiger und folgenschwerer Fehler. Das Attribut loading="lazy" ist die direkte Anweisung an den Browser, den Abruf eines Bildes zu verzögern, bis es sich nahe dem viewport befindet. Während dies für Bilder unterhalb des sichtbaren Bereichs (below-the-fold) die richtige Optimierung ist, ist es für ein oberhalb des sichtbaren Bereichs (above-the-fold) liegendes LCP-Element kontraproduktiv. Der Preload-Scanner des Browsers ist so konzipiert, dass er Bilder mit loading="lazy" ignoriert, was eine späte Erkennung und eine hohe Resource Load Delay garantiert.

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

• Entferne loading="lazy" vom LCP-Bild: Jedes Bild, das wahrscheinlich das LCP-Element ist, darf nicht das Attribut loading="lazy" besitzen. Das Standardverhalten des Browsers ist loading="eager". Dies ist die richtige Einstellung für kritische Inhalte über dem Falz (above-the-fold). Das vollständige Weglassen des loading-Attributs hat denselben Effekt.
• Prüfe und konfiguriere Drittanbieter-Tools: Du musst auch Drittanbieter-Tools überprüfen. Viele CMS-Plattformen wie WordPress und verschiedene Plugins zur Bildoptimierung wenden automatisch lazy loading auf alle Bilder an. Es ist wichtig, diese Tools so zu konfigurieren, dass das LCP-Bild von diesem Verhalten ausgenommen wird. Dies 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 unkritische, aber bandbreitenintensive Ressourcen wie Header-Icons oder Chat-Widget-Skripte im <body> weiter oben platziert sind als das LCP-Element, werden sie zuerst entdeckt und für den Download eingereiht. Dies verbraucht die anfängliche Netzwerkbandbreite und kann den Download der LCP-Ressource verzögern. Auch ein großes HTML-Dokument kann ein Problem sein: Wenn sich das LCP-Element nicht im ersten vom Browser empfangenen Daten-Chunk (ca. 14 KB) befindet, verzögert sich seine Entdeckung um mindestens einen Netzwerk-Roundtrip.

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

• HTML-Reihenfolge anpassen: Stelle wenn möglich 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 deprioritisieren: Wende auf nicht essenzielle Bilder, die früh im HTML-Quellcode erscheinen müssen (wie Icons im Header), loading="lazy" an. Dies weist den Preload-Scanner an, sie zu überspringen, wodurch die Download-Warteschlange für das LCP-Element freigehalten wird.
• Nicht-essenzielle Skripte aufschieben: Skripte für Analysen, Werbung oder Social-Media-Widgets sind für das initiale Rendering selten kritisch. Verschiebe ihre <script>-Tags an das Ende des <body> oder nutze das Attribut defer. 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 auffindbar ist, kannst du Resource Hints nutzen, um dem Browser präzisere Anweisungen für den Abruf zu geben. Diese Hints ermöglichen eine feine Steuerung von Entdeckung und Priorisierung.

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

<link rel="preload"> ist kein Hint, sondern eine Direktive. Sie zwingt den Browser, eine Ressource mit hoher Priorität herunterzuladen, selbst wenn sie für den Hauptparser noch nicht auffindbar ist. Die Platzierung im <head> deines HTML ist der direkteste Weg, um Probleme bei der späten Erkennung von Ressourcen wie Schriftarten, CSS-Hintergrundbildern oder tief im DOM liegenden LCP-Bildern zu beheben. Vollständige Implementierungsdetails und Beispiele findest du in unserem speziellen Leitfaden zum Thema Preloading des LCP-Bildes.

Mechanismus

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

Responsives Preloading

Ein wichtiges Implementierungsdetail ist beim Preloading von responsiven Bildern erforderlich. Um sicherzustellen, dass der Browser das Bild in der richtigen Größe für den viewport des Nutzers vorab lädt und einen unnötigen doppelten Download vermeidet, muss das <link rel="preload">-Tag die Attribute imagesrcset und imagesizes 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">
    

Potenzieller Fallstrick

Preloading löst das Timing für den Abruf (fetch timing – Load Delay und Load Duration), aber nicht das Timing für die Darstellung (paint timing). Wenn der main thread durch umfangreiches JavaScript oder render-blocking CSS blockiert ist, sobald das vorab geladene Bild eintrifft, muss das Bild dennoch auf das Rendering warten. Dadurch kann sich der Flaschenhals von der Load Delay zur Element Render Delay verschieben.

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

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

Wie die Priorisierung im Browser 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“ (niedrig) und werden später auf „High“ (hoch) hochgestuft, sobald der Browser das Layout fertiggestellt hat und feststellt, dass sie sichtbar sind. Dieses Upgrade erfordert, dass der Browser zuerst CSS herunterlädt und parst, was eine Verzögerung verursacht. Das Attribut fetchpriority="high" umgeht diesen Prozess vollständig, indem es das Bild ab dem Moment seiner Entdeckung auf die Priorität „High“ setzt. Dies ist besonders für LCP-Bilder wirkungsvoll, da es die Verzögerung durch das Prioritäts-Upgrade eliminiert.

preload im Vergleich zu fetchpriority

Diese beiden Hints dienen unterschiedlichen, aber sich ergänzenden Zwecken. preload beeinflusst, wann eine Ressource entdeckt und zur Warteschlange hinzugefügt wird. fetchpriority beeinflusst ihre Prioritätsstufe, sobald sie sich in der Warteschlange befindet. Diesen Unterschied zu verstehen, ist entscheidend: Preload löst die späte Entdeckung, während Fetchpriority eine niedrige Priorisierung behebt. Für viele LCP-Bilder, die sich bereits im HTML befinden, kann Fetchpriority allein ausreichend sein. Einen vollständigen Leitfaden zum Zusammenspiel dieser beiden Elemente findest du in unserem Artikel über Ressourcenpriorisierung.

Best Practice für den LCP

Für das LCP-Bild ist es die beste Strategie, beide gemeinsam zu nutzen. Stelle erstens eine frühe Entdeckung sicher – entweder durch eine frühe Platzierung des <img>-Tags im HTML oder durch preload. Füge zweitens fetchpriority="high" direkt im <img>-Tag (und ggf. im preload-Link) hinzu. Diese Kombination sorgt dafür, 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 Schriftarten zu gewinnen.

Beispiel:

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

Wann man fetchpriority="low" verwendet

Das Attribut fetchpriority dient nicht nur der Prioritätssteigerung. Du kannst auch fetchpriority="low" nutzen, um unkritische Ressourcen zu deprioritisieren, die mit dem LCP-Bild um Bandbreite konkurrieren. Typische Kandidaten dafür sind Bilder über dem Falz (above-the-fold), die nicht das LCP-Element sind (wie kleine Icons oder Avatare im Header), sowie vorab geladene Ressourcen, die zwar benötigt werden, aber nicht eilen. Indem du die Priorität dieser konkurrierenden Ressourcen explizit senkst, schaffst du mehr Bandbreitenspielraum für das LCP-Bild.

<!-- LCP-Bild: hohe Priorität -->
<img src="hero.jpg" fetchpriority="high" alt="Hero image" width="1200" height="600">

<!-- Unkritisches Bild über dem Falz (above-fold): niedrige Priorität -->
<img src="avatar.jpg" fetchpriority="low" alt="Author avatar" width="48" height="48">

Nachgewiesener Effekt

In einer Fallstudie zu 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.

Drittanbieter-Verbindungen optimieren: preconnect und dns-prefetch

Das Problem

Wenn deine LCP-Ressource auf einer externen Domain gehostet wird, wie etwa einem Bild-CDN oder einem Schriftarten-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-Aushandlung, die alle abgeschlossen sein müssen, bevor das erste Byte der Ressource heruntergeladen werden kann. Diese Zeit für den Verbindungsaufbau 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 einen bestimmten Drittanbieter-Origin vorab im Hintergrund durchzuführen. Wenn die Ressource tatsächlich angefordert wird, steht die Verbindung bereits, was die Setup-Latenz eliminiert. Dies ist äußerst 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, bietet jedoch eine breitere Browserunterstützung und ist nützlich als Fallback oder für weniger kritische Drittanbieter-Domains.

Implementation Best Practice

Um maximale Kompatibilität zu gewährleisten, stelle beide Hints bereit. Der Browser nutzt dann preconnect, sofern unterstützt, und weicht andernfalls auf dns-prefetch aus. Das Attribut crossorigin ist für Ressourcen, die über CORS abgerufen werden (wie z. B. Schriftarten), zwingend erforderlich.

<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: Vergleich der Resource Hints für die LCP-Optimierung

Um Missbrauch vorzubeugen und die unterschiedlichen Rollen dieser mächtigen Hints zu verdeutlichen, bietet die folgende Tabelle eine vergleichende Übersicht.

Ganzheitliche und zukunftsweisende Strategien

Abseits von Resource Hints können umfassendere Architekturentscheidungen die Resource Load Delay noch weiter reduzieren.

Die Rolle eines modernen CDN

Die Rolle eines modernen CDN

• Reduzierung des Verbindungs-Overheads: Durch die Verteilung von Assets über ein globales Servernetzwerk platziert ein CDN Inhalte geografisch näher am Nutzer. Dies reduziert von Natur aus die Round-Trip-Time (RTT), die für DNS-Lookup, TCP-Handshake und TLS-Aushandlung erforderlich ist – allesamt Komponenten des Verbindungsaufbaus. Für ein auf einem CDN gehostetes LCP-Bild reduziert dies direkt dessen Load Delay.
• Bild-CDNs (Image CDNs): Spezialisierte Bild-CDNs bieten einen doppelten Vorteil. Sie bieten den räumlichen Vorteil eines Standard-CDNs und automatisieren gleichzeitig viele komplexe Optimierungen, die die Resource Load Duration verkürzen – wie die Bildgrößenanpassung im laufenden Betrieb (on-the-fly), Komprimierung und die Konvertierung in moderne Formate wie AVIF und WebP.
• Moderne Protokolle: Viele moderne CDNs nutzen HTTP/3, das auf QUIC statt TCP setzt. HTTP/3 verkürzt den Verbindungsaufbau und entschärft das Head-of-Line-Blocking, was insgesamt zu einer schnelleren und effizienteren Bereitstellung von Ressourcen führt.

Verzögerungen mit Speculation Rules komplett eliminieren

Diese API ermöglicht es Entwicklern, den Browser deklarativ darüber zu informieren, welche URLs ein Nutzer wahrscheinlich als Nächstes ansteuern wird. Basierend auf diesen Regeln kann der Browser eine Zielseite vorab im Hintergrund laden (prerender), noch bevor der Nutzer überhaupt auf den Link klickt.

Einfluss auf den LCP

Wenn der Nutzer auf einen Link zu einer per Prerendering geladenen Seite klickt, erfolgt der Wechsel praktisch verzögerungsfrei. Die Seite wurde bereits im Hintergrund vollständig geladen und gerendert. Für diese Navigation sind TTFB, Resource Load Delay, Resource Load Duration und Element Render Delay aus Nutzersicht effektiv auf nahezu null reduziert.

Beispiel-Use-Case

Auf der Kategorieseite eines E-Commerce-Shops könnten Speculation Rules genutzt werden, um die Produktdetailseiten der ersten paar Artikel in der Liste per Prerendering vorzuladen. Klickt ein Nutzer auf eines dieser Produkte, erscheint die Seite sofort.

Zusammenfassung von Fallstudien: Aus der Theorie in die Praxis

Diese Optimierungen haben einen messbaren Einfluss in der Praxis.

• Fall 1: Die transformative Kraft von Preloading: Ein von DebugBear durchgeführtes Experiment auf einer Seite mit hoher Ladeverzögerung liefert ein eindrucksvolles Beispiel. Das LCP-Bild war in einer Request-Kette versteckt, sodass die Resource Load Delay stolze 75 % der gesamten LCP-Zeit ausmachte. Durch die Implementierung eines einzigen <link rel="preload">-Hints zur frühen Erkennung des Bildes sank die Resource Load Delay auf gerade einmal 2 % der LCP-Zeit. Dies zeigt, wie eine einfache architektonische Anpassung einen massiven Performance-Flaschenhals beheben kann.
• Fall 2: Das loading="lazy"-Anti-Pattern in der Praxis: Ein Entwickler auf Stack Overflow berichtete von einem Desktop-LCP mit einer verblüffenden Verzögerung von 1.430 ms beim Laden, trotz eines schnellen Netzwerks. Die Ursache wurde auf ein Bildoptimierungs-Plugin zurückgeführt, welches fälschlicherweise lazy loading auf das LCP-Bild anwendete, indem es das src-Attribut durch ein transparentes Platzhalter-SVG ersetzte. Die endgültige Lösung bestand darin, dieses Verhalten für das LCP-Element zu deaktivieren, damit es frühzeitig und eager geladen werden kann. Dies verdeutlicht, wie Drittanbieter-Tools ungewollt erhebliche Ladeverzögerungen verursachen können.
• Fall 3: Der Performance-Schub durch fetchpriority: Die Google Flights-Fallstudie liefert einen klaren Beweis für die Wirkung einer expliziten Priorisierung. Allein durch das Hinzufügen von fetchpriority="high" zum LCP-Hintergrundbild der Seite verbesserte sich der LCP-Wert um 700 ms (von 2,6 Sekunden auf 1,9 Sekunden). Dies zeigt, dass es selbst bei einer auffindbaren Ressource ein entscheidender Schritt ist, dem Browser deren hohe Wichtigkeit zu signalisieren, um den Kampf um die Netzwerkbandbreite zu gewinnen.

Netzwerkanalyse in den Chrome DevTools: Nutze das Tastenkürzel Strg + Shift + I, um die Developer Tools von Chrome zu öffnen, wähle dann den Reiter „Network“ und lade die Seite neu. Betrachte die Ladereihenfolge. Deine LCP-Ressource sollte eines der ersten Elemente sein, die für den Download eingereiht werden. Wenn sie hinter anderen Elementen hinterherhinkt, liegt ein Problem mit der Resource Load Delay vor. Unten siehst du das Beispiel einer Website, bei der die Resource Load Delay nicht optimiert wurde.

Nutze Real User Monitoring (RUM)-Daten: RUM-Tools protokollieren oft LCP-Attributionsdaten. Mit RUM kannst du die Aufteilung der LCP-Teilphasen visualisieren (im Zeitverlauf oder nach Seiten), was dir ein klares Bild der Load Delay für LCP-Elemente auf deiner gesamten Website oder pro Seite vermittelt. Das folgende Beispiel zeigt eine globale LCP-Aufteilung zusammen mit der entsprechenden Load Delay.

So verbesserst du die Load Delay

Eine Resource Load Delay entsteht, wenn die Download-Reihenfolge und das Timing der Ressourcen nicht optimal sind. Im Wesentlichen gibt es zwei direkte Wege, dies zu beheben: die LCP-Ressource priorisieren oder Nicht-LCP-Ressourcen deprioritisieren. Lass uns einige typische Patterns 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. 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 deine LCP-Ressourcen für den Preload-Scanner auffindbar sind, kann einen großen Unterschied bei der Reduzierung der Load Delay ausmachen.

1. Optimiere die HTML-Struktur

Der Browser (oder der Preload-Scanner) verarbeitet dein HTML von oben nach unten und reiht die Ressourcen in der Reihenfolge ihres Erscheinens ein. Das bedeutet: Je weiter oben die LCP-Ressource im HTML steht, desto früher wird sie eingereiht. Um dies zu optimieren, entferne oder verschiebe nicht benötigte Ressourcen vom Anfang des HTML-Dokuments:

• Unwichtige oder versteckte Bilder per lazy loading laden: Manchmal befinden sich Bilder (beispielsweise Flaggen für sprachspezifische Versionen deiner Website oder Bilder im Menü) ganz oben im HTML deiner Website. Diese Bilder sind bei Weitem nicht so wichtig wie das LCP-Element. Wenn du diese Bilder per lazy loading lädst, werden sie vom Preload-Scanner übersprungen und erst etwas später im Ladevorgang eingereiht.
• Unwichtige Skripte an das Seitenende verschieben: Verschiebe Skripte, die für das initiale Laden absolut unwichtig sind, an das Ende der Seite, um zu verhindern, 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 über den wesentlich langsameren DOM-Parser eingereiht werden. Um diese Verzögerung zu vermeiden, verwende stattdessen ein reguläres <img>-Tag in Kombination 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 Attribut fetchpriority="high" zu deinem LCP-Element hinzu, um dem Browser zu signalisieren, dass er diese Ressource von Anfang an priorisieren soll. Normalerweise laden Bilder mit einer standardmäßigen niedrigen oder mittleren Priorität. Während der Layout-Phase stuft der Browser sichtbare Elemente auf eine hohe Priorität hoch. Durch das Setzen von fetchpriority="high" beginnt der Download sofort mit hoher Priorität, was für einen schnelleren LCP sorgt.

Fetch Priority ist in der Regel weniger invasiv (und weniger effektiv) als Preloading, da es die relative Priorität eines Elements festlegt (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. Implementiere Preloading

Preloading ändert die Reihenfolge, in der der Preload-Scanner Dateien einreiht. Platziere das Tag <link rel="preload"> 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 vorab zu laden, die erst später im HTML referenziert (und daher später eingereiht) werden, oder sogar Ressourcen vorab zu laden, die noch gar nicht im HTML referenziert sind (wie bei manchen Slidern). Für eine maximale Wirksamkeit wird empfohlen, Preloads im Head der Seite hinter den Stylesheets und vor den Skripten 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 nicht mit der Rendering-Phase beginnen. Eine übermäßige CSS-Größe und eine zu große Anzahl von Stylesheets konkurrieren jedoch mit der LCP-Ressource um die anfängliche Bandbreite.

6. Implementiere effizientes Lazy Loading

Das loading-Attribut kann ein zweischneidiges Schwert sein. Verwende loading="eager" (oder lasse 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.

• LCP-Element eager laden: Wenn das LCP-Element per lazy loading geladen wird, reiht der Preload-Scanner es nicht ein und es lädt viel später, was sich negativ auf die Performance auswirkt.
• Bilder im viewport per lazy loading laden: Verwende für Bilder, die sich im sichtbaren viewport befinden, aber keine LCP-Ressourcen sind, loading="lazy", um sie etwas später für den Download einzureihen. Dies verringert die Bandbreitenkonkurrenz mit der LCP-Ressource.
• Lazy loading für Offscreen-Bilder vermeiden: Bilder, die sich nicht im sichtbaren viewport befinden, lösen überhaupt keinen Download aus, was die Bandbreitenkonkurrenz komplett eliminiert.

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 bei nachfolgenden Seitenaufrufen und wiederkehrenden Besuchern. So hilft Browser-Caching bei der Resource Load Delay:

• Konkurrierende Ressourcen cachen: Während das Cachen der LCP-Ressource selbst eine hervorragende Strategie ist, verbessert Browser-Caching die Resource Load Delay des LCP, indem es Netzwerkressourcen speichert, die mit der LCP-Ressource konkurrieren oder diese verzögern könnten – wie Skripte, Stylesheets und Bilder.
• Serverlast reduzieren: Caching verringert die Anzahl der an deinen Server gesendeten Anfragen, was die Performance anderer Ressourcen verbessern kann, indem Bandbreite freigegeben und Server-CPU-Zyklen eingespart werden.

8. Nutze Speculation Rules

Speculation Rules ermöglichen es Browsern, Webseiten basierend auf der vorhergesagten Navigation des Nutzers vorab abzurufen (prefetch) oder vorab zu rendern (prerender). Prefetching eliminiert effektiv die TTFB-Teilphase des LCP und hat keinen Einfluss auf die Resource Load Delay. Prerendering rendert die nächste Seite in einem ausgeblendeten Tab und lädt alle Ressourcen der Seite herunter. Dies eliminiert sämtliche Ladeverzögerungen für das LCP-Element, wie in diesem Beispiel einer LCP-Aufteilung einer per Prerendering geladenen Seite gezeigt.

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 Verzögerung bei der Erkennung minimiert hast, fahre mit diesen Leitfäden fort:

• LCP-Probleme identifizieren &amp;amp; beheben: Die vollständige Diagnose-Methodik, um alle LCP-Probleme zu finden und zu beheben.
• Das LCP-Bild optimieren: Auswahl des Bildformats, responsive Bilder, Preloading und häufige Bild-Fehler.
• Resource Load Duration: Nachdem der Browser die Ressource entdeckt hat, verkürze deren Downloadzeit durch Komprimierung, moderne Formate und CDN-Optimierung.
• Element Render Delay: Stelle nach dem Download der Ressource sicher, dass der Browser sie sofort darstellen kann, indem der main thread freigehalten wird.