Largest Contentful Paint (LCP) Probleme erkennen und beheben

Dieser Leitfaden ist Teil des Largest Contentful Paint (LCP) Hubs. LCP misst, wie schnell das größte sichtbare Element rendert. Google verlangt einen Wert unter 2,5 Sekunden. Was folgt, ist der exakte Diagnoseprozess, den ich bei der Beratung zur Seitengeschwindigkeit verwende.

Ein Berater-Leitfaden zur Diagnose und Behebung von LCP

Mein Name ist Arjen Karel und ich bin Berater für Seitengeschwindigkeit. Über die Jahre habe ich hunderte Websites auditiert. Eine der hartnäckigsten Herausforderungen ist Largest Contentful Paint (LCP). In diesem Leitfaden teile ich die genaue Methode, die ich zur Diagnose und Behebung von LCP-Problemen nutze. Du wirst sehen, dass ich CoreDash erwähne. Das ist ein RUM-Tool, das ich entwickelt habe, um präzise Daten für diesen Prozess zu erhalten. Die Prinzipien hier sind universell. Ich zeige aber gerne echte Beispiele aus den Tools, die ich baue und täglich verwende.

LCP zu verbessern, ist ein Ausschlussverfahren. Laut dem 2025 Web Almanac bestehen nur 66 % der mobilen Origins den LCP. Das bedeutet, ein Drittel des Webs hat ein Ladeproblem. Finde die langsamste Phase, behebe sie, miss erneut.

Die Diagnosemethode: Zuerst Field Data, dann Lab Data

Um effektiv zu optimieren, musst du einen zweistufigen Diagnose-Workflow anwenden. So stellst du sicher, dass du Probleme löst, die deine Nutzer tatsächlich haben. Du jagst nicht einfach Scores in einer Laborumgebung hinterher.

1. Field Data (RUM & CrUX) zeigen dir, WAS passiert. Field Data werden von echten Nutzern gesammelt, die deine Seite besuchen. Sie sagen dir, ob du ein LCP-Problem hast, welche Seiten betroffen sind und welche Nutzer (Mobil oder Desktop) es erleben. Du musst immer hier beginnen, um ein echtes Problem zu bestätigen.
2. Lab Data (Lighthouse, DevTools) helfen dir zu diagnostizieren, WARUM es passiert. Lab Data werden in einer kontrollierten, simulierten Umgebung gesammelt. Sobald deine Field Data ein Problem auf einer bestimmten Seite bestätigt haben, kannst du Labortools nutzen. Damit reproduzierst du das Problem konsistent und analysierst den Ladeprozess, um die Ursache zu finden.

Beginne mit Field Data. So zielen deine Optimierungen auf Änderungen ab, die echte Nutzer tatsächlich beeinflussen.

Schritt 1: LCP-Probleme mit Field Data identifizieren

Deine erste Aufgabe ist es, mit echten Nutzerdaten zu bestätigen, welche Seiten einen schlechten LCP haben.

Ein zugänglicher Startpunkt: Google Search Console

Ein valider Startpunkt ist der Core Web Vitals-Bericht in der Google Search Console. Logge dich ein, navigiere zum Bericht und prüfe die Mobil- und Desktop-Diagramme. Wenn Google URLs mit „LCP-Problem: länger als 2,5 s“ markiert, hast du die Bestätigung aus dem Chrome User Experience (CrUX) Report. Ein Prozentsatz deiner Nutzer hat eine schlechte Erfahrung.

Die Search Console bestätigt das Problem. Sie aktualisiert sich aber langsam und gruppiert URLs. Für Details auf Seitenebene in Echtzeit brauchst du ein RUM-Tool.

Real User Monitoring (RUM): Details auf Seitenebene

Du kannst dein eigenes RUM-Setup mit der web-vitals-Bibliothek bauen, um Daten an dein Analytics-Backend zu senden. Das ist aber ein erheblicher Entwicklungsaufwand.

Ich habe CoreDash speziell dafür gebaut. Du fügst ein Script-Tag hinzu und es beginnt, LCP-Daten von jedem echten Besucher zu sammeln. Aufgeschlüsselt nach Seite, Gerät und Element.

Ein gutes RUM-Tool zeigt dir:

• Deinen präzisen LCP-Wert 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 verbunden sind.
• Das genaue Timing für jede der vier LCP-Phasen für jeden Seitenaufruf. Das lokalisiert den Engpass.

Über das LCP-Element hinauszuschauen ist wichtig. In einer gut dokumentierten Fallstudie verbesserte Vodafone seinen LCP um 31 %. Das trug direkt zu einer Umsatzsteigerung von 8 % bei. Ihre Optimierung fokussierte sich auf das Identifizieren und Beheben des spezifischen LCP-Engpasses auf wichtigen Landingpages. Sie nutzten eine Kombination aus Field Data-Analyse und gezielten Fixes. Bei der LCP-Optimierung geht es nicht nur um das Bild. Du musst die gesamte Ladepipeline verstehen: Serverantwort, Ressourcenerkennung, Download und Paint.

Zum Beispiel kannst du in CoreDash zur LCP-Seite navigieren und eine Datentabelle anzeigen. Sie zeigt deine langsamsten LCP-Elemente. Durch Klicken auf ein spezifisches Element (wie eine bestimmte CSS-Klasse für ein Hero-Bild) kannst du alle Metriken filtern. Du siehst dann die Leistungsdaten nur für Seiten, auf denen dieses Element der LCP war.

Das Ziel: Nutze Field Data, um deine langsamste Seite und ihr häufigstes LCP-Element zu finden. Das ist dein Ziel.

LCP mit der Performance Observer API messen

Die Performance Observer API gibt dir in JavaScript direkten Zugriff auf LCP-Einträge. Das ist dieselbe API, die RUM-Tools unter der Haube nutzen, um Field Data zu sammeln. Das folgende Snippet loggt jeden LCP-Kandidaten, den der Browser identifiziert. Inklusive Element, Größe und Renderzeit.

const observer = new PerformanceObserver((list) => {
  const entries = list.getEntries();
  const lastEntry = entries[entries.length - 1];
  console.log('LCP element:', lastEntry.element);
  console.log('LCP time:', lastEntry.renderTime || lastEntry.loadTime);
  console.log('LCP size:', lastEntry.size);
});
observer.observe({ type: 'largest-contentful-paint', buffered: true });

Das ist nützlich für die schnelle Validierung während der Entwicklung. Für die Messung in Produktion solltest du die web-vitals-Bibliothek verwenden. Sie behandelt Randfälle wie Änderungen der Tab-Sichtbarkeit und Wiederherstellungen aus dem Back/Forward-Cache.

Schritt 2: Den Engpass mit Lab-Tools diagnostizieren

Du weißt, welche Seite du beheben musst. Finde jetzt heraus, warum sie langsam ist. Führe einen Test mit PageSpeed Insights oder dem Lighthouse-Panel in den Chrome DevTools durch.

Scrolle im Bericht nach unten zum Bereich „Diagnostics“ und finde das Audit „Largest Contentful Paint element“. Dieses Wasserfalldiagramm schlüsselt deine LCP-Zeit in ihre vier Teilbereiche auf. Dein RUM-Tool sollte basierend auf deinen Field Data eine ähnliche Aufschlüsselung zeigen.

Dein Ziel ist es, die längste Phase in dieser Aufschlüsselung zu finden. Das ist dein primärer Engpass. Darauf solltest du deine Optimierungen zuerst konzentrieren.

Schritt-für-Schritt-Anleitung: Arbeitest du lieber in DevTools? LCP mit dem Chrome DevTools Performance-Panel diagnostizieren zeigt, wie man einen gedrosselten Trace aufzeichnet und dieselben vier Teilbereiche aus dem LCP Breakdown Insight abliest.

Schritt 3: Die vier LCP-Phasen verstehen

Jeder LCP-Wert ist die Summe aus vier aufeinanderfolgenden Phasen. Jede Phase hat auf dieser Seite einen eigenen Leitfaden. Er deckt spezifische Optimierungstechniken ab.

• Time to First Byte (TTFB): Das ist das Fundament, das du nicht überspringen kannst. Eine langsame Serverantwort verlängert deinen LCP direkt, Millisekunde für Millisekunde. Bevor du ein einziges Bild optimierst, musst du sicherstellen, dass dein Server schnell antwortet. Erfahre mehr über die Optimierung der TTFB.
• Resource Load Delay: Das ist das „Erkennungsproblem“ und eines der häufigsten Probleme. Der Browser kann keine Ressource herunterladen, die er nicht kennt. Wenn dein LCP-Bild in einer CSS- oder JavaScript-Datei versteckt ist oder sich im HTML befindet, aber andere Ressourcen zuerst angefragt werden, findet der Browser es zu spät. Du verschwendest wertvolle Zeit. Lies den vollständigen Leitfaden zu Resource Load Delay.
• Resource Load Duration: Das ist die Downloadzeit für die LCP-Ressource selbst. Große, unkomprimierte Bilder oder langsame Netzwerkbedingungen können diese Phase zum Engpass machen. Lies den vollständigen Leitfaden zu Resource Load Duration.
• Element Render Delay: Das ist das „Zu-beschäftigt-zum-Rendern“-Problem. Die LCP-Bilddatei mag vollständig heruntergeladen sein. Wenn der main thread des Browsers jedoch durch schwere JavaScript-Ausführung blockiert ist, kommt er einfach nicht dazu, das Bild auf dem Bildschirm zu rendern. Lies den vollständigen Leitfaden zu Element Render Delay.

Beginne immer damit, dass deine TTFB schnell ist und deine LCP-Ressource rechtzeitig erkannt wird. Gehe erst danach zu Dateigrößen- und Render-Optimierungen über.

Schritt 4: Den Fix ausführen

Sobald der Engpass identifiziert ist, wende den Fix an. Die Implementierung hängt von deinem Stack ab. Jede Phase unten behandelt zuerst universelle Prinzipien. Danach folgen Besonderheiten von WordPress und JS-Frameworks.

1. Time to First Byte (TTFB) optimieren

Wenn deine TTFB langsam ist (ein gutes Ziel ist unter 800 ms), setzt das eine hohe Untergrenze für deinen LCP. Eine Verbesserung der TTFB wird jede andere Lademetrik verbessern.

Universelle TTFB-Lösungen

• Caching aktivieren: Das ist einer der effektivsten Wege, die TTFB zu verbessern. Caching generiert und speichert eine Kopie der Seite. So kann sie sofort ausgeliefert werden. Der Server muss sie nicht bei jedem Besuch von Grund auf neu bauen.
• Ein CDN nutzen: Ein Content Delivery Network liefert deine Inhalte von einem Server aus, der physisch nah an deinem Nutzer ist. Das reduziert die Netzwerklatenz. Das Caching deiner vollständigen HTML-Seiten an der CDN-Edge ist eine mächtige Strategie für eine schnelle, globale TTFB. Für detaillierte CDN-Konfigurationstipps lies unseren Leitfaden, wie du Cloudflare für optimale Performance konfigurierst.
• Brotli- oder Gzip-Komprimierung nutzen: Stelle sicher, dass dein Server textbasierte Assets wie HTML, CSS und JavaScript komprimiert. Brotli bietet eine bessere Komprimierung als Gzip und sollte bevorzugt werden.
• HTTP/3 mit 0-RTT nutzen: Stelle sicher, dass dein Server für HTTP/3 konfiguriert ist. Es bietet signifikante Performance-Vorteile. Dazu gehört besseres Multiplexing. Es unterstützt 0-RTT (Zero Round Trip Time Resumption). Das eliminiert die Verbindungsaufbauzeit für wiederkehrende Besucher und sorgt für einen sofortigen TTFB-Boost.
• 103 Early Hints nutzen: Für einen fortgeschrittenen Boost nutze den 103 Early Hints-Statuscode. Das erlaubt deinem Server oder CDN, dem Browser Hinweise zu kritischen CSS- und JS-Dateien zu senden, während er noch das vollständige HTML-Dokument vorbereitet. Downloads können so noch früher starten. Für einen kompletten Implementierungsleitfaden lies unseren Artikel über 103 Early Hints.

Plattformspezifische TTFB-Fixes

Auf WordPress:

• In hochwertiges Hosting investieren: Bei WordPress hängt eine langsame TTFB oft mit der Hosting-Umgebung zusammen. Billiges Shared Hosting kann ein Engpass sein. Ziehe einen Managed WordPress Host in Betracht, der auf Leistung optimiert ist.
• Ein Caching-Plugin nutzen: Ein hochwertiges Caching-Plugin (z. B. WP Rocket, W3 Total Cache) ist nicht verhandelbar. Es übernimmt die Generierung statischer HTML-Dateien für dich. Das ist der Kern von effektivem Caching auf dieser Plattform.

In einem JS-Framework:

• Die richtige Hosting-Plattform wählen: Für Node.js-Anwendungen sind Plattformen wie Vercel oder Netlify stark auf SSR/SSG-Frameworks optimiert. Sie bieten intelligentes Caching und serverless Function Execution out-of-the-box.
• SSR-Caching implementieren: Wenn du Server-Side Rendering nutzt, cache die gerenderten Seiten auf dem Server (z. B. mit Redis oder einem In-Memory-Cache). Vermeide so das erneute Rendern bei jeder Anfrage.
• Vorsicht vor Serverless Cold Starts: Wenn du Serverless Functions fürs Rendering verwendest, sei dir bewusst: Ein „Cold Start“ (die erste Anfrage nach einer Inaktivitätsphase) kann eine hohe TTFB haben. Nutze Provisioned Concurrency oder Keep-Alive-Strategien, um das abzuschwächen.

2. Resource Load Delay reduzieren

Das ist häufig der größte Engpass. Es bedeutet, der Browser war arbeitsbereit. Er konnte aber dein Hauptbild oder deine Schriftartendatei nicht sofort finden. Diese Verzögerung wird typischerweise durch eines von zwei Problemen verursacht. Die Ressource wird spät entdeckt oder sie erhält eine niedrige Download-Priorität. Für den vollständigen Leitfaden zu diesem Thema lies unseren speziellen Ratgeber zu Resource Load Delay.

Universelle Load Delay-Lösungen

Die universelle Lösung für das Resource Load Delay: Stelle sicher, dass deine LCP-Ressource im initialen HTML-Markup erkennbar ist. Sie muss vom Browser zudem eine hohe Priorität erhalten. So erreichst du das:

• Die LCP-Ressource auffindbar machen: Der wichtigste Schritt ist, dass dein LCP-Element im HTML vorhanden ist, das der Server sendet. Browser nutzen einen schnellen „Preload Scanner“. Er sucht im rohen HTML vorab nach Ressourcen wie Bildern und Skripten zum Herunterladen. Wenn dein LCP-Bild über ein CSS-background-image geladen oder per JavaScript injiziert wird, ist es für diesen Scanner unsichtbar. Das verursacht eine große Verzögerung. Die robusteste Lösung ist immer ein Standard-<img>-Tag mit einem src-Attribut in deinem server-gerenderten HTML.
• Die Ladereihenfolge mit preload steuern: Wenn du die LCP-Ressource nicht direkt auffindbar machen kannst (oft bei Schriften oder CSS-Hintergrundbildern), ist die nächstbeste Lösung <link rel="preload">. Dieses Tag fungiert als explizite Anweisung in deinem HTML-<head>. Es sagt dem Browser, dass er eine kritische Ressource viel früher herunterladen soll, als er sie natürlich gefunden hätte. Für Implementierungsdetails und Beispiele lies unseren Leitfaden, wie man das LCP-Bild per Preload lädt.
• Hohe Priorität mit fetchpriority sicherstellen: Auch wenn eine Ressource auffindbar ist, gibt ihr der Browser vielleicht nicht die höchste Download-Priorität. Das Hinzufügen von fetchpriority="high" zu deinem <img>-Tag oder <link rel="preload">-Tag ist ein starker Hinweis an den Browser. Diese spezifische Ressource ist die wichtigste für die Nutzererfahrung. Das hilft ihr, den Kampf um Bandbreite gegen andere Ressourcen zu gewinnen.

Plattformspezifische Load Delay-Fixes

Auf WordPress:

• Page Builder-Hintergrundbilder vermeiden: Viele Page Builder machen es leicht, ein Hero-Bild als CSS-background-image auf einem div zu setzen. Das macht es für den Preload Scanner des Browsers unsichtbar. Wenn möglich, nutze stattdessen einen Standard-<img>-Block. Wenn nicht, brauchst du vielleicht ein Plugin oder eigenen Code, um dieses spezifische Bild per Preload zu laden.
• Lazy Loading für das LCP-Bild deaktivieren: Viele Optimierungs-Plugins laden alle Bilder automatisch per Lazy Loading. Du musst die Einstellung in deinem Plugin finden, um das LCP-Bild (und oft die ersten paar Bilder auf der Seite) vom Lazy Loading auszuschließen. Das ist ein so häufiger Fehler, dass wir einen eigenen Artikel über die Behebung von per Lazy Loading geladenen LCP-Bildern haben.

In einem JS-Framework:

• Server-Side Rendering (SSR) nutzen: Das ist oft der wirkungsvollste Fix. Eine standardmäßige Client-Side Rendered (CSR) React-App sendet minimales HTML. 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 inklusive dem <img>-Tag. So kann der Browser es sofort erkennen.
• Framework-spezifische Bildkomponenten nutzen: Frameworks wie Next.js bieten eine Bildkomponente mit einer priority-Prop. Die Nutzung dieser Prop wendet automatisch fetchpriority="high" und weitere Optimierungen auf dein LCP-Bild an.

3. Resource Load Duration verringern

Es bleibt ein wesentlicher Teil des Prozesses, deine LCP-Ressource so klein wie möglich zu halten. In dieser Phase geht es darum, wie lange das Herunterladen der LCP-Ressourcendatei über das Netzwerk dauert. Für einen vollständigen Leitfaden zu Bildoptimierungstechniken siehe unseren Artikel zur Optimierung des LCP-Bildes und speziell für mehr über Resource Load Duration.

Universelle Load Time-Lösungen

• Dateigröße mit modernen Formaten und Responsive Images reduzieren: Der direkteste Weg, die Downloadzeit zu verkürzen, ist eine kleinere Datei. Für Bilder bedeutet das, moderne, hocheffiziente Formate wie AVIF oder WebP zu nutzen. Du musst auch Responsive Images mit dem <picture>-Element oder den srcset- und sizes-Attributen ausliefern. Das stellt sicher, dass ein Nutzer auf einem mobilen Gerät ein Bild in passender Größe erhält. Er wird nicht gezwungen, ein riesiges Desktop-Bild herunterzuladen. Ein 400 Pixel breiter mobiler Bildschirm braucht einfach keine 2000 Pixel breite Bilddatei. Für textbasierte LCPs stelle sicher, dass deine Schriften im effizienten WOFF2-Format vorliegen. Sie sollten mittels Subsetting verkleinert werden, um ungenutzte Zeichen zu entfernen.
• Netzwerkkonkurrenz reduzieren: Die LCP-Ressource muss um die begrenzte Netzwerkbandbreite des Nutzers konkurrieren. Das Zurückstellen unkritischer Ressourcen (wie Analytics-Skripte oder CSS für Below-the-fold-Inhalte) gibt Bandbreite frei. So kann sich der Browser auf den schnelleren Download der LCP-Ressource fokussieren.
• Kritische Ressourcen auf deiner Hauptdomain hosten: Vermeide es möglichst, deine LCP-Ressource von einer anderen Domain zu laden. Der Aufbau einer neuen Verbindung zu einem anderen Server fügt zeitraubende DNS-Lookups und Handshakes hinzu.

Plattformspezifische Load Time-Fixes

Auf WordPress:

• Ein Bildoptimierungs-Plugin nutzen: Tools wie ShortPixel oder Smush können Bilder beim Upload automatisch komprimieren. Sie konvertieren diese in moderne Formate wie WebP/AVIF und generieren responsive srcset-Größen.
• Bilder manuell skalieren: Skaliere deine Bilder vor dem Upload, damit sie nicht größer als nötig sind. Lade kein 4000 Pixel breites Bild für einen Bereich hoch, der auf den größten Bildschirmen nur 1200 Pixel breit ist.

In einem JS-Framework:

• Ein Image CDN nutzen: Das ist eine mächtige Lösung. Dienste wie Cloudinary, Imgix oder Akamais Image & Video Manager können den gesamten Optimierungsprozess automatisieren. Du lädst ein hochqualitatives Bild hoch. Sie liefern jedem Nutzer über ein schnelles CDN eine perfekt dimensionierte, komprimierte und formatierte Version.
• Build Tools nutzen: Wenn du ein Bild in eine Komponente in einem modernen Framework importierst, kann das Build Tool (wie Webpack oder Vite) die Datei als Teil des Build-Prozesses automatisch hashen und optimieren.

4. Element Render Delay verkürzen

Die Ressource ist fertig heruntergeladen, aber noch nicht auf dem Bildschirm. Das bedeutet, der main thread des Browsers ist mit anderen Aufgaben beschäftigt. Er kann das Element nicht zeichnen. Das ist ein weiterer sehr häufiger und signifikanter Engpass. Für den vollständigen Leitfaden lies unseren Artikel zu Element Render Delay.

Universelle Render Delay-Lösungen

• Ungenutztes JavaScript zurückstellen oder entfernen: Jedes JS, das nicht essentiell für das Rendern des initialen, sichtbaren Teils der Seite ist, sollte mit den Attributen defer oder async zurückgestellt werden.
• Critical CSS nutzen: Ein großes, render-blocking Stylesheet kann das Rendern verzögern. Bei der Critical CSS-Technik extrahierst du das minimale CSS für die Above-the-fold-Inhalte. Du bindest es inline im <head> ein und lädst die restlichen Styles asynchron.
• Long Tasks aufteilen: Ein langlaufendes Skript kann den main thread für längere Zeit blockieren und das Rendern verhindern. Das ist auch eine Hauptursache für ein schlechtes Interaction to Next Paint (INP). Teile deinen Code in kleinere, asynchrone Stücke auf. Nutze yielding für den main thread.

Plattformspezifische Render Delay-Fixes

Auf WordPress:

• Deine Plugins auditieren: Zu viele Plugins, besonders schwere wie Slider oder komplexe Page Builder, können signifikantes CSS und JS hinzufügen. Das blockiert den main thread. Deaktiviere Plugins nacheinander, um Performance-Fresser zu identifizieren.
• Ein leichtgewichtiges Theme nutzen: Ein überladenes Theme mit dutzenden Features, die du nicht nutzt, kann eine Hauptursache für render-blocking Code sein. Wähle ein Theme mit Fokus auf Performance.
• Plugin Asset Manager nutzen: Tools wie Asset CleanUp oder Perfmatters erlauben dir, CSS und JS von bestimmten Plugins bedingt zu deaktivieren. Und zwar auf Seiten, wo sie nicht gebraucht werden.

In einem JS-Framework:

• Code Splitting ist der Schlüssel: Liefere nicht das gesamte JavaScript deiner App in einem riesigen Bundle aus. Teile deinen Code nach Route (damit Nutzer nur den Code der besuchten Seite herunterladen) und nach Komponente auf.
• Komponenten per Lazy Loading laden: Nutze React.lazy und Suspense, um Komponenten per Lazy Loading zu laden, die nicht sofort sichtbar sind (z. B. Komponenten Below-the-fold oder in Modals). Das hält sie aus dem initialen Bundle heraus.

Fortgeschritten: LCP für nachfolgende Navigationen optimieren

Den initialen LCP zu beheben, ist wichtig. Du kannst das Surfen auf deiner Seite aber sofort reagierend anfühlen lassen, indem du für nachfolgende Seitenladevorgänge optimierst.

Stelle sicher, dass Seiten für den Back/Forward Cache (bfcache) geeignet sind

Der bfcache ist eine Browseroptimierung. Sie speichert einen kompletten Snapshot einer Seite im Arbeitsspeicher, wenn ein Nutzer wegnavigiert. Klickt er den Zurück-Button, kann die Seite sofort wiederhergestellt werden. Das resultiert in einem LCP nahe null. Viele Seiten sind für diesen Cache aufgrund von Dingen wie unload Event Listenern ungeeignet. Nutze das Lighthouse „bfcache“-Audit, um deine Seiten zu testen. Entferne alle blockierenden Features.

Nutze die Speculation Rules API fürs Prerendering

Die Speculation Rules API erlaubt dir, dem Browser deklarativ mitzuteilen, welche Seiten ein Nutzer als Nächstes wahrscheinlich besucht. Der Browser kann diese Seiten dann im Hintergrund fetchen und prerendern. Klickt der Nutzer einen Link zu einer vorausgerenderten Seite, erfolgt die Navigation sofort. Das führt zu einem LCP nahe null. Du kannst diese Regeln in einem <script type="speculationrules">-Tag in deinem HTML definieren.

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

Dieses Beispiel weist den Browser an, auf der aktuellen Seite nach Links zu Produktseiten zu suchen. Er soll mit dem Prerendering beginnen, wenn ein Nutzer mit der Maus über den Link fährt.

Arbeite die vier Phasen der Reihe nach ab. Behebe den größten Engpass zuerst, miss erneut, wiederhole.

Nächste Schritte: Jede LCP-Phase im Detail

Jede LCP-Phase hat ihren eigenen Leitfaden:

• Das LCP-Bild optimieren: Ein kompletter Leitfaden zur Auswahl des Bildformats, Responsive Images, Preloading und häufigen Fehlern bei der Bildoptimierung.
• Resource Load Delay: Wie du sicherstellst, dass der Browser deine LCP-Ressource so früh wie möglich erkennt. Nutze Preload, fetchpriority und die richtige HTML-Struktur.
• Resource Load Duration: Wie du die Downloadzeit für deine LCP-Ressource reduzierst. Durch Dateikomprimierung, moderne Formate, CDN-Konfiguration und Netzwerkoptimierung.
• Element Render Delay: Wie du den main thread des Browsers freimachst. So kann er das LCP-Element sofort nach dem Download zeichnen. Behandelt Critical CSS, JavaScript-Deferral und content-visibility.