Beheben & Identifizieren Sie Largest Contentful Paint (LCP) Probleme

Ein Leitfaden für Berater zur Diagnose und Behebung von LCP

Mein Name ist Arjen Karel und ich bin Berater für Seitengeschwindigkeit. Im Laufe der Jahre habe ich Hunderte von Websites geprüft, und eine der hartnäckigsten Herausforderungen ist der Largest Contentful Paint (LCP). In diesem Leitfaden teile ich die genaue Methodik, die ich verwende, um LCP-Probleme zu diagnostizieren und zu lösen. Sie werden Erwähnungen von CoreDash sehen, einem RUM-Tool, das ich entwickelt habe, um die genauen Daten zu erhalten, die für diesen Prozess benötigt werden. Die Prinzipien hier sind universell, aber ich glaube daran, echte Beispiele aus den Tools zu zeigen, die ich täglich baue und verwende.

Die Verbesserung des LCP ist ein systematischer Eliminierungsprozess. Indem Sie einer klaren Methodik folgen, können Sie die Engpässe in Ihrem Seitenladeprozess effektiv diagnostizieren und gezielte Lösungen anwenden, um die Leistung und Benutzererfahrung Ihrer Website zu verbessern.

Die diagnostische Methodik: Felddaten zuerst, Labordaten als zweites

Um effektiv zu optimieren, müssen Sie einen zweistufigen Diagnose-Workflow anwenden. Dies stellt sicher, dass Sie Probleme lösen, mit denen Ihre Benutzer tatsächlich konfrontiert sind, und nicht nur Ergebnissen in einer Laborumgebung nachjagen.

1. Felddaten (RUM & CrUX) zeigen Ihnen, WAS passiert. Felddaten werden von echten Benutzern gesammelt, die Ihre Website besuchen [1]. Sie sagen Ihnen, ob Sie ein LCP-Problem haben, welche Seiten betroffen sind und welche Benutzer (Mobil oder Desktop) es erleben. Sie müssen immer hier beginnen, um zu bestätigen, dass ein echtes Problem besteht.
2. Labordaten (Lighthouse, DevTools) helfen Ihnen zu diagnostizieren, WARUM es passiert. Labordaten werden in einer kontrollierten, simulierten Umgebung gesammelt [2]. Sobald Ihre Felddaten ein Problem auf einer bestimmten Seite bestätigt haben, können Sie Labortools verwenden, um das Problem konsistent zu replizieren und den Ladeprozess zu analysieren, um die Grundursache zu finden.

Der Beginn mit Felddaten stellt sicher, dass Ihre Optimierungsbemühungen auf Änderungen ausgerichtet sind, die eine messbare Auswirkung auf Ihre tatsächlichen Benutzer haben.

Schritt 1: Identifizieren Sie LCP-Probleme mit Felddaten

Ihre erste Aufgabe besteht darin, Daten von echten Benutzern zu verwenden, um zu bestätigen, welche Seiten, falls vorhanden, einen schlechten LCP haben.

Ein zugänglicher Ausgangspunkt: Google Search Console

Ein guter Ort, um zu beginnen, ist der Core Web Vitals-Bericht in der Google Search Console. Melden Sie sich an, navigieren Sie zum Bericht und überprüfen Sie die Mobil- und Desktop-Diagramme. Wenn Google URLs markiert mit "LCP-Problem: länger als 2,5s", haben Sie die Bestätigung aus dem Chrome User Experience (CrUX) Report, dass ein Prozentsatz Ihrer Benutzer eine schlechte Erfahrung hat.

Während die Search Console von unschätzbarem Wert für die Bestätigung eines Problems ist, aktualisiert sie sich langsam und gruppiert Daten nach URL-Mustern. Für unmittelbarere und detailliertere Einblicke ist ein dediziertes RUM-Tool erforderlich.

Ein tieferer Blick: Real User Monitoring (RUM)

Um die Wahrheit herauszufinden, können Sie LCP für jeden Benutzer bei jedem Seitenaufruf mithilfe einer Real User Monitoring (RUM)-Lösung verfolgen. Während Sie Ihre eigene erstellen können, indem Sie die web-vitals Bibliothek nutzen, um Daten an Ihr Analytics-Backend zu senden, kann dies ein erheblicher technischer Aufwand sein.

Alternativ sind dedizierte RUM-Tools für diesen Zweck konzipiert. Tools wie CoreDash sind so konzipiert, dass sie diese Daten sofort liefern. Die Einrichtung umfasst normalerweise das Hinzufügen eines kleinen JavaScript-Snippets zum Header Ihrer Website. Nach der Installation beginnt es, Leistungsdaten von jedem echten Besucher zu sammeln.

Ein gutes RUM-Tool hilft Ihnen, über URL-Gruppen hinauszusehen, um zu verstehen:

• Ihren genauen LCP-Score für jede spezifische URL.
• Eine Aufschlüsselung jedes LCP-Elements (z. B. ein Bild, eine Überschrift) und welche am häufigsten mit einem langsamen LCP in Verbindung gebracht werden.
• Das genaue Timing für jede der vier LCP-Phasen für jeden Seitenaufruf, wodurch der Engpass genau bestimmt wird.

Bei einem kürzlichen Audit für einen E-Commerce-Kunden sahen wir hohe LCP-Werte auf Produktseiten trotz eines vollständig optimierten Hero-Bildes. Unsere RUM-Daten enthüllten, dass die Verzögerung nicht das Bild selbst war, sondern ein clientseitiges A/B-Testskript, das den Produkttitel, der das LCP-Element war, dynamisch änderte. Dieses Skript blockierte das Rendern lange genug, um LCP in die Kategorie "schlecht" zu drängen. Das Pausieren des Tests löste das Problem sofort, was beweist, dass LCP-Optimierung erfordert, über das LCP- Element selbst hinauszuschauen.

In CoreDash können Sie beispielsweise zur LCP-Seite navigieren und eine Datentabelle anzeigen, die Ihre langsamsten LCP-Elemente zeigt. Durch Klicken auf ein bestimmtes Element (wie eine bestimmte CSS-Klasse für ein Hero- Bild) können Sie alle Metriken filtern, um die Leistungsdaten nur für Seiten anzuzeigen, auf denen dieses Element der LCP war.

Ob Sie eine benutzerdefinierte Lösung oder ein Tool wie CoreDash verwenden, das Ziel ist dasselbe: Verwenden Sie Felddaten, um Ihre langsamste Seite zu finden und das häufigste LCP-Element zu identifizieren. Sobald Sie dieses Ziel haben, sind Sie bereit zur Diagnose.

Schritt 2: Diagnostizieren Sie den Engpass mit Labortools

Jetzt, wo Sie wissen, welche Seite Sie reparieren müssen, ist es an der Zeit herauszufinden, warum sie langsam ist. Das ist wo ein Labortool wie PageSpeed Insights oder das Lighthouse-Panel in Chrome DevTools unverzichtbar wird [3].

Führen Sie einen Test für Ihre Ziel-URL durch. Scrollen Sie im Bericht nach unten zum Abschnitt "Diagnose" und finden Sie das Audit "Element mit dem Largest Contentful Paint". Dieses Wasserfalldiagramm schlüsselt Ihre LCP-Zeit in ihre vier Unterteile auf. Ihr RUM-Tool sollte eine ähnliche Aufschlüsselung basierend auf Ihren Felddaten anzeigen.

Ihr Ziel ist es, die längste Phase in dieser Aufschlüsselung zu finden. Das ist Ihr primärer Engpass, und das ist wo Sie Ihre Optimierungsbemühungen zuerst konzentrieren sollten.

Schritt 3: Den wahren Engpass verstehen

In den meisten realen Szenarien kommen die bedeutendsten und hartnäckigsten LCP-Probleme aus einer der anderen drei Phasen.

• Time to First Byte (TTFB): Dies ist das unüberspringbare Fundament. Eine langsame Server- antwort ist eine direkte Millisekunde-für-Millisekunde-Addition zu Ihrem LCP. Bevor Sie auch nur ein einziges Bild optimieren, müssen Sie sicherstellen, dass Ihr Server schnell antwortet.
• Resource Load Delay: Dies ist das "Entdeckungsproblem" und eines der häufigsten Probleme. Der Browser kann eine Ressource, von der er nichts weiß, nicht herunterladen. Wenn Ihr LCP-Bild in einer CSS- oder JavaScript-Datei versteckt ist, oder selbst wenn es im HTML ist, aber andere Ressourcen zuerst angefordert werden, findet der Browser es zu spät, was wertvolle Zeit verschwendet.
• Element Render Delay: Dies ist das "zu beschäftigt zum Malen"-Problem. Die LCP-Bild- datei könnte vollständig heruntergeladen sein, aber wenn der Main Thread des Browsers durch schwere JavaScript- Ausführung blockiert ist, kann er einfach nicht dazu kommen, das Bild auf den Bildschirm zu malen.

Der folgende Leitfaden ist so strukturiert, dass diese Phasen in einer logischen Reihenfolge angegangen werden. Beginnen Sie immer damit, sicherzustellen, dass Ihre TTFB schnell ist und Ihre LCP-Ressource auffindbar ist, bevor Sie zu Dateigrößen- und Render- Optimierungen übergehen.

Schritt 4: Führen Sie die Lösung aus

Mit dem identifizierten Engpass können Sie gezielte Optimierungen anwenden. Die Art und Weise, wie Sie diese Lösungen implementieren, hängt stark von der Architektur Ihrer Website ab. Wir behandeln zuerst die universellen Prinzipien für jede Phase und geben dann spezifische Ratschläge für WordPress und moderne JavaScript-Frameworks.

1. Optimierung der Time to First Byte (TTFB)

Wenn Ihre TTFB langsam ist (ein gutes Ziel ist unter 800ms [4]), legt dies eine hohe Untergrenze für Ihren LCP fest. Die Verbesserung der TTFB wird jede andere Lademetrik verbessern. Dies ist die Zeit, die der Browser benötigt, um das erste Byte HTML von Ihrem Server zu empfangen.

Universelle TTFB-Lösungen

• Caching aktivieren: Dies ist einer der effektivsten Wege, die TTFB zu verbessern. Caching generiert und speichert eine Kopie der Seite, so dass sie sofort bereitgestellt werden kann, ohne darauf zu warten, dass der Server sie bei jedem Besuch von Grund auf neu erstellt.
• Verwenden Sie ein CDN: Ein Content Delivery Network liefert Ihre Inhalte von einem Server, der sich physisch nah an Ihrem Benutzer befindet, was die Netzwerklatenz reduziert [5]. Das Caching Ihrer vollständigen HTML-Seiten am Edge des CDN ist eine leistungsstarke Strategie für eine schnelle, weltweite TTFB.
• Verwenden Sie Brotli- oder Gzip-Komprimierung: Stellen Sie sicher, dass Ihr Server textbasierte Assets wie HTML, CSS und JavaScript komprimiert. Brotli bietet eine bessere Komprimierung als Gzip und sollte bevorzugt werden.
• Verwenden Sie HTTP/3 mit 0-RTT: Stellen Sie sicher, dass Ihr Server für die Verwendung von HTTP/3 konfiguriert ist. Es bietet signifikante Leistungsvorteile, einschließlich besserem Multiplexing. Entscheidend ist, dass es 0-RTT (Zero Round Trip Time Resumption) unterstützt, was die Verbindungsaufbauzeit für wiederkehrende Besucher eliminiert und einen sofortigen TTFB-Schub bietet [6].
• Verwenden Sie 103 Early Hints: Für einen fortgeschrittenen Schub verwenden Sie den 103 Early Hints Status- code. Dies ermöglicht Ihrem Server oder CDN, Hinweise zu kritischen CSS- und JS-Dateien an den Browser zu senden, während dieser noch das vollständige HTML-Dokument vorbereitet, wodurch Downloads noch früher beginnen können [7]. Dies ist eine leistungsstarke Funktion auf Serverebene, von der jede Plattform profitieren kann.

Plattformspezifische TTFB-Lösungen

Auf WordPress:

• Investieren Sie in Qualitätshosting: Auf WordPress hängt eine langsame TTFB oft mit der Hosting-Umgebung zusammen. Billiges Shared Hosting kann ein Engpass sein. Ziehen Sie einen Managed WordPress- Host in Betracht, der auf Leistung optimiert ist.
• Verwenden Sie ein Caching-Plugin: Ein hochwertiges Caching-Plugin (z. B. WP Rocket, W3 Total Cache) ist nicht verhandelbar. Es übernimmt die Generierung statischer HTML-Dateien für Sie, was der Kern eines effektiven Cachings auf dieser Plattform ist.

Auf einem JS-Framework:

• Wählen Sie die richtige Hosting-Plattform: Für Node.js-Anwendungen sind Plattformen wie Vercel oder Netlify hochgradig für SSR/SSG-Frameworks optimiert und bieten intelligentes Caching und serverlose Funktionsausführung sofort einsatzbereit.
• Implementieren Sie SSR-Caching: Wenn Sie Server-Side Rendering verwenden, cachen Sie die gerenderten Seiten auf dem Server (z. B. mit Redis oder einem In-Memory-Cache), um ein erneutes Rendern bei jeder Anfrage zu vermeiden.
• Vorsicht vor Serverless Cold Starts: Wenn Sie serverlose Funktionen zum Rendern verwenden, seien Sie sich bewusst, dass ein "Kaltstart" (die erste Anfrage nach einer Zeit der Inaktivität) eine hohe TTFB haben kann. Verwenden Sie bereitgestellte Nebenläufigkeit oder Keep-Alive-Strategien, um dies zu mildern.

2. Reduzierung der Ressourcen-Ladeverzögerung (Resource Load Delay)

Dies ist häufig der größte Engpass. Es bedeutet, dass der Browser bereit war zu arbeiten, aber er konnte Ihr Hauptbild oder Ihre Schriftartdatei nicht sofort finden. Diese Verzögerung wird typischerweise durch eines von zwei Problemen verursacht: Die Ressource wird spät entdeckt oder ihr wird eine niedrige Download-Priorität zugewiesen.

Universelle Load Delay-Lösungen

Die universelle Lösung für Resource Load Delay besteht darin, sicherzustellen, dass Ihre LCP-Ressource sowohl auffindbar im anfänglichen HTML-Markup ist als auch vom Browser eine hohe Priorität erhält. So erreichen Sie das:

• Machen Sie die LCP-Ressource auffindbar: Der wichtigste Schritt ist sicherzustellen, dass Ihr LCP-Element in dem HTML vorhanden ist, das der Server sendet. Browser verwenden einen Hochgeschwindigkeits-"Preload Scanner", um im rohen HTML nach Ressourcen wie Bildern und Skripten zum Herunterladen vorauszuschauen. Wenn Ihr LCP-Bild über ein CSS-`background-image` geladen oder mit JavaScript eingefügt wird, ist es für diesen Scanner unsichtbar, was eine große Verzögerung verursacht. Die robusteste Lösung ist immer, ein Standard-<img>-Tag mit einem `src`-Attribut in Ihrem vom Server gerenderten HTML zu verwenden.
• Steuern Sie die Ladereihenfolge mit `preload`: Wenn Sie die LCP-Ressource nicht direkt auffindbar machen können (ein häufiges Problem bei Schriftarten oder CSS-Hintergrundbildern), ist die nächstbeste Lösung die Verwendung von <link rel="preload">. Dieses Tag fungiert als explizite Anweisung in Ihrem HTML <head> und weist den Browser an, mit dem Herunterladen einer kritischen Ressource viel früher zu beginnen, als er sie auf natürliche Weise gefunden hätte. Dies ist unerlässlich für die Änderung der absoluten Ladereihenfolge, um sicherzustellen, dass Ihr LCP-Bild oder Ihre Schriftart vor weniger kritischen Ressourcen wie asynchronen JavaScript-Dateien eingereiht wird.
• Sichern Sie hohe Priorität mit `fetchpriority`: Selbst wenn eine Ressource auffindbar ist, gibt der Browser ihr möglicherweise nicht die höchste Download-Priorität. Das Hinzufügen von fetchpriority="high" zu Ihrem <img>-Tag oder Ihrem <link rel="preload">-Tag ist ein starker Hinweis an den Browser, dass diese spezifische Ressource die wichtigste für die Benutzererfahrung ist, was ihr hilft, das Rennen um Bandbreite gegen andere Ressourcen zu gewinnen [8].

Plattformspezifische Load Delay-Lösungen

Auf WordPress:

• Vermeiden Sie Hintergrundbilder in Page Buildern: Viele Page Builder machen es einfach, ein Hero-Bild als CSS-`background-image` auf einem `div` festzulegen. Dies macht es für den Preload-Scanner des Browsers unsichtbar. Verwenden Sie, wenn möglich, einen Standard-``-Block. Wenn nicht, benötigen Sie möglicherweise ein Plugin oder benutzerdefinierten Code, um dieses spezifische Bild zu `preloaden`.
• Deaktivieren Sie Lazy-Loading für das LCP-Bild: Viele Optimierungs-Plugins werden automatisch alle Bilder lazy-loaden. Sie müssen die Einstellung in Ihrem Plugin finden, um das LCP- Bild (und oft die ersten paar Bilder auf der Seite) vom Lazy-Loading auszuschließen.

Auf einem JS-Framework:

• Verwenden Sie Server-Side Rendering (SSR): Dies ist oft die wirkungsvollste Lösung. Eine Standard-Client-Side Rendered (CSR) React-App sendet minimales HTML, und das LCP-Element existiert erst, nachdem ein großes JS-Bundle heruntergeladen und ausgeführt wurde. SSR-Frameworks wie Next.js oder Remix liefern das vollständige HTML, einschließlich des ``-Tags, so dass der Browser es sofort entdecken kann.
• Verwenden Sie Framework-spezifische Bildkomponenten: Frameworks wie Next.js bieten ein ` `-Element mit einer `priority`-Prop. Die Verwendung von ` ` wendet automatisch `fetchpriority="high"` und andere Optimierungen auf Ihr LCP-Bild an.

3. Verringerung der Ressourcen-Ladezeit (Resource Load Time)

Sicherzustellen, dass Ihre LCP-Ressource so klein wie möglich ist, ist immer noch ein entscheidender Teil des Prozesses. Diese Phase handelt davon, wie lange es dauert, die LCP-Ressourcendatei über das Netzwerk herunterzuladen.

Universelle Load Time-Lösungen

• Reduzieren Sie die Dateigröße mit modernen Formaten und responsiven Bildern: Der direkteste Weg, die Downloadzeit zu verkürzen, besteht darin, die Datei kleiner zu machen. Für Bilder bedeutet dies die Verwendung moderner, hocheffizienter Formate wie AVIF oder WebP [9]. Entscheidend ist, dass Sie auch responsive Bilder unter Verwendung des <picture>-Elements oder der srcset- und sizes-Attribute bereitstellen. Dies stellt sicher, dass ein Benutzer auf einem mobilen Gerät ein Bild erhält, das für seinen kleineren Bildschirm angemessen dimensioniert ist, anstatt gezwungen zu sein, ein riesiges Bild in Desktop-Größe herunterzuladen. Ein 400-Pixel breiter mobiler Bildschirm benötigt einfach keine 2000-Pixel breite Bild- datei. Für textbasierte LCPs stellen Sie sicher, dass Ihre Schriftarten im effizienten WOFF2-Format vorliegen und subsetted sind, um ungenutzte Zeichen zu entfernen.
• Reduzieren Sie Netzwerkkonkurrenz: Die LCP-Ressource muss um die begrenzte Netzwerkbandbreite des Benutzers konkurrieren. Das Zurückstellen nicht-kritischer Ressourcen wie Analyseskripte oder CSS für Inhalte unterhalb des Falzes macht Bandbreite frei, damit sich der Browser auf das schnellere Herunterladen der LCP- Ressource konzentrieren kann.
• Hosten Sie kritische Ressourcen auf Ihrer Hauptdomain: Vermeiden Sie es, Ihre LCP-Ressource von einer anderen Domain zu laden, wenn möglich. Das Einrichten einer neuen Verbindung zu einem anderen Server fügt zeitaufwändige DNS-Lookups und Handshakes hinzu.

Plattformspezifische Load Time-Lösungen

Auf WordPress:

• Verwenden Sie ein Bildoptimierungs-Plugin: Tools wie ShortPixel oder Smush können Bilder beim Hochladen automatisch komprimieren, sie in moderne Formate wie WebP/AVIF konvertieren und responsive `srcset`-Größen generieren.
• Manuelles Ändern der Bildgröße: Ändern Sie die Größe Ihrer Bilder vor dem Hochladen, damit sie nicht größer sind als sie sein müssen. Laden Sie kein 4000px breites Bild für einen Platz hoch, der nur 1200px breit auf den größten Bildschirmen ist.

Auf einem JS-Framework:

• Verwenden Sie ein Image CDN: Dies ist eine leistungsstarke Lösung. Dienste wie Cloudinary, Imgix oder Akamais Image & Video Manager können den gesamten Optimierungsprozess automatisieren. Sie laden ein hochwertiges Bild hoch, und sie liefern eine perfekt dimensionierte, komprimierte und formatierte Version an jeden Benutzer über ein schnelles CDN.
• Nutzen Sie Build-Tools: Wenn Sie ein Bild in eine Komponente in einem modernen Framework `importieren`, kann das Build-Tool (wie Webpack oder Vite) die Datei automatisch hashen und als Teil des Build-Prozesses optimieren.

4. Verkürzung der Element-Renderverzögerung (Element Render Delay)

Die Ressource wurde vollständig heruntergeladen, ist aber noch nicht auf dem Bildschirm. Das bedeutet, dass der Main Thread des Browsers mit anderen Aufgaben beschäftigt ist und das Element nicht malen kann. Dies ist ein weiterer sehr häufiger und signifikanter Engpass.

Universelle Render Delay-Lösungen

• Verschieben oder Entfernen von ungenutztem JavaScript: Jedes JS, das nicht für das Rendering des anfänglichen, sichtbaren Teils der Seite wesentlich ist, sollte unter Verwendung der defer- oder async-Attribute zurückgestellt werden.
• Verwenden Sie Critical CSS: Ein großes, Render-blockierendes Stylesheet kann das Rendering verzögern. Die Critical CSS-Technik beinhaltet das Extrahieren des minimalen CSS, das zum Stylen des Inhalts "Above the Fold" benötigt wird, das Inlining in den <head> und das asynchrone Laden der restlichen Stile [10].
• Brechen Sie lange Aufgaben auf: Ein lang laufendes Skript kann den Main Thread für einen längeren Zeitraum blockieren und das Rendering verhindern. Dies ist auch eine Hauptursache für schlechten Interaction to Next Paint (INP). Brechen Sie Ihren Code in kleinere, asynchrone Stücke auf, die an den Main Thread zurückgeben.

Plattformspezifische Render Delay-Lösungen

Auf WordPress:

• Prüfen Sie Ihre Plugins: Zu viele Plugins, besonders schwere wie Slider oder komplexe Page Builder, können signifikantes CSS und JS hinzufügen, das den Main Thread blockiert. Deaktivieren Sie Plugins nacheinander, um Leistungsfresser zu identifizieren.
• Verwenden Sie ein leichtgewichtiges Theme: Ein aufgeblähtes Theme mit Dutzenden von Funktionen, die Sie nicht verwenden, kann eine Hauptquelle für Render-blockierenden Code sein. Wählen Sie ein leistungsorientiertes Theme.
• Verwenden Sie Plugin Asset Manager: Tools wie Asset CleanUp oder Perfmatters ermöglichen es Ihnen, CSS und JS von bestimmten Plugins auf Seiten, auf denen sie nicht benötigt werden, bedingt zu deaktivieren.

Auf einem JS-Framework:

• Code Splitting ist der Schlüssel: Liefern Sie nicht das gesamte JavaScript Ihrer App in einem riesigen Bundle aus. Teilen Sie Ihren Code nach Route (damit Benutzer nur den Code für die Seite herunterladen, die sie besuchen) und nach Komponente auf.
• Lazy Load Components: Verwenden Sie `React.lazy` und `Suspense`, um Komponenten lazy zu laden, die nicht sofort sichtbar sind (z. B. Komponenten unterhalb des Falzes oder in Modals). Dies hält sie aus dem anfänglichen Bundle heraus.

Erweitert: Optimierung von LCP für nachfolgende Navigationen

Das Beheben des anfänglichen LCP ist entscheidend, aber Sie können eine dramatisch schnellere Erfahrung für Benutzer schaffen, während sie durch Ihre Website browsen, indem Sie für nachfolgende Seitenladevorgänge optimieren.

Stellen Sie sicher, dass Seiten für den Back/Forward Cache (bfcache) berechtigt sind

Der bfcache ist eine Browseroptimierung, die einen vollständigen Schnappschuss einer Seite im Speicher speichert, wenn ein Benutzer wegnavigiert. Wenn sie auf den Zurück-Button klicken, kann die Seite sofort wiederhergestellt werden, was zu einem nahezu null LCP führt. Viele Seiten sind aufgrund von Dingen wie `unload`-Event-Listenern für diesen Cache nicht berechtigt. Verwenden Sie das Lighthouse "bfcache"-Audit, um Ihre Seiten zu testen und blockierende Funktionen zu entfernen [11].

Verwenden Sie die Speculation Rules API für Prerendering

Die Speculation Rules API ist ein neues, leistungsstarkes Tool, mit dem Sie dem Browser deklarativ mitteilen können, zu welchen Seiten ein Benutzer wahrscheinlich als nächstes navigieren wird. Der Browser kann diese Seiten dann im Hintergrund abrufen und vorrendern. Wenn der Benutzer auf einen Link zu einer vorgerenderten Seite klickt, ist die Navigation sofortig, was zu einer phänomenalen Benutzererfahrung und einem nahezu null LCP führt [12]. Sie können diese Regeln in einem `<script type="speculationrules">`-Tag in Ihrem HTML definieren.

<script type="speculationrules">
 {
  "prerender": [{
   "source": "document",
   "where": {
    "href_matches": "/products/*"
   },
   "eagerness": "moderate"
  }]
 }
 </script>  

Dieses Beispiel weist den Browser an, nach Links auf der aktuellen Seite zu suchen, die zu Produktseiten führen, und damit zu beginnen, sie vorzurüsten, wenn ein Benutzer über den Link fährt.

Indem Sie diese vier Phasen methodisch durcharbeiten und fortschrittliche Navigationsoptimierungen in Betracht ziehen, können Sie die genaue Ursache Ihrer LCP-Probleme ermitteln und die richtige, wirkungsvolle Lösung anwenden.

Referenzen

1. web.dev: Lab and field data
2. Chrome for Developers: Debug Web Vitals in the field
3. web.dev: Optimize Largest Contentful Paint
4. web.dev: Optimize for a good TTFB
5. Cloudflare: What is a CDN?
6. web.dev: HTTP/3
7. web.dev: Slower is faster? Sending an HTTP 103 response to speed up your site
8. web.dev: Optimize LCP with fetchpriority
9. web.dev: Use modern image formats
10. web.dev: Extract critical CSS
11. web.dev: Back/forward cache
12. web.dev: Speculation Rules API