LCP-Probleme finden und beheben: Largest Contentful Paint (LCP)

Dieser Leitfaden ist Teil des Largest Contentful Paint (LCP) Hubs. LCP misst, wie schnell das größte sichtbare Element gerendert wird. Google möchte, dass es unter 2,5 Sekunden liegt. Was folgt, ist der genaue 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 ein Page-Speed-Berater. Im Laufe der Jahre habe ich Hunderte von Websites geprüft, und eine der hartnäckigsten Herausforderungen ist Largest Contentful Paint (LCP). In diesem Leitfaden teile ich die genaue Methodik, die ich zur Diagnose und Lösung von LCP-Problemen verwende. Sie werden Erwähnungen von CoreDash sehen, einem RUM-Tool, das ich entwickelt habe, um die präzisen Daten für diesen Prozess zu erhalten. 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 von LCP ist ein Ausschlussprozess. Laut dem 2025 Web Almanac bestehen nur 66% der mobilen Ursprünge LCP. Das bedeutet, ein Drittel des Webs hat ein Ladeproblem. Finden Sie die langsamste Phase, beheben Sie sie, messen Sie erneut.

Die Diagnosemethodik: Zuerst Felddaten, dann Lab-Daten

Um effektiv zu optimieren, müssen Sie einen zweistufigen Diagnose-Workflow anwenden. Dies stellt sicher, dass Sie Probleme lösen, die Ihre Benutzer tatsächlich haben, und nicht nur Scores in einer Lab-Umgebung jagen.

1. Felddaten (RUM & CrUX) zeigen Ihnen, WAS passiert. Felddaten werden von echten Benutzern, die Ihre Website besuchen, erhoben. 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 ein echtes Problem zu bestätigen.
2. Lab-Daten (Lighthouse, DevTools) helfen Ihnen zu diagnostizieren, WARUM es passiert. Lab-Daten werden in einer kontrollierten, simulierten Umgebung erhoben. Sobald Ihre Felddaten ein Problem auf einer bestimmten Seite bestätigt haben, können Sie Lab-Tools verwenden, um das Problem konsistent zu replizieren und den Ladeprozess zu analysieren, um die Grundursache zu finden.

Beginnen Sie mit Felddaten, damit Ihre Optimierungsbemühungen auf Änderungen abzielen, die tatsächlich echte Benutzer betreffen.

Schritt 1: LCP-Probleme mit Felddaten identifizieren

Ihre erste Aufgabe ist es, reale Benutzerdaten zu verwenden, um zu bestätigen, welche Seiten, falls vorhanden, einen schlechten LCP haben.

Ein zugänglicher Ausgangspunkt: Google Search Console

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

Search Console bestätigt das Problem, aber sie aktualisiert sich langsam und gruppiert URLs zusammen. Für seitenspezifische Details in Echtzeit benötigen Sie ein RUM-Tool.

Real User Monitoring (RUM): Details auf Seitenebene

Sie können Ihr eigenes RUM-Setup mit der web-vitals-Bibliothek aufbauen und die Daten an Ihr eigenes Analytics-Backend senden, aber das ist ein erheblicher Entwicklungsaufwand.

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

Ein gutes RUM-Tool lässt Sie sehen:

• Ihren genauen LCP-Score für jede spezifische URL.
• Eine Aufschlüsselung jedes LCP-Elements (z.B. ein Bild, eine Überschrift) und welche davon am häufigsten mit einem langsamen LCP verbunden sind.
• Das genaue Timing für jede der vier LCP-Phasen für jeden Seitenaufruf, das den Engpass genau lokalisiert.

Über das LCP-Element selbst hinauszuschauen ist wichtig. In einer gut dokumentierten Fallstudie verbesserte Vodafone ihren LCP um 31%, was direkt zu einer 8%igen Umsatzsteigerung beitrug. Ihre Optimierung konzentrierte sich darauf, den spezifischen LCP-Engpass auf wichtigen Landingpages zu identifizieren und zu beheben, indem Felddatenanalyse und gezielte Korrekturen kombiniert wurden. LCP-Optimierung dreht sich nicht nur um das Bild. Sie müssen die gesamte Lade-Pipeline verstehen: Serverantwort, Ressourcenerkennung, Download und Paint.

Zum Beispiel können Sie in CoreDash 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 zu sehen, auf denen dieses Element das LCP war.

Das Ziel: Verwenden Sie Felddaten, um Ihre langsamste Seite und ihr häufigstes LCP-Element zu finden. Das ist Ihr Ziel.

LCP messen mit der Performance Observer API

Die Performance Observer API gibt Ihnen direkten Zugriff auf LCP-Einträge in JavaScript. Dies ist die gleiche API, die RUM-Tools unter der Haube verwenden, um Felddaten zu erfassen. Das folgende Snippet protokolliert jeden LCP-Kandidaten, den der Browser identifiziert, einschließlich des Elements, seiner Größe und der 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 });

Dies ist nützlich zur schnellen Validierung während der Entwicklung, aber für Produktionsmessungen sollten Sie die web-vitals-Bibliothek verwenden, die Sonderfälle wie Tab-Sichtbarkeitsänderungen und Back/Forward-Cache-Wiederherstellungen behandelt.

Schritt 2: Den Engpass mit Lab-Tools diagnostizieren

Sie wissen, welche Seite repariert werden muss. Finden Sie nun heraus, warum sie langsam ist. Führen Sie einen Test mit PageSpeed Insights oder dem Lighthouse-Panel in Chrome DevTools durch.

Scrollen Sie im Bericht zum Abschnitt "Diagnostics" und finden Sie das Audit "Largest Contentful Paint element". Dieses Wasserfalldiagramm schlüsselt Ihre LCP-Zeit in ihre vier Teilphasen 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 dort sollten Sie Ihre Optimierungsbemühungen zuerst konzentrieren.

Schritt 3: Die vier LCP-Phasen verstehen

Jeder LCP-Score ist die Summe von vier aufeinanderfolgenden Phasen. Jede Phase hat einen eigenen Leitfaden auf dieser Website mit spezifischen Optimierungstechniken.

• Time to First Byte (TTFB): Dies ist das unvermeidbare Fundament. Eine langsame Serverantwort ist eine direkte, millisekundengenaue Addition zu Ihrem LCP. Bevor Sie ein einziges Bild optimieren, müssen Sie sicherstellen, dass Ihr Server schnell antwortet. Erfahren Sie mehr über die Optimierung von TTFB.
• Resource Load Delay: Dies ist das "Erkennungsproblem" und eines der häufigsten Probleme. Der Browser kann keine Ressource herunterladen, von der er nichts weiß. Wenn Ihr LCP-Bild in einer CSS- oder JavaScript-Datei versteckt ist, oder selbst wenn es im HTML steht, aber andere Ressourcen zuerst angefordert werden, findet der Browser es zu spät und verschwendet wertvolle Zeit. Lesen Sie den vollständigen Leitfaden zu Resource Load Delay.
• Resource Load Duration: Dies ist die Download-Zeit für die LCP-Ressource selbst. Große, unkomprimierte Bilder oder langsame Netzwerkbedingungen können diese Phase zum Engpass machen. Lesen Sie den vollständigen Leitfaden zu Resource Load Duration.
• Element Render Delay: Dies ist das "zu beschäftigt zum Malen"-Problem. Die LCP-Bilddatei ist möglicherweise vollständig heruntergeladen, aber wenn der Haupt-Thread des Browsers durch schwere JavaScript-Ausführung blockiert ist, kann er das Bild einfach nicht auf den Bildschirm zeichnen. Lesen Sie den vollständigen Leitfaden zu Element Render Delay.

Stellen Sie immer zuerst sicher, dass Ihr TTFB schnell ist und Ihre LCP-Ressource auffindbar ist, bevor Sie sich mit Dateigröße und Render-Optimierungen befassen.

Schritt 4: Die Lösung umsetzen

Mit dem identifizierten Engpass wenden Sie die Lösung an. Die Umsetzung hängt von Ihrem Stack ab. Jede Phase unten behandelt zuerst universelle Prinzipien, dann WordPress- und JS-Framework-Spezifika.

1. Time to First Byte (TTFB) optimieren

Wenn Ihr TTFB langsam ist (ein gutes Ziel ist unter 800ms), setzt es eine hohe Untergrenze für Ihren LCP. Die Verbesserung von TTFB verbessert jede andere Lademetrik.

Universelle TTFB-Lösungen

• Caching aktivieren: Dies ist einer der effektivsten Wege, um TTFB zu verbessern. Caching generiert und speichert eine Kopie der Seite, damit sie sofort ausgeliefert werden kann, ohne darauf zu warten, dass der Server sie bei jedem Besuch von Grund auf neu erstellt.
• Ein CDN verwenden: Ein Content Delivery Network liefert Ihre Inhalte von einem Server aus, der sich physisch in der Nähe Ihres Benutzers befindet, was die Netzwerklatenz reduziert. Das Caching Ihrer vollständigen HTML-Seiten am Edge des CDN ist eine leistungsstarke Strategie für einen schnellen, globalen TTFB. Für detaillierte CDN-Konfigurationstipps siehe unseren Leitfaden zur Konfiguration von Cloudflare für optimale Leistung.
• Brotli- oder Gzip-Komprimierung verwenden: Stellen Sie sicher, dass Ihr Server textbasierte Assets wie HTML, CSS und JavaScript komprimiert. Brotli bietet bessere Komprimierung als Gzip und sollte bevorzugt werden.
• HTTP/3 mit 0-RTT verwenden: Stellen Sie sicher, dass Ihr Server für die Verwendung von HTTP/3 konfiguriert ist. Es bietet erhebliche Leistungsvorteile, einschließlich besseres Multiplexing. Es unterstützt 0-RTT (Zero Round Trip Time Resumption), das die Verbindungsaufbauzeit für wiederkehrende Besucher eliminiert und einen sofortigen TTFB-Boost bietet.
• 103 Early Hints verwenden: Für einen fortgeschrittenen Boost verwenden Sie den 103 Early Hints Statuscode. Dies ermöglicht es Ihrem Server oder CDN, Hinweise über kritische CSS- und JS-Dateien an den Browser zu senden, während er noch das vollständige HTML-Dokument vorbereitet, sodass Downloads noch früher beginnen können. Für eine vollständige Implementierungsanleitung siehe unseren Artikel über 103 Early Hints.

Plattformspezifische TTFB-Lösungen

Auf WordPress:

• In Qualitäts-Hosting investieren: Auf WordPress hängt ein langsamer TTFB oft mit der Hosting-Umgebung zusammen. Günstiges Shared-Hosting kann ein Engpass sein. Erwägen Sie einen verwalteten WordPress-Hoster, der für Leistung optimiert ist.
• Ein Caching-Plugin verwenden: Ein hochwertiges Caching-Plugin (z.B. WP Rocket, W3 Total Cache) ist unverzichtbar. Es übernimmt die Generierung statischer HTML-Dateien für Sie, was der Kern effektiven Cachings auf dieser Plattform ist.

Auf einem JS-Framework:

• Die richtige Hosting-Plattform wählen: Für Node.js-Anwendungen sind Plattformen wie Vercel oder Netlify hochoptimiert für SSR/SSG-Frameworks und bieten intelligentes Caching und serverlose Funktionsausführung direkt ab Werk.
• SSR-Caching implementieren: 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, beachten Sie, dass ein "Cold Start" (die erste Anfrage nach einer Phase der Inaktivität) einen hohen TTFB haben kann. Verwenden Sie Provisioned Concurrency oder Keep-Alive-Strategien, um dies abzumildern.

2. Resource Load Delay reduzieren

Dies ist häufig der größte Engpass. Es bedeutet, dass der Browser bereit war zu arbeiten, aber Ihr Hauptbild oder Ihre Schriftdatei nicht sofort finden konnte. 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 lesen Sie unseren dedizierten Leitfaden zu Resource Load Delay.

Universelle Load-Delay-Lösungen

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

• Die LCP-Ressource auffindbar machen: Der wichtigste Schritt ist sicherzustellen, dass Ihr LCP-Element im HTML vorhanden ist, das der Server sendet. Browser verwenden einen Hochgeschwindigkeits-"Preload-Scanner", um im rohen HTML nach Ressourcen wie Bildern und Scripts zu suchen, die heruntergeladen werden sollen. Wenn Ihr LCP-Bild über ein CSS-background-image geladen oder mit JavaScript injiziert wird, ist es für diesen Scanner unsichtbar, was zu einer erheblichen Verzögerung führt. Die robusteste Lösung ist immer die Verwendung eines Standard-<img>-Tags mit einem src-Attribut in Ihrem servergerenderten HTML.
• Die Ladereihenfolge mit preload steuern: Wenn Sie die LCP-Ressource nicht direkt auffindbar machen können (ein häufiges Problem bei Schriften oder CSS-Hintergrundbildern), ist die nächstbeste Lösung die Verwendung von <link rel="preload">. Dieses Tag dient als explizite Anweisung in Ihrem HTML-<head>, die dem Browser sagt, eine kritische Ressource viel früher herunterzuladen, als er sie natürlich gefunden hätte. Für Implementierungsdetails und Beispiele siehe unseren Leitfaden zum Preloading des LCP-Bildes.
• Hohe Priorität mit fetchpriority sicherstellen: 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 user experience ist und ihr hilft, den Kampf um Bandbreite gegen andere Ressourcen zu gewinnen.

Plattformspezifische Load-Delay-Lösungen

Auf WordPress:

• Page-Builder-Hintergrundbilder vermeiden: Viele Page-Builder machen es einfach, ein Hero-Bild als CSS-background-image auf einem div zu setzen. Dies macht es für den Preload-Scanner des Browsers unsichtbar. Verwenden Sie wenn möglich stattdessen einen Standard-<img>-Block. Andernfalls benötigen Sie möglicherweise ein Plugin oder benutzerdefinierten Code, um dieses spezifische Bild vorab zu laden.
• Lazy-Loading für das LCP-Bild deaktivieren: Viele Optimierungs-Plugins werden automatisch alle Bilder lazy-laden. Sie müssen die Einstellung in Ihrem Plugin finden, um das LCP-Bild (und oft die ersten Bilder auf der Seite) vom Lazy-Loading auszunehmen. Dies ist ein so häufiger Fehler, dass wir einen eigenen Artikel zur Behebung von lazy-geladenen LCP-Bildern haben.

Auf einem JS-Framework:

• Server-Side Rendering (SSR) verwenden: Dies ist oft die wirkungsvollste Lösung. Eine standardmäßig Client-Side gerenderte (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 <img>-Tags, sodass der Browser es sofort erkennen kann.
• Framework-spezifische Bild-Komponenten verwenden: Frameworks wie Next.js bieten eine Bild-Komponente mit einem priority-Prop. Die Verwendung des Priority-Props wendet automatisch fetchpriority="high" und andere Optimierungen auf Ihr LCP-Bild an.

3. Resource Load Duration verringern

Sicherzustellen, dass Ihre LCP-Ressource so klein wie möglich ist, bleibt ein wesentlicher Teil des Prozesses. Diese Phase dreht sich darum, wie lange es dauert, die LCP-Ressourcendatei über das Netzwerk herunterzuladen. Für einen vollständigen Leitfaden zu Bildoptimierungstechniken siehe unseren Artikel zur Optimierung des LCP-Bildes und speziell zu Resource Load Duration.

Universelle Load-Time-Lösungen

• Dateigröße mit modernen Formaten und responsiven Bildern reduzieren: Der direkteste Weg, die Download-Zeit zu verkürzen, ist die Datei kleiner zu machen. Für Bilder bedeutet das die Verwendung moderner, hocheffizienter Formate wie AVIF oder WebP. Sie müssen außerdem responsive Bilder mit dem <picture>-Element oder den srcset- und sizes-Attributen ausliefern. Dies stellt sicher, dass ein Benutzer auf einem Mobilgerät ein Bild erhält, das für seinen kleineren Bildschirm angemessen dimensioniert ist, anstatt gezwungen zu sein, ein riesiges Desktop-Bild herunterzuladen. Ein 400 Pixel breiter Mobilbildschirm braucht einfach kein 2000 Pixel breites Bild. Für textbasierte LCPs stellen Sie sicher, dass Ihre Schriften im effizienten WOFF2-Format vorliegen und auf nicht verwendete Zeichen reduziert sind.
• Netzwerk-Konkurrenz reduzieren: Die LCP-Ressource muss um die begrenzte Netzwerkbandbreite des Benutzers konkurrieren. Das Aufschieben nicht-kritischer Ressourcen wie Analytics-Scripts oder CSS für Inhalte unterhalb des sichtbaren Bereichs gibt Bandbreite frei, damit der Browser sich auf den schnelleren Download der LCP-Ressource konzentrieren kann.
• Kritische Ressourcen auf Ihrer Hauptdomain hosten: Vermeiden Sie es, Ihre LCP-Ressource von einer anderen Domain zu laden, wenn möglich. Das Aufbauen einer neuen Verbindung zu einem anderen Server fügt zeitaufwändige DNS-Lookups und Handshakes hinzu.

Plattformspezifische Load-Time-Lösungen

Auf WordPress:

• Ein Bildoptimierungs-Plugin verwenden: Tools wie ShortPixel oder Smush können Bilder beim Upload automatisch komprimieren, in moderne Formate wie WebP/AVIF konvertieren und responsive srcset-Größen generieren.
• Bilder manuell skalieren: Skalieren Sie Ihre Bilder vor dem Upload so, dass sie nicht größer sind, als sie sein müssen. Laden Sie kein 4000px breites Bild für einen Bereich hoch, der auf den größten Bildschirmen nur 1200px breit ist.

Auf einem JS-Framework:

• Ein Image-CDN verwenden: Dies ist eine leistungsstarke Lösung. Dienste wie Cloudinary, Imgix oder Akamai's 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.
• Build-Tools nutzen: 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 optimieren als Teil des Build-Prozesses.

4. Element Render Delay verkürzen

Die Ressource ist fertig heruntergeladen, aber sie ist noch nicht auf dem Bildschirm. Das bedeutet, der Haupt-Thread des Browsers ist mit anderen Aufgaben beschäftigt und kann das Element nicht zeichnen. Dies ist ein weiterer sehr häufiger und bedeutender Engpass. Für den vollständigen Leitfaden lesen Sie unseren Leitfaden zu Element Render Delay.

Universelle Render-Delay-Lösungen

• Nicht benötigtes JavaScript aufschieben oder entfernen: Jedes JS, das nicht wesentlich für das Rendern des initialen, sichtbaren Teils der Seite ist, sollte mit den defer- oder async-Attributen aufgeschoben werden.
• Critical CSS verwenden: Ein großes, renderblockendes Stylesheet kann das Rendern verzögern. Die Critical-CSS-Technik beinhaltet das Extrahieren des minimalen CSS, das zum Stylen des Above-the-fold-Inhalts benötigt wird, das Inlining im <head> und das Laden der restlichen Styles asynchron.
• Lange Tasks aufbrechen: Ein lang laufendes Script kann den Haupt-Thread für einen längeren Zeitraum blockieren und das Rendern verhindern. Dies ist auch eine Hauptursache für schlechte Interaction to Next Paint (INP). Teilen Sie Ihren Code in kleinere, asynchrone Abschnitte auf, die dem Haupt-Thread die Kontrolle zurückgeben.

Plattformspezifische Render-Delay-Lösungen

Auf WordPress:

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

Auf einem JS-Framework:

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

Fortgeschritten: LCP für nachfolgende Navigationen optimieren

Den initialen LCP zu verbessern ist wichtig, aber Sie können das Browsen auf Ihrer Website blitzschnell wirken lassen, indem Sie für nachfolgende Seitenladungen optimieren.

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

Der bfcache ist eine Browser-Optimierung, die einen vollständigen Snapshot einer Seite im Speicher ablegt, wenn ein Benutzer weg navigiert. Wenn er den Zurück-Button klickt, kann die Seite sofort wiederhergestellt werden, was zu einem nahezu null LCP führt. Viele Seiten sind für diesen Cache nicht berechtigt aufgrund von Dingen wie unload-Event-Listenern. Verwenden Sie das Lighthouse-"bfcache"-Audit, um Ihre Seiten zu testen und alle blockierenden Funktionen zu entfernen.

Die Speculation Rules API für Prerendering verwenden

Die Speculation Rules API ermöglicht es Ihnen, dem Browser deklarativ mitzuteilen, zu welchen Seiten ein Benutzer wahrscheinlich als nächstes navigieren wird. Der Browser kann diese Seiten dann im Hintergrund abrufen und vor-rendern. Wenn der Benutzer auf einen Link zu einer vorgerenderten Seite klickt, ist die Navigation sofort, was zu einem nahezu null LCP führt. 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, auf der aktuellen Seite nach Links zu Produktseiten zu suchen und sie vorzurendern, wenn ein Benutzer mit der Maus darüber fährt.

Arbeiten Sie die vier Phasen der Reihe nach durch. Beheben Sie zuerst den größten Engpass, messen Sie erneut, wiederholen Sie.

Nächste Schritte: Jede LCP-Phase im Detail

Jede LCP-Phase hat ihren eigenen Leitfaden:

• Das LCP-Bild optimieren: Ein vollständiger Leitfaden zur Bildformatauswahl, responsiven Bildern, Preloading und häufigen Fehlern bei der Bildoptimierung.
• Resource Load Delay: Wie Sie sicherstellen, dass der Browser Ihre LCP-Ressource so früh wie möglich entdeckt, mit preload, fetchpriority und korrekter HTML-Struktur.
• Resource Load Duration: Wie Sie die Download-Zeit für Ihre LCP-Ressource durch Dateikomprimierung, moderne Formate, CDN-Konfiguration und Netzwerkoptimierung reduzieren.
• Element Render Delay: Wie Sie den Haupt-Thread des Browsers freimachen, damit er das LCP-Element sofort nach dem Download zeichnen kann, einschließlich Critical CSS, JavaScript-Aufschiebung und content-visibility.