LCP Resource Load Delay optimieren

LCP Resource Load Delay optimieren

Largest Contentful Paint (LCP) besteht aus vier Phasen: TTFB, Resource Load Delay, Resource Load Duration und Element Render Delay. Entwicklungsbemühungen konzentrieren sich oft auf die Reduzierung der Load Duration durch Dateikomprimierung, aber dies übersieht die Resource Load Delay, die häufig eine größere Quelle für Latenz ist. Diese Verzögerung vor Beginn des Downloads kann Hunderte von Millisekunden zu Ihrem LCP beitragen und dazu führen, dass er den 'Good'-Schwellenwert von 2,5 Sekunden überschreitet. 

Ein schneller Tipp: Wenn Ihr LCP ein Bild ist, wird es fast immer schlechter abschneiden als Text. Sie müssen Ihre LCP-Elementtypen in Ihren RUM-Daten verfolgen, sonst fliegen Sie blind.

Präzise Definition: Das kritische Warten vor dem Download

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 Downloadzeit; es ist die Entdeckungslatenz, die auftritt, bevor der Fetch beginnt. Ein hoher Wert hier deutet auf ein architektonisches Problem hin, bei dem der Browser die Ressourcen-URL im anfänglichen HTML-Payload nicht finden kann.  Diese Resource Load Delay kann als die Zeit angesehen werden, die der Browser damit verbringt, zu identifizieren, dass die LCP-Ressource benötigt wird, und zu entscheiden, sie abzurufen.

Für LCP-Elemente, die textbasiert sind und mit einer Systemschriftart gerendert werden, ist diese Resource Load Delay in der Regel null, da keine externe Ressource abgerufen werden muss. Höhere Resource Load Delay-Werte sind spezifisch für LCP-Elemente, 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 Hauptfaktor, der die Latenz bestimmt. Browser verwenden zwei Mechanismen: einen schnellen Pfad und einen langsamen Pfad.

• Der Preload Scanner (Der schnelle Pfad): Der Preload Scanner (Schneller Pfad): Dies ist ein schneller sekundärer Parser, der das rohe HTML nach Ressourcen-URLs scannt, wie die in <img> oder <link> Tags. Er stellt sie sofort zum Download in die Warteschlange, 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 CSS Object Model (CSSOM) konstruiert. Ressourcen, die im anfänglichen HTML nicht gefunden werden, wie ein CSS background-image oder ein von JavaScript injiziertes Element, werden nur von diesem Parser entdeckt. Dies ist der langsame Pfad, da er von anderen Dateien abhängt, die zuerst heruntergeladen und ausgeführt werden müssen, was eine Kette von Abhängigkeiten erzeugt, die hohe Latenz einführt.

Die gesamte Strategie zur Optimierung der Resource Load Delay basiert auf einem Prinzip: Stellen Sie sicher, dass die LCP-Ressourcen-URL für den Preload Scanner auffindbar ist. Jedes Muster, das die URL vor dem anfänglichen HTML-Dokument verbirgt, zwingt den Browser, den langsamen Entdeckungspfad zu verwenden. Diese Wartezeit übersetzt sich direkt in Resource Load Delay. Jede effektive Optimierung dreht sich um die Architektur Ihres HTML, um die LCP-Ressource auf den schnellen Pfad zu bringen

Warum Load Delay wichtig ist

Ein häufiges Missverständnis ist, dass ein langsames LCP ein "Dateigrößen"-Problem ist. Dies führt dazu, dass Teams sich nur auf Bildkomprimierung konzentrieren, um die Resource Load Duration zu reduzieren. Während die Asset-Optimierung ein Faktor ist, zeigt die Analyse von realen Felddaten, dass bei vielen Websites mit schlechter LCP die Resource Load Delay der primäre Engpass ist, nicht die Resource Load Duration.

Felddaten zeigen, dass die mittlere Website mit einem schlechten LCP-Score eine 1,3 Sekunden Resource Load Delay hat. Das ist über die Hälfte des gesamten Budgets von 2,5 Sekunden für einen 'Good' LCP-Score, alles verbraucht, bevor der LCP-Ressourcendownload überhaupt beginnt. Die Daten zeigen, dass diese Websites fast viermal so lange auf den Start des Downloads warten wie auf den Download selbst.

Diese Daten legen eine häufige Fehlleitung von Entwicklungsaufwand offen. Teams können Wochen damit verbringen, Kilobyte von Bildern zu entfernen, um die Load Duration um einige Millisekunden zu verkürzen, während ein architektonisches Problem, das eine Load Delay von 1,5 Sekunden verursacht, ungelöst bleibt. LCP ist ein sequenzieller Prozess; eine Verzögerung in einer frühen Phase kann nicht durch Optimierung einer späteren Phase wiederhergestellt werden. Wenn ein Fetch um mehr als eine Sekunde verzögert wird, ist ein Unterschied von 100ms in der Downloadzeit irrelevant für den endgültigen LCP-Score. Die Optimierungen mit der höchsten Auswirkung betreffen architektonische Änderungen, wie die Verbesserung der Auffindbarkeit von Ressourcen, nicht nur Asset-Komprimierung. Der Fokus muss sich von der Verkleinerung von Assets darauf verlagern, Diese Daten legen eine häufige Fehlleitung von Entwicklungsaufwand offen. Teams können Wochen damit verbringen, Kilobyte von Bildern zu entfernen, um die Load Duration um einige Millisekunden zu verkürzen, während ein architektonisches Problem, das eine Load Delay von 1,5 Sekunden verursacht, ungelöst bleibt. LCP ist ein sequenzieller Prozess; eine Verzögerung in einer frühen Phase kann nicht durch Optimierung einer späteren Phase wiederhergestellt werden. Wenn ein Fetch um mehr als eine Sekunde verzögert wird, ist ein Unterschied von 100ms in der Downloadzeit irrelevant für den endgültigen LCP-Score. Die Optimierungen mit der höchsten Auswirkung betreffen architektonische Änderungen, wie die Verbesserung der Auffindbarkeit von Ressourcen, nicht nur Asset-Komprimierung. Der Fokus muss sich von der Verkleinerung von Assets darauf verlagern, sicherzustellen, dass sie schneller entdeckt werden..

Wie man Resource Load Delay erkennt

Um Resource Load Delay zu beheben, müssen Sie es zuerst genau messen. Der professionelle Workflow besteht darin, das Problem zuerst mit echten Benutzerdaten (RUM) zu definieren und erst dann zur tiefgehenden Analyse zu Chrome DevTools überzugehen.

Schritt 1: Analysieren Sie Felddaten (RUM)

Felddaten, oder Real User Monitoring (RUM), werden aus tatsächlichen Benutzersitzungen 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 umfassendes RUM-Tool bietet auch eine Aufschlüsselung der LCP-Teilbereiche und zeigt Ihnen die mittlere Resource Load Delay über Ihre Benutzer hinweg. Diese Daten validieren, dass ein LCP-Problem existiert, zeigen, welche URLs betroffen sind, und enthüllen die gemeinsamen LCP-Elemente, die Ihre Benutzer tatsächlich sehen. Sie müssen hier beginnen, um zu bestätigen, dass Sie ein echtes Problem lösen.

Schritt 2: Diagnose mit DevTools

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

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

Das Performance-Panel in Chrome DevTools ist ein unverzichtbares Werkzeug zur Zerlegung von 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 die Tastenkombination Ctrl+Shift+I (Windows/Linux) oder Cmd+Option+I (Mac) verwenden.   
• Navigieren Sie zum Tab Performance.
• Stellen Sie sicher, dass das Kontrollkästchen Web Vitals in den Aufnahmeeinstellungen aktiviert ist. Dies überlagert Core Web Vitals-Informationen auf der Performance-Zeitleiste.   
• Um realistische Benutzerbedingungen zu simulieren, wenden Sie CPU- und Netzwerkdrosselung an. Ein "4x slowdown" für CPU und ein "Fast 3G" oder "Slow 4G" Netzwerkprofil sind häufige Ausgangspunkte für mobile Tests.   

2. Aufnahme eines Performance-Profils:

• Klicken Sie auf die Schaltfläche "Record and reload page" (ein kreisförmiges Pfeilsymbol) im Performance-Panel. Dies startet eine Aufnahme, lädt die Seite neu und stoppt die Aufnahme, sobald die Seite vollständig geladen ist.   

3. Analyse und Interpretation:

• Timings Track: Suchen Sie in der Hauptzeitleistenansicht nach dem Timings-Track. Sie sehen eine Markierung mit der Bezeichnung LCP. Wenn Sie über diese Markierung fahren, wird das entsprechende LCP-Element im Haupt-Viewport-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 unten im Panel finden Sie eine detaillierte Aufschlüsselung des LCP-Timings. Diese Aufschlüsselung zeigt explizit die Dauer jedes der vier Unterteile, einschließlich Load delay, gemessen in Millisekunden. Dieser Wert ist die direkteste und präziseste Messung der Resource Load Delay für diesen spezifischen Seitenladevorgang.   
• Main Thread Analysis: Schauen Sie sich während der Untersuchung der Zeitleiste den Main-Track nach langen Aufgaben an (Aktivitätsblöcke, die mit einem roten Dreieck gekennzeichnet sind). Wenn diese langen Aufgaben auftreten, nachdem die LCP-Ressource geladen wurde, aber vor der LCP-Markierung, tragen sie wahrscheinlich zur Element Render Delay bei, einem verwandten, aber unterschiedlichen Problem.   

Häufige Ursachen und Lösungen mit hoher Auswirkung

Eine hohe Resource Load Delay wird durch eines von zwei Dingen verursacht: Die LCP-Ressource wird spät entdeckt oder erhält eine niedrige Fetch-Prioritä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-Dateilink gefunden, die CSS-Datei heruntergeladen, das CSSOM erstellt und dann den Stil angewendet hat. Diese Abhängigkeitskette verursacht direkt eine hohe Resource Load Delay.

Die Lösung: Die korrekte Implementierung besteht darin, background-image für jedes kritische LCP-Element zu vermeiden. 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-Muster (Tun Sie dies nicht):

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

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

Best Practice (Tun Sie dies stattdessen):

    <!-- HTML -->
    <div class="hero-container">
      <img
        src="hero-image.jpg"
        alt="Ein beschreibender Alt-Text für das Hero-Bild"
        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; /* Äquivalent zu top: 0; right: 0; bottom: 0; left: 0; */
      width: 100%;
      height: 100%;
      object-fit: cover; /* Diese Eigenschaft ahmt background-size: cover nach */
      z-index: -1; /* Platziert das Bild hinter anderen Inhalten */
    }
    

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

Ursache: Client-Side Rendering und JavaScript-Injektion

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

Die Lösung: Die effektivste Lösung ist es, das anfängliche Rendern 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 vollständiges Dokument, das das <img>-Tag und sein src-Attribut enthält, wodurch die LCP-Ressource sofort für den Preload Scanner auffindbar ist. Dies ist die erforderliche Architektur für jede leistungskritische Seite.
• Framework-Spezifische Optimierungen: Moderne Frameworks bieten auch integrierte Optimierungen. Zum Beispiel hat die Next.js <Image>-Komponente eine priority-Eigenschaft. Wenn Sie diese auf true setzen, weisen Sie das Framework an, automatisch die richtigen <link rel="preload">- und fetchpriority="high"-Attribute hinzuzufügen, um sicherzustellen, dass das Bild mit der richtigen Priorität entdeckt und abgerufen wird.

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

Das Problem: Dies ist ein häufiger Fehler mit hoher Auswirkung. Das loading="lazy"-Attribut ist eine direkte Anweisung an den Browser, das Abrufen eines Bildes zu verzögern, bis es nahe am Ansichtsfenster ist. Während dies die richtige Optimierung für Bilder "below the fold" ist, ist die Anwendung auf ein "above the fold" LCP-Element kontraproduktiv. Der Preload Scanner des Browsers ist so konzipiert, dass er Bilder mit loading="lazy" ignoriert, was eine späte Entdeckung und eine hohe Resource Load Delay garantiert.

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

• Entfernen Sie loading="lazy" vom LCP-Bild: Jedes Bild, das wahrscheinlich das LCP-Element ist, darf nicht das loading="lazy"-Attribut haben. Das Standardverhalten des Browsers ist loading="eager", was die richtige Einstellung für kritische Inhalte "above the fold" ist. Das vollständige Weglassen des loading-Attributs hat denselben Effekt.
• Prüfen und Konfigurieren von Drittanbieter-Tools: Sie müssen auch Tools von Drittanbietern prüfen. Viele CMS-Plattformen wie WordPress und verschiedene Bildoptimierungs-Plugins wenden automatisch Lazy Loading auf alle Bilder an. Es ist wichtig, 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 nicht kritische, 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 in die Warteschlange gestellt. Dies verbraucht anfängliche Netzwerkbandbreite und kann den Download der LCP-Ressource verzögern. Ein großes HTML-Dokument kann ebenfalls ein Problem darstellen; wenn sich das LCP-Element nicht im ersten Datenblock befindet, den der Browser empfängt (ca. 14 KB), verzögert sich seine Entdeckung um mindestens einen Netzwerk-Round-Trip.

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

• Ordnen Sie das HTML neu an: Stellen Sie 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.
• De-priorisieren Sie nicht kritische Bilder: 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, wodurch die Download-Warteschlange für das LCP-Element erhalten bleibt.
• Verschieben Sie nicht essentielle Skripte: Skripte für Analysen, Anzeigen oder Social-Media-Widgets sind selten kritisch für das anfängliche Rendern. 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 auffindbar ist, können Sie Resource Hints verwenden, um dem Browser explizitere Anweisungen zum Abrufen zu geben. Diese Hinweise bieten eine feinkörnige Kontrolle über Entdeckung und Priorisierung.

Erzwingen der frühen Entdeckung mit <link rel="preload">

<link rel="preload"> ist kein Hinweis; es ist eine Anweisung. Es zwingt den Browser, eine Ressource mit hoher Priorität herunterzuladen, auch wenn sie vom Hauptparser noch nicht auffindbar ist. Die Platzierung im <head> Ihres HTML ist der direkteste Weg, um Probleme mit später Entdeckung für Ressourcen wie Schriftarten, CSS-Hintergrundbilder oder LCP-Bilder, die tief im DOM liegen, zu beheben.

Mechanismus

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

Responsives Preloading

Ein kritisches Implementierungsdetail ist beim Preloading von responsiven Bildern erforderlich. Um sicherzustellen, dass der Browser das Bild in der richtigen Größe für das Ansichtsfenster des Benutzers vorlädt und einen verschwenderischen doppelten Download vermeidet, muss das <link rel="preload">-Tag imagesrcset- und imagesizes-Attribute enthalten, die die Attribute auf dem entsprechenden <img>-Tag perfekt widerspiegeln.[4]

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="Ein beschreibender Alt-Text"
     fetchpriority="high"
     width="1200" height="675">
    

Mögliche Fallstricke

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-blockierendes CSS blockiert wird, wenn das vorgeladene Bild ankommt, muss das Bild immer noch warten, um gerendert zu werden, was den Engpass von Load Delay zu Element Render Delay verschieben kann.[5, 6]

Feinabstimmung mit fetchpriority="high": Den Kampf um Bandbreite gewinnen

Das fetchpriority-Attribut ist ein Hinweis, 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.[7]

preload vs. fetchpriority

Diese beiden Hinweise dienen unterschiedlichen, aber komplementären Zwecken. preload beeinflusst, wann eine Ressource entdeckt und zur Warteschlange hinzugefügt wird. fetchpriority beeinflusst ihre Prioritätsstufe, sobald sie in der Warteschlange ist.

Best Practice für LCP

Für das LCP-Bild ist die optimale Strategie, sie zusammen zu verwenden. Stellen Sie zuerst eine frühe Entdeckung sicher, entweder indem Sie das <img>-Tag früh im HTML platzieren oder indem Sie preload verwenden. Fügen Sie zweitens fetchpriority="high" direkt zum <img>-Tag (und dem preload-Link, falls verwendet) hinzu. Diese Kombination stellt sicher, dass die Ressource nicht nur früh entdeckt wird, sondern auch die höchstmögliche Priorität erhält, um im Wettbewerb um Netzwerkbandbreite gegen andere Ressourcen wie Stylesheets oder Schriftarten zu bestehen.[3, 1, 7]

Beispiel:

<img src="lcp-image.jpg" fetchpriority="high" alt="Ein kritisches Hero-Bild">

Nachgewiesene Wirkung

In einer Fallstudie mit Google Flights trug das Hinzufügen von fetchpriority="high" zum LCP-Hintergrundbild der Seite maßgeblich dazu bei, die LCP-Zeit von 2,6 Sekunden auf 1,9 Sekunden zu verbessern, eine Verbesserung um 700ms.[8]

Optimierung von Drittanbieter-Verbindungen: preconnect und dns-prefetch

Das Problem

Wenn Ihre LCP-Ressource auf einer Drittanbieter-Domain gehostet wird, wie z. B. einem Bild-CDN oder einem Schriftartenanbieter 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-Aushandlung, 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.[9, 2, 10, 11]

Die Lösungen

• preconnect: Dieser Hinweis weist den Browser an, den vollständigen Verbindungsaufbau (DNS, TCP und TLS) für eine angegebene Drittanbieter-Herkunft im Hintergrund im Voraus durchzuführen. Wenn die Ressource tatsächlich angefordert wird, ist die Verbindung bereits warm, was die Aufbaulatenz eliminiert. Dies ist sehr effektiv und wird für die ein oder zwei kritischsten Drittanbieter-Domains empfohlen, die LCP-Ressourcen bereitstellen.[2]
• dns-prefetch: Dies ist ein leichterer Hinweis, der nur den DNS-Lookup für eine Domain durchführt. Er spart weniger Zeit als preconnect, hat jedoch eine breitere Browserunterstützung und ist als Fallback oder für weniger kritische Drittanbieter-Domains nützlich.[2, 12]

Best Practice für die Implementierung

Um maximale Kompatibilität zu gewährleisten, geben Sie beide Hinweise an. Der Browser verwendet preconnect, wenn unterstützt, und fällt auf dns-prefetch zurück, wenn nicht. Das crossorigin-Attribut ist für Ressourcen unerlässlich, die über CORS abgerufen werden, wie z. B. Schriftarten.

<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 von Resource Hints für LCP-Optimierung

Um Missbrauch zu verhindern und die unterschiedlichen Rollen dieser leistungsstarken Hinweise zu klären, bietet die folgende Tabelle eine vergleichende Zusammenfassung.

Ganzheitliche und zukunftsorientierte Strategien

Jenseits gezielter Hinweise können breitere architektonische Entscheidungen und neue Webplattform-Funktionen ganzheitliche und leistungsstarke Lösungen für Resource Load Delay bieten.

Die Rolle eines modernen CDN

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

• Reduzierung des Verbindungsoverheads: Durch die Verteilung von Assets über ein globales Servernetzwerk platziert ein CDN Inhalte geografisch näher am Benutzer. Dies reduziert inhärent die Round-Trip-Time (RTT), die für den DNS-Lookup, den TCP-Handshake und die TLS-Aushandlung erforderlich ist, die alle Komponenten der Verbindungsaufbauzeit sind.[13, 14, 15] Für ein auf einem CDN gehostetes LCP-Bild reduziert dies direkt dessen Ladeverzögerung.
• Bild-CDNs: Spezialisierte Bild-CDNs bieten einen doppelten Vorteil. Sie bieten den Nähe-Vorteil eines Standard-CDNs und automatisieren gleichzeitig viele komplexe Optimierungen, die die Resource Load Duration reduzieren, wie z. B. das spontane Skalieren, Komprimieren und Konvertieren von Bildern in moderne Formate wie AVIF und WebP.[9, 1]
• Erweiterte Protokolle: Viele moderne CDNs nutzen überlegene Netzwerkprotokolle wie HTTP/3, das QUIC anstelle von TCP verwendet. HTTP/3 reduziert die Verbindungsaufbauzeit und mindert Head-of-Line-Blocking, was insgesamt zu einer schnelleren und effizienteren Ressourcenbereitstellung führt.[16]

Verzögerung vollständig eliminieren mit Speculation Rules

Die Speculation Rules API ist eine hochmoderne Webplattform-Funktion, die das Potenzial bietet, die LCP-Verzögerung für nachfolgende Navigationen vollständig zu eliminieren.

Mechanismus

Diese API ermöglicht es Entwicklern, den Browser deklarativ darüber zu informieren, zu welchen URLs ein Benutzer wahrscheinlich als nächstes navigieren wird. Basierend auf diesen Regeln kann der Browser wählen, eine Zielseite in einem versteckten Hintergrund-Tab zu prerendern, bevor der Benutzer überhaupt auf den Link klickt.[3, 1, 16]

Auswirkung auf LCP

Wenn der Benutzer auf einen Link zu einer prerenderten 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 Sicht des Benutzers effektiv auf fast null reduziert.[3, 1, 16]

Beispielhafter Anwendungsfall

Auf einer E-Commerce-Kategorieseite könnten Speculation Rules verwendet werden, um die Produktdetailseiten für die ersten paar Artikel in der Liste zu prerendern. Wenn ein Benutzer auf eines dieser Produkte klickt, erscheint die Seite sofort und bietet ein nahtloses und außergewöhnlich schnelles Erlebnis.

Synthese der Fallstudien: Von der Theorie zur Praxis

Die Wirksamkeit dieser Optimierungsstrategien ist nicht nur theoretisch; sie wird durch Daten aus realen Tests und Szenarien belegt.

• Fall 1: Die transformative Kraft von Preloading: Ein von DebugBear durchgeführtes Experiment auf einer Seite mit hoher Ladeverzögerung liefert ein dramatisches Beispiel. Das LCP-Bild war in einer Anfragekette versteckt, wodurch die Resource Load Delay erstaunliche 75% der gesamten LCP-Zeit ausmachte. Durch die Implementierung eines einzigen <link rel="preload">-Hinweises, um das Bild frühzeitig auffindbar zu machen, wurde die Resource Load Delay auf nur 2% der LCP-Zeit reduziert.[17] Dies zeigt, wie eine einfache architektonische Korrektur einen massiven Leistungsengpass beheben kann.
• Fall 2: Das reale loading="lazy" Anti-Muster: Ein Entwickler auf Stack Overflow berichtete von einem Desktop-LCP mit einer verblüffenden Ladeverzögerung von 1.430 ms trotz eines schnellen Netzwerks. Die Ursache wurde auf ein Bildoptimierungs-Plugin zurückgeführt, das fälschlicherweise Lazy Loading auf das LCP-Bild anwendete, indem es dessen src-Attribut durch ein transparentes Platzhalter-SVG ersetzte. Die definitive Lösung bestand darin, dieses Verhalten für das LCP-Element zu deaktivieren, damit es begierig entdeckt und geladen werden konnte.[18] Dies veranschaulicht, wie Drittanbieter-Tools versehentlich schwere Ladeverzögerungen verursachen können.
• Fall 3: Der fetchpriority Leistungsschub: Die Fallstudie von Google Flights liefert klare Beweise für die Auswirkungen expliziter Priorisierung. Durch einfaches Hinzufügen von fetchpriority="high" zum LCP-Hintergrundbild der Seite verbesserte sich der LCP-Score um 700 ms und sank von 2,6 Sekunden auf 1,9 Sekunden.[8] Dies zeigt, dass selbst wenn eine Ressource auffindbar ist, das Signalisieren ihrer hohen Wichtigkeit an den Browser ein entscheidender Schritt ist, um den Wettlauf um Netzwerkbandbreite zu gewinnen.

Netzwerk-Inspektion in Chrome DevTools: Verwenden Sie die Tastenkombination Ctrl + Shift + I, um die Entwicklertools von Chrome zu öffnen, wählen Sie dann den Tab "Network" und laden Sie die Seite neu. Schauen Sie sich die Ladesequenz an. Ihre LCP-Ressource sollte eines der ersten Elemente sein, die zum Download in die Warteschlange gestellt werden. Wenn sie hinter anderen Elementen zurückbleibt, liegt ein Resource Load Delay-Problem vor. Unten ist ein Beispiel für eine Seite, auf der die Resource Load Delay nicht optimiert wurde.

Nutzung von Real User Monitoring (RUM) Daten: Real User Monitoring Tools protokollieren oft LCP-Attributionsdaten. Mit RUM können Sie die Aufschlüsselung der LCP-Teilbereiche (im Zeitverlauf oder pro Seite) visualisieren, was Ihnen ein klares Bild der Ladeverzögerung für LCP-Elemente auf Ihrer gesamten Website oder pro Seite gibt. Das folgende Beispiel zeigt eine globale LCP-Aufschlüsselung zusammen mit der entsprechenden Ladeverzögerung.

Wie man 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 einfache Möglichkeiten, dies zu beheben: Priorisieren Sie die LCP-Ressource oder de-priorisieren Sie Nicht-LCP-Ressourcen. Lassen Sie uns einige häufige Muster untersuchen:

LCP-Tipp: Verstehen Sie den Preload Scanner: Moderne Browser verwenden einen Mechanismus namens Preload Scanner, der das HTML schnell scannt und Ressourcen zum Download in die Warteschlange stellt. Wenn eine Ressource nicht vom Preload Scanner in die Warteschlange gestellt werden kann, muss sie auf den langsameren DOM-Parser warten, was zu Verzögerungen führt. Sicherzustellen, dass Ihre LCP-Ressourcen für den Preload Scanner auffindbar sind, kann einen großen Unterschied bei der Reduzierung der Ladeverzögerung machen.

1. Optimieren Sie die HTML-Struktur

Der Browser (oder der Preload Scanner) verarbeitet Ihr HTML von oben nach unten und stellt Ressourcen in der Reihenfolge ihres Erscheinens in die Warteschlange. Das bedeutet, je höher die LCP-Ressource im HTML erscheint, desto eher wird sie eingereiht. Um dies zu optimieren, entfernen oder verschieben Sie unnötige Ressourcen von oben im HTML:

• Lazy-Load unwichtige oder versteckte Bilder: 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 Ladevorgangs eingereiht.
  
• Verschieben Sie unwichtige Skripte an das Ende der Seite: Verschieben Sie Skripte, die für das anfängliche 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. Vermeiden Sie 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, verwenden Sie stattdessen ein normales <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. Verwenden Sie Fetch Priority

Fügen Sie das fetchpriority="high"-Attribut zu Ihrem LCP-Element hinzu, um dem Browser einen Hinweis zu geben, dass er diese Ressource von Anfang an priorisieren soll. Normalerweise laden Bilder mit einer standardmäßig 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 ein schnelleres LCP gewährleistet. 

Fetchpriority ist normalerweise weniger aufdringlich (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. Implementieren Sie Preloading

Preloading ändert die Reihenfolge, in der der Preload Scanner Dateien in die Warteschlange stellt. 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. Optimieren Sie Stile

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 Renderphase beginnen. Eine übermäßige CSS-Größe und eine übermäßige Anzahl von Stylesheets konkurrieren jedoch mit der LCP-Ressource um frühe Bandbreite.

6. Implementieren Sie effizientes Lazy-Loading

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

• Eager Load das LCP-Element: Wenn das LCP-Element lazy-geladen wird, wird es nicht vom Preload Scanner eingereiht und lädt viel später, was sich negativ auf die Leistung auswirkt.
• Lazy-Load Viewport-Bilder: Für Bilder, die sich im sichtbaren Ansichtsfenster befinden, aber keine LCP-Ressourcen sind, verwenden Sie loading="lazy", um sie etwas später für den Download einzureihen. Dies reduziert die Bandbreitenkonkurrenz mit der LCP-Ressource.
• Vermeiden Sie Lazy Loading von Offscreen-Bildern: Bilder, die sich nicht im sichtbaren Ansichtsfenster befinden, lösen überhaupt keinen Download aus, wodurch die Bandbreitenkonkurrenz vollständig eliminiert wird.

7. Browser Caching

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

• Cache konkurrierende Ressourcen: 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 z. B. Skripte, Stylesheets und Bilder.
  
• Reduzieren Sie die Serverlast: Caching reduziert die Anzahl der Anfragen, die an Ihren Server gesendet werden, was die Leistung anderer Ressourcen verbessern kann, indem Bandbreite freigegeben und Server-CPU-Zyklen reduziert werden.
  

8. Verwenden Sie Speculation Rules

Speculation Rules ermöglichen es Browsern, Webseiten basierend auf der vorhergesagten Benutzernavigation vorab abzurufen oder vorab zu rendern. Prefetching eliminiert effektiv den Time to First Byte-Teilbereich 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 eliminierte alle Ladeverzögerungen für das LCP-Element, wie in dieser Beispiel-LCP-Aufschlüsselung einer prerenderten Seite gezeigt.

9. Vermeiden Sie Client-Side Rendering