Largest Contentful Paint (LCP) im SEO

TL;DR — Largest Contentful Paint (LCP) misst, wie lange es dauert, bis das größte Element auf dem Bildschirm – normalerweise ein Hero-Bild oder ein großer Textblock – nach einem Klick auf Ihre Seite angezeigt wird. Unter 2,5 Sekunden ist gut. Es ist eine der drei Core Web Vitals von Google und diejenige, mit der die meisten Websites kämpfen.

Was LCP ist

Der erste Eindruck, den Besucher von Ihrer Website haben, ist, wie schnell sie scheint zu laden. LCP versucht, dem eine Zahl zuzuordnen. Es misst die Zeit, die benötigt wird, um das einzelne größte sichtbare Element im Viewport zu laden – den Teil der Seite, den Sie sehen können, ohne zu scrollen.

Dieses „größte Element“ ist normalerweise eines von zwei Dingen:

• Ein großes Bild – ein Hero-Banner, ein Produktfoto, ein Beitragsbild.
• Ein großer Textblock – häufig auf Artikelseiten, die nicht mit einem Bild beginnen.

LCP ist der Moment, in dem dieses Element fertig gerendert wird, gemessen ab dem Start des Seitenladens. Je niedriger die Zahl, desto schneller fühlt sich Ihre Seite an.

Die Bewertung

Google unterteilt LCP in drei Kategorien:

• Gut: 2,5 Sekunden oder weniger
• Verbesserungsbedürftig: 2,5 bis 4 Sekunden
• Schlecht: mehr als 4 Sekunden

Sie zielen auf diese 2,5-Sekunden-Marke ab. Und sie wird anhand echter Besucher Ihrer Website bewertet, nicht anhand eines einmaligen Tests – es ist also die Erfahrung, die Ihr tatsächliches Publikum auf seinen tatsächlichen Geräten und Verbindungen macht.

Warum es schwierig sein kann

LCP ist die Core Web Vital, mit der Menschen am meisten kämpfen. Das liegt daran, dass es die meisten beweglichen Teile hat: Ihr Server muss antworten, der Browser muss das Bild finden und herunterladen, und dann muss er es tatsächlich rendern. Eine Verlangsamung bei einem dieser Schritte treibt die gesamte Zahl nach oben. Ihre Bilder zu komprimieren ist ein häufiger erster Versuch – und es hilft manchmal –, aber es ist oft nicht der eigentliche Engpass.

Es ist auch auf mobilen Geräten schwieriger als auf dem Desktop, weil Telefone langsamere Verbindungen und weniger Rechenleistung haben.

Was zuerst zu tun ist

Drei schnelle Maßnahmen, welche die häufigsten Fehler beheben:

1. Lazy-Loaden Sie Ihr Hauptbild nicht. „Lazy Loading“ weist den Browser an, mit dem Abrufen eines Bildes zu warten. Das ist großartig für Inhalte weit unten auf der Seite – aber wenn Sie es bei Ihrem Hero-Bild tun, verzögern Sie absichtlich das wichtigste Element auf dem Bildschirm. Evidence for this claim An LCP image should not be lazy-loaded, and reducing resource load delay is a primary LCP optimization. Scope: web.dev guidance for image-based LCP elements. Confidence: high · Verified: 2026-07-14 web.dev: Optimize LCP
2. Teilen Sie dem Browser mit, dass das Hauptbild wichtig ist – es gibt ein Attribut (fetchpriority="high"), das genau das tut. Setzen Sie es auf das eine Bild, das tatsächlich Ihr LCP-Kandidat ist; es auf mehrere Bilder zu setzen, verwässert das Signal.
3. Beschleunigen Sie Ihren Server. Wenn Ihr Server langsam antwortet, nützt alles andere, was Sie tun, wenig.

Möchten Sie das vollständige mentale Modell – die vier Unterteile von LCP, wie Sie Ihr LCP-Element finden, die Render- und Schriftart-Themen und wie viel das tatsächlich für Rankings bedeutet? Wechseln Sie zum Erweitert-Tab.

TL;DR — LCP ist die Renderzeit des größten sichtbaren Bildes oder Textblocks im Viewport, relativ zum Start des Seitenladens. Gut ist ≤ 2,5 s beim 75. Perzentil der echten Nutzer (nach Gerät getrennt); 2,5–4 s erfordert Arbeit, über 4 s ist schlecht. Es ist eine der drei Core Web Vitals und gliedert sich in vier Unterteile – TTFB, Ressourcenladeverzögerung, Ressourcenladedauer, Element-Renderverzögerung – wobei TTFB und Ladedauer normalerweise dominieren (Richtlinien, keine festen Anteile – diagnostizieren Sie Ihre eigene Seite). Die wichtigsten Korrekturen: Lazy-Loaden Sie das LCP-Bild niemals, fügen Sie fetchpriority="high" auf dem tatsächlichen Kandidaten hinzu, laden Sie es vor, wenn es nicht im HTML ist, entfernen Sie render-blockierendes CSS/JS und beheben Sie TTFB. Es ist eine Feld-Metrik – Labor- Tools approximieren sie nur – und das LCP-Element kann sich während des Ladens ändern. Google bestätigt, dass Core Web Vitals in Ranking-Systeme einfließen, veröffentlicht aber kein genaues LCP- Gewicht und nennt es keinen Tiebreaker; Inhaltsrelevanz dominiert weiterhin.

Was LCP tatsächlich misst

LCP gibt die Renderzeit des größten im Viewport sichtbaren Bild- oder Textblocks an, gemessen relativ zum Zeitpunkt, zu dem der Nutzer die Seite erstmals aufgerufen hat. Googles eigene Einordnung: Es ist der am nächsten kommende standardisierte Proxy für wann der Hauptinhalt für den Nutzer erscheint. Es ersetzte frühere, unschärfere Metriken wie First Meaningful Paint und Speed Index.

Ein paar Dinge, über die man sofort stolpert:

• Es ist nicht die “Seitenladezeit”. Eine Seite kann alle Ressourcen geladen haben und trotzdem einen langsamen LCP aufweisen, wenn das Rendern des größten Elements blockiert war. Bei LCP geht es um dieses eine Element, nicht um die gesamte Seite.
• Es ist nicht dasselbe wie FCP. First Contentful Paint feuert, wenn irgendein Inhalt zuerst erscheint; LCP wartet auf das größte Element. Eine Seite kann ein schnelles FCP haben (die Navigationsleiste wird gemalt) und ein langsames LCP (das Hero-Bild lädt spät).
• Es ist eine dynamische Metrik. Der Browser sendet jedes Mal einen neuen LCP-Kandidaten, wenn ein größeres Element sichtbar wird. Der letzte Eintrag vor der Interaktion des Nutzers (Tippen, Scrollen, Tastendruck) oder dem Entladen der Seite ist der Wert, der zählt — Interaktion ändert oft, was sichtbar ist, daher endet die Berichterstattung dort. Ein Kandidat, der später aus dem DOM entfernt wird, löscht seinen eigenen Eintrag nicht — er bleibt das gemeldete Element, es sei denn, ein noch größeres wird vor dem Ende der Berichterstattung gerendert.

Die Schwellenwerte — und warum 2,5 Sekunden

Bewertet am 75. Perzentil der realen Nutzer-Seitenaufrufe, segmentiert nach Gerätetyp. Drei von vier Besuchen müssen also unter 2,5 s liegen, damit eine Origin besteht.

Warum genau 2,5? Googles Schwellenwert-Methodik stützte sich auf zwei Dinge: Forschung zur menschlichen Wahrnehmung, die auf etwa 1–3 Sekunden als den Bereich hinweist, der sich “sofort” anfühlt, und CrUX-Erreichbarkeitsdaten, die zeigten, dass 2,5 s für gut optimierte Websites konsistent erreichbar waren, ohne trivial einfach zu sein. Engere Ziele wie 1,5 s oder 2,0 s waren nicht über genügend Origins hinweg konsistent erreichbar, daher schafften sie es nicht.

Was als LCP-Element zählt

Die für LCP berücksichtigten Elementtypen:

• <img>-Elemente
• <image>-Elemente innerhalb eines <svg>
• <video>-Elemente (die Ladezeit des Posterbilds oder das erste Bild, je nachdem, was früher ist)
• Ein Element mit einem Hintergrundbild, das über die CSS-Funktion url() geladen wird
• Blockelemente, die Textknoten oder andere Inline-Textkinder enthalten

Die gemeldete Größe ist das, was tatsächlich im Viewport sichtbar ist — abgeschnittene oder herausgescrollte Teile zählen nicht, und bei Bildern ist es die sichtbare Größe oder die intrinsische Größe, je nachdem, was kleiner ist. Ränder, Innenabstände und Rahmen werden ignoriert. Eine Handvoll Elemente wird durch Heuristiken ausgeschlossen: alles mit opacity: 0, Elemente, die den gesamten Viewport abdecken (als Hintergründe behandelt), und Platzhalterbilder mit geringer Entropie.

Bei etwa drei Viertel der Seiten ist ein Bild das LCP-Element — daher ist Bildarbeit normalerweise der richtige erste Schritt. Aber nicht immer, und nicht immer Kompression (dazu gleich mehr). Der verbleibende Teil sind Text-LCPs, bei denen der Hebel völlig anders ist: Es geht um Schriftarten laden, nicht um Bildgewicht.

Die vier Unterteile — der Teil, den die meisten Artikel überspringen

Das ist das Framework, mit dem ich jede LCP-Diagnose beginnen würde. web.dev unterteilt LCP in vier aufeinanderfolgende Unterteile:

1. Time to First Byte (TTFB) — vom Beginn des Ladens der Seite bis der Browser das erste Byte HTML empfängt. Typischer Anteil: ~40 % der gesamten LCP.
2. Ressourcenladeverzögerung — die Lücke zwischen TTFB und dem Beginn des Ladens der LCP-Ressource durch den Browser. Dies ist die Entdeckungszeit. Typischer Anteil: unter 10 %.
3. Ressourcenladedauer — wie lange die LCP-Ressource selbst zum Herunterladen benötigt. Typischer Anteil: ~40 %.
4. Element-Renderverzögerung — vom Abschluss des Ladens der Ressource bis das Element tatsächlich gemalt wird. Typischer Anteil: unter 10 %.

Das Prinzip hinter der Tabelle: Die überwiegende Mehrheit der LCP-Zeit sollte für das Laden des HTML-Dokuments und der LCP-Ressource aufgewendet werden. Jeder Abschnitt, in dem keines von beiden geladen wird, ist eine Gelegenheit zur Verbesserung.

web.dev macht deutlich, dass diese Prozentsätze Richtwerte und keine strengen Regeln sind – machen Sie daraus keine absoluten Sekundenziele und zwingen Sie nicht jede Seite, der Aufteilung zu entsprechen. Sie sind nur relativ zueinander aussagekräftig, und wenn Ihre LCP bereits konstant unter 2,5 Sekunden liegt, spielen die relativen Anteile überhaupt keine Rolle. Nutzen Sie die Tabelle, um zu erkennen, welche Teilkomponente auf Ihrer Seite einen übermäßigen Anteil ausmacht, und beheben Sie dann genau diese – nicht, um eine exakte 40/10/40/10-Aufteilung zu erreichen.

Und hier ist der Punkt, der die gängige Annahme umstößt: Seit Februar 2025 sind diese vier Teilkomponenten in der CrUX-API für Bild-LCPs verfügbar, und die Analyse der Chrome-Teams von HTTP-Archive-Daten ergab, dass die Bilddownloadzeit oft der kleinste Teil der LCP-Zeit war. Mit anderen Worten: „Komprimieren Sie einfach meine Bilder“ behebt häufig die falsche Teilkomponente. TTFB und Discovery-Verzögerung sind oft die größeren Hebel.

So finden Sie Ihr LCP-Element

Bevor Sie etwas optimieren, finden Sie heraus, welches Element Ihre LCP ist und welche Teilkomponente den Engpass darstellt:

• PageSpeed Insights – der Abschnitt „Diagnose“ kennzeichnet das LCP-Element, und die Registerkarte mit Felddaten zeigt Ihre Bewertung durch echte Nutzer.
• Chrome DevTools – das Bedienfeld „Leistung“ markiert den LCP-Knoten auf der Zeitleiste.
• Die web-vitals-JS-Bibliothek – protokollieren Sie LCP (und das Element) aus Ihrem eigenen Monitoring echter Nutzer.

So verbessern Sie LCP

Ordnen Sie jede Korrektur der Teilkomponente zu, die sie betrifft:

Beheben Sie die Verzögerung beim Ressourcenladen (Discovery). Dies ist die wirkungsvollste und am häufigsten fehlerhafte.

• Laden Sie Ihr LCP-Bild niemals lazy. loading="lazy" auf dem LCP-Element fügt immer unnötige Ladeverzögerung hinzu. Reservieren Sie Lazy Loading für Bilder unterhalb des Falzes.
• Fügen Sie fetchpriority="high" zum wahrscheinlichen LCP-Bild hinzu, damit der Browser es früh mit hoher Priorität abruft.
• Preloaden Sie es mit <link rel="preload">, wenn das Bild nicht im initialen HTML auffindbar ist – zum Beispiel, wenn es über CSS oder JavaScript geladen wird. Das Laden des Hero-Bilds über JS ist ein Anti-Pattern, gerade weil es die URL vor dem Preload-Scanner des Browsers verbirgt.
• Hosten Sie kritische Ressourcen auf derselben Origin, damit der Browser keine zusätzliche Verbindungseinrichtung zahlt.

Preload und fetchpriority lösen unterschiedliche Probleme, also greifen Sie nicht aus Gewohnheit zu beiden. Preload macht eine Ressource verfügbar, die der Preload-Scanner des Browsers sonst spät entdecken würde (z. B. ein über JS oder CSS geladenes Bild); fetchpriority ändert die Abrufpriorität einer Ressource, die der Browser bereits gefunden hat. Wenn Discovery und Priorität bereits korrekt sind – das Bild ist ein einfaches <img> im initialen HTML –, kann das Hinzufügen von beidem wenig bewirken, abgesehen von zusätzlichen Anfragen. Überprüfen Sie ein Trace, wenden Sie das an, das zum tatsächlichen Problem passt, und bestätigen Sie, dass sich die Feldnummer bewegt hat.

Beheben Sie die Verzögerung beim Rendern des Elements.

• Reduzieren oder inline Sie render-blockierendes CSS; verschieben Sie nicht kritische Stile.
• Vermeiden Sie synchrone Skripte im <head>.
• Bevorzugen Sie serverseitiges Rendering oder statische Generierung, damit das Markup bereit zum Rendern ankommt, und unterbrechen Sie lange Main-Thread-Aufgaben.

Reduzieren Sie die Dauer des Ressourcenladens.

• Moderne Bildformate (WebP, AVIF), sinnvolle Komprimierung und ein CDN.
• Effizientes Cache-Control. Und ignorieren Sie Netzwerküberlastung nicht – das Lazy-Loading der anderen Bilder unterhalb des Falzes kann Bandbreite freigeben, sodass das LCP-Bild früher ankommt.

Reduzieren Sie TTFB.

• Minimieren Sie Weiterleitungen, entfernen Sie unnötige eindeutige URL-Parameter und optimieren Sie die Serverantwortzeit. Beachten Sie, dass LCP jegliche Entladezeit der vorherigen Seite, Verbindungseinrichtung und Weiterleitungszeit einschließt – all das fließt in TTFB ein.

Sonderfall: textbasiertes LCP. Wenn das größte Element Text ist, liegt der kritische Pfad im Schriftartenladen, nicht im Bildgewicht. font-display: optional oder Systemschriftarten eliminieren schriftartbedingte Renderverzögerungen; font-display: swap ohne Vorabladen der Schriftdatei kann sie einführen.

Labor vs. Feld – dieser Unterschied ist wichtig

LCP ist grundsätzlich eine Feld-Metrik. Google bewertet sie anhand realer Nutzer über CrUX, dargestellt im Feld-Tab von PageSpeed Insights und im Core Web Vitals-Bericht der Search Console. Diese Felddaten fließen in das Ranking ein.

Labortools – Lighthouse, Chrome DevTools, WebPageTest – nähern sich ihr nur annähernd unter simulierten Bedingungen an, und sie verwenden nicht einmal dieselbe Bewertung. Lighthouse wendet strengere Desktop-Schwellenwerte an (Gut ≤ 1,2 s) als der Feldstandard (≤ 2,5 s). Ein bestehender Lighthouse-Score garantiert also keinen bestehenden CrUX-Score und umgekehrt. Verwenden Sie Labortools zum Debuggen und Reproduzieren; vertrauen Sie für das eigentliche Urteil den Felddaten.

Es gibt einen zweiten Grund, warum Labor- und Feldwerte voneinander abweichen können, den es zu kennen lohnt, damit eine ungewöhnliche Messung Sie nicht auf die Jagd nach einem Phantomfehler schickt: Die aktuelle LargestContentfulPaint-Browser-API (noch ein W3C-Arbeitsentwurf) ist auf einen einzelnen Dokumentladevorgang beschränkt. Sie setzt sich selbst nicht bei Back/Forward-Cache (bfcache)-Wiederherstellungen oder SPA-Navigationen im selben Dokument zurück, und Seiten, die im Hintergrund starten – Hintergrund-Tabs, vorgerenderte Seiten – können überhöhte Werte melden, da die Zeitmessung vom Laden an läuft und nicht von dem Zeitpunkt, an dem die Seite tatsächlich sichtbar wurde. Der Meldealgorithmus stoppt auch bei qualifizierender Nutzereingabe. Wenn ein Nutzer also interagiert, bevor Ihre Hauptinhalte angezeigt werden, erfasst LCP dies nicht. Nichts davon ändert die obige Schwellenwerttabelle; es erklärt, warum die Zahl einer bestimmten Sitzung falsch aussehen kann, wenn die zugrunde liegende Navigation kein einfacher erster Ladevorgang ist.

Beeinflusst LCP das Ranking?

Ja, in dem Sinne, dass Google bestätigt, dass Core Web Vitals in seine Ranking-Systeme einfließen und empfiehlt, gute Werte zu erzielen. Die aktuelle Search-Central-Dokumentation veröffentlicht jedoch kein genaues LCP-Gewicht und beschreibt es nicht als Tiebreaker – Googles eigene Rahmung ist, dass die Seitenerfahrung “can contribute to success in Search” (Übersetzung) „zum Erfolg in der Suche beitragen kann“, und zwar für Suchanfragen, bei denen mehrere Seiten bereits vergleichbare, relevante Inhalte bieten, und dass ein guter Score keinen Ranking-Boost garantiert. Inhaltsrelevanz und -qualität dominieren weiterhin. Optimieren Sie LCP, weil eine sich schneller anfühlende Seite für Nutzer (und Conversions) wirklich besser ist – nicht, weil der Mechanismus als Ranking-Tiebreaker dokumentiert ist, denn das ist er nicht.

Ein paar Realitäten aus den Daten: Von den Core Web Vitals ist LCP diejenige, die Websites am schwersten zu verbessern finden, und sie ist auf Mobilgeräten deutlich schwieriger als auf dem Desktop – langsamere CPUs und Verbindungen. Bei 3G und langsamer kann die 2,5-s-Schwelle fast unmöglich zu erreichen erscheinen.

Wo dies einzuordnen ist

LCP ist eines der drei Core Web Vitals, neben Interaction to Next Paint und Cumulative Layout Shift. Sein erster Unterteil, Time to First Byte, ist eine eigene diagnostische Metrik, und First Contentful Paint liegt direkt daneben auf der Ladezeitleiste. Sie sehen alle diese in PageSpeed Insights, Lighthouse und dem Chrome User Experience Report (CrUX). Jede davon ist in diesem Cluster ein eigenes Deep Dive.

KI-Zusammenfassung

Eine komprimierte Darstellung der erweiterten Version:

• LCP = Renderzeit des größten sichtbaren Bild- oder Textblocks, relativ zum Start der Seitenladung. Es ist der engste standardisierte Proxy für „Wann erscheint der Hauptinhalt?“.
• Schwellenwerte: Gut ≤ 2,5 s, Verbesserungsbedarf 2,5–4 s, Schlecht > 4 s – beim 75. Perzentil der echten Nutzer, aufgeteilt nach Gerät. Es ist eine der drei Core Web Vitals.
• Nicht Seitenladezeit, nicht FCP. FCP = erster Pixel beliebigen Inhalts; LCP = das größte Element. LCP ist auch dynamisch – der größte Kandidat kann sich während des Ladens ändern; der letzte vor der Nutzerinteraktion zählt.
• LCP-Elemente: <img>, <image> in <svg>, <video>-Poster, CSS background-image: url() oder ein Block-Level-Textelement. ~3 von 4 Seiten haben ein Bild-LCP; der Rest sind Text (wo Schriftarten, nicht Bildgewicht, der Hebel sind).
• Vier Unterteile: TTFB (~40 %), Ressourcenladeverzögerung (<10 %), Ressourcenlade- dauer (~40 %), Element-Renderverzögerung (<10 %) – web.dev nennt diese Richtlinien, keine festen Anteile; diagnostizieren Sie pro Seite, statt eine exakte Aufteilung zu verfolgen. CrUX-2025-Daten: Bilddownload ist oft der kleinste Teil – also behebt „Bilder einfach komprimieren“ oft das Falsche.
• Top-Fixes: LCP-Bild niemals lazy-loaden; fetchpriority="high" auf den tatsächlichen Kandidaten setzen; vorladen, wenn es nicht im HTML ist (Preload und fetchpriority lösen verschiedene Probleme – nicht aus Gewohnheit beides verwenden); renderblockierendes CSS/JS reduzieren; TTFB senken.
• Feld, nicht Labor. CrUX/Search Console beeinflussen Rankings; Lighthouse approximiert nur und verwendet strengere Desktop-Schwellenwerte (≤ 1,2 s). Die aktuelle LargestContentfulPaint-API ist auf Dokumentladungen beschränkt und setzt sich selbst nicht für bfcache-Wiederherstellungen oder Same-Document-SPA-Navigationen zurück.
• Rankings: Google bestätigt CWV-Feed-Ranking-Systeme, veröffentlicht aber kein exaktes LCP-Gewicht und nennt es keinen Tiebreaker; Inhaltsrelevanz dominiert weiterhin. Schwerste CWV zu verbessern und schwieriger auf Mobilgeräten.

Offizielle Dokumentation

Primärquellen-Leitfaden von Googles Chrome- und Search-Teams.

web.dev (Chrome-Team)

• Largest Contentful Paint (LCP) – die kanonische Definition: was als LCP-Element zählt, wie die Größe berechnet wird, wann die Berichterstattung stoppt und die Mess-APIs.
• Largest Contentful Paint optimieren – das Framework der vier Unterteile und das vollständige Optimierungs-Playbook.
• Core Web Vitals – wo LCP unter den drei Core Web Vitals steht.
• Wie die Schwellenwerte der Core-Web-Vitals-Metriken festgelegt wurden – die Forschung und Erreichbarkeitsdaten hinter der 2,5-s-Marke.

Chrome for Developers

• LCP-Bildunterteile und RTT jetzt in CrUX verfügbar – die Felddaten-Veröffentlichung vom Februar 2025 der vier Unterteile (nur Bild-LCPs).
• Largest Contentful Paint in Lighthouse – die Labormetrik und ihre gerätespezifische Bewertung.

Google Search Central

• Core Web Vitals und Google-Suchergebnisse verstehen – wie Core Web Vitals in die Suche einfließen.

Zitate aus der Quelle

Aussagen aus Googles Dokumentation und Team, die auf dem Rekord basieren. Jeder Link ist ein Deep Link, der zur zitierten Passage springt.

web.dev – Definition und Verhalten (Philip Walton & Barry Pollard, Google)

• “LCP reports the render time of the largest image, text block, or video visible in the viewport, measured relative to when the user first navigated to the page.” (Übersetzung) „LCP meldet die Renderzeit des größten Bildes, Textblocks oder Videos, das im Viewport sichtbar ist, gemessen relativ zum Zeitpunkt der ersten Navigation des Nutzers zur Seite.“ Zum Zitat springen
• Zum Messgegenstand: “LCP doesn’t consider margins, paddings, or borders applied using CSS.” (Übersetzung) „LCP berücksichtigt keine über CSS angewendeten Ränder, Innenabstände oder Rahmen.“ Zum Zitat springen
• Zum Ende der Berichterstattung: “The browser will stop reporting new entries as soon as the user interacts with the page (via a tap, scroll, or keypress), as user interaction often changes what’s visible to the user.” (Übersetzung) „Der Browser stoppt die Meldung neuer Einträge, sobald der Nutzer mit der Seite interagiert (per Tippen, Scrollen oder Tastendruck), da Nutzerinteraktion häufig ändert, was für den Nutzer sichtbar ist.“ Zum Zitat springen
• Zum Umfang der Zeitmessung: “It is important to note that LCP includes any unload time from the previous page, connection set up time, redirect time, and other Time To First Byte (TTFB) delays.” (Übersetzung) „Es ist wichtig zu beachten, dass LCP jegliche Entladezeit der vorherigen Seite, Verbindungsaufbauzeit, Weiterleitungszeit und andere Time To First Byte (TTFB)-Verzögerungen einschließt.“ Zum Zitat springen

web.dev — Optimierung (Philip Walton & Barry Pollard, Google)

• Die wichtigste Regel zum Lazy Loading: “Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay.” (Übersetzung) „Laden Sie Ihr LCP-Bild niemals lazy, da dies immer zu unnötiger Verzögerung beim Laden von Ressourcen führt.“ Zum Zitat springen
• Das Prinzip hinter den Teilzielen: “The vast majority of the LCP time should be spent loading the HTML document and LCP source.” (Übersetzung) „Der Großteil der LCP-Zeit sollte für das Laden des HTML-Dokuments und der LCP-Quelle aufgewendet werden.“ Zum Zitat springen

Google Search Central — Rankings

• “We highly recommend site owners achieve good Core Web Vitals for success with Search and to ensure a great user experience generally.” (Übersetzung) „Wir empfehlen Website-Betreibern dringend, gute Core Web Vitals zu erreichen, um im Search erfolgreich zu sein und generell eine großartige Nutzererfahrung zu gewährleisten.“ (Weitergeleitet aus dem Search Central Core Web Vitals-Dokument; vor endgültiger Behandlung gegen die Live-Seite prüfen.)

LCP-Fix-Checkliste

Gehen Sie diese Punkte grob von oben nach unten durch — zuerst Discovery und TTFB, da dies in der Regel die größten und am häufigsten fehlerhaften Stellschrauben sind.

• Das tatsächliche LCP-Element gefunden (PageSpeed Insights Diagnostics, DevTools Performance-Panel oder die web-vitals-Bibliothek) – nicht blind optimieren.
• Die vier Unterteile geprüft, um zu sehen, welcher der Engpass ist, bevor etwas geändert wird.
• LCP-Bild ist nicht loading="lazy" (Lazy Loading gehört nur unterhalb des Falzes).
• LCP-Bild hat fetchpriority="high".
• LCP-Bild ist im initialen HTML auffindbar – oder vorab geladen (<link rel="preload">), wenn es über CSS/JS geladen wird.
• Hero-Bild wird nicht über JavaScript geladen (versteckt es vor dem Preload-Scanner).
• Render-blockierendes CSS minimiert/inline eingebunden; nicht kritische Styles aufgeschoben.
• Keine synchronen Skripte im <head>; lange Tasks aufgeteilt.
• Modernes Bildformat (WebP/AVIF), sinnvolle Komprimierung, über ein CDN mit gutem Cache-Control ausgeliefert.
• Bilder unterhalb des Falzes lazy-geladen, damit sie nicht um Bandbreite mit dem LCP-Bild konkurrieren.
• TTFB adressiert: Redirects minimiert, Serverantwort optimiert, unnötige URL-Parameter entfernt.
• Text-LCP? font-display: optional oder Systemschriften verwenden und jede ausgetauschte Schriftdatei vorab laden.
• Gegen Felddaten (CrUX / Search Console) verifiziert, nicht nur gegen einen Lighthouse-Labortest.

LCP-Spickzettel

Schwellenwerte (75. Perzentil der echten Nutzer, nach Gerät)

Die vier Unterteile – was sie sind und die Lösung

Was das LCP-Element sein kann

• <img> · <image> innerhalb <svg> · <video>-Poster · CSS background-image: url() · Block-Level-Text

Durch Heuristik ausgeschlossen: opacity: 0, „Hintergrund“-Elemente über die volle Viewport-Höhe, Platzhalter mit geringer Entropie.

Schnelle Fakten

• LCP ist eine Feld-Metrik (CrUX / Search Console steuern Rankings); Lighthouse nähert nur an und verwendet einen strengeren Desktop-Gut-Wert von ≤ 1,2 s.
• Das LCP-Element kann sich während des Ladens ändern; der letzte Kandidat vor der Nutzerinteraktion zählt.
• Etwa 3 von 4 Seiten haben ein Bild-LCP; der Rest ist Text (Schriften sind der Hebel).
• Die Downloadzeit des Bildes ist oft der kleinste Unterteil – Komprimierung ist nicht immer die Antwort.
• LCP ≠ FCP; LCP ≠ gesamte Seitenladezeit.

Tools zum Messen und Beheben von LCP

Felddaten (was Rankings verwenden)

• PageSpeed Insights – Feld-Tab zeigt Ihre CrUX-Daten echter Nutzer; Diagnostics kennzeichnet das LCP-Element.
• Search Console – Core Web Vitals-Bericht – LCP-Status über Ihre URLs, gruppiert, auf Basis echter Nutzerdaten.
• Chrome User Experience Report (CrUX) – der zugrunde liegende Felddatensatz; ab Februar 2025 enthält er die vier Bild-LCP-Unterteile über die API.
• web-vitals-JS-Bibliothek – LCP und das LCP-Element aus Ihrem eigenen Monitoring echter Nutzer protokollieren.

Labordaten (zum Debuggen)

• Lighthouse – schnelles Labor-LCP und eine Liste von Optimierungsmöglichkeiten (denken Sie daran: strengere Desktop-Schwellenwerte als im Feld).
• Chrome DevTools – Performance-Panel – markiert den LCP-Knoten und die vollständige Render-Zeitleiste.
• WebPageTest – Wasserfallansicht, um herauszufinden, welcher Unterteil langsam ist.

SEO-Crawler

• Ahrefs Site Audit – deckt Core Web Vitals / Leistungsprobleme über die gesamte Website im großen Maßstab auf.

Wie die Tools selbst bewertet werden

Ein Live-Beispiel der Metrik, die diese Seite beschreibt – bekannte Seitenleistungs- und Monitoring-Dienste, bewertet nach ihrem eigenen mobilen LCP echter Nutzer (Chrome UX Report-Felddaten):

LCP-Fixes, die das falsche Problem angehen

Lazy-Loading des Hero-Bilds

loading="lazy" verzögert die Erkennung eines Bildes oberhalb der Falz, das wahrscheinlich zum LCP wird. Laden Sie es eager, geben Sie dem wahrscheinlichen Kandidaten fetchpriority="high" und reservieren Sie Lazy-Loading für Bilder unterhalb der Falz.

Komprimieren jedes Bildes, bevor der Engpass gefunden wird

Die Bilddownloaddauer ist nur einer von vier LCP-Unterteilen und kann der kleinste sein. Identifizieren Sie das LCP-Element und prüfen Sie TTFB, Ladeverzögerung, Ladedauer und Renderverzögerung, bevor Sie einen Fix wählen.

Laden des Hero-Bilds über JavaScript

Ein per JS eingefügtes Bild verbirgt seine URL vor dem Preload-Scanner des Browsers und erzeugt eine Ressourcenladeverzögerung. Platzieren Sie das Bild im initialen HTML oder laden Sie es vor, wenn CSS oder JS es besitzen müssen.

Sieg aus einem einzigen Lighthouse-Lauf erklären

Lighthouse ist eine kontrollierte Diagnose, während das CWV-Urteil von Google aus CrUX-Felddaten stammt. Verwenden Sie Laborläufe, um den Mechanismus zu verifizieren, und warten Sie auf echte Nutzerdaten, um zu zeigen, ob sich das p75-Ergebnis verbessert hat.

Die LCP-Ressource startet spät

Symptom: Eine lange Lücke erscheint zwischen TTFB und der LCP-Ressourcenanfrage. Wahrscheinliche Ursache: Lazy-Loading, JS-Erkennung, ein CSS-Hintergrundbild oder niedrige Fetch-Priorität. Fix: Machen Sie die Ressource im initialen HTML auffindbar, entfernen Sie Lazy-Loading und setzen Sie fetchpriority="high" oder Preload ein. Bestätigen Sie, dass die Anfrage in einem Trace früher erfolgt.

Die Ressource lädt, aber LCP feuert trotzdem spät

Symptom: Die Ladedauer endet deutlich vor dem LCP-Ereignis. Wahrscheinliche Ursache: Render-blockierendes CSS, synchrones JavaScript, eine lange Aufgabe oder Schriftdarstellung für ein Text-LCP. Fix: Reduzieren Sie blockierende Arbeit und testen Sie die Schriftstrategie für Text; bestätigen Sie, dass die Element-Renderverzögerung schrumpft.

Labor-LCP ist gut, aber Feld-LCP ist schlecht

Symptom: Lighthouse besteht, während CrUX oder die Google Search Console nicht besteht. Wahrscheinliche Ursache: Echte Nutzer haben unterschiedliche Geräte, Netzwerke, Cache-Zustände, Geografien oder LCP-Elemente. Fix: Segmentieren Sie Felddaten, erfassen Sie RUM-Element-/Unterteil-Details und reproduzieren Sie das langsame Segment, anstatt nur das Standard-Laborprofil zu optimieren.

Das gemeldete LCP-Element ändert sich zwischen Läufen

Symptom: DevTools identifiziert unterschiedliche Bilder oder Textblöcke. Wahrscheinliche Ursache: Responsive Breakpoints, Personalisierung, späte DOM-Änderungen oder konkurrierende Kandidaten. Fix: Testen Sie repräsentative Viewports und Zustände und optimieren Sie dann jeden wiederkehrenden Kandidaten, anstatt anzunehmen, dass ein Desktop-Hero jeden Nutzer abdeckt.

Hero-Bild-Erkennung: verzögert vs. früh

Eine vereinfachte verzögerte Implementierung verbirgt das Bild hinter JavaScript:

<div id="hero"></div>
<script>
  document.querySelector('#hero').innerHTML = '<img src="hero.webp" alt="">';
</script>

Der Browser kann diese Version beim Parsen von HTML erkennen und priorisieren:

<img src="hero.webp" alt="" fetchpriority="high" width="1200" height="675">

CSS-Hintergrundbild: nicht offengelegt vs. vorab geladen

Wenn das LCP-Bild ein CSS-Hintergrund bleiben muss, legen Sie es offen, bevor das Stylesheet fertig ist:

<link rel="preload" as="image" href="hero.webp" fetchpriority="high">

Der Preload hilft nur, wenn seine URL und Anfrageattribute mit der tatsächlichen Ressource übereinstimmen.

Aktuelle LCP-Kandidaten in Chrome DevTools auflisten

Fügen Sie dies in die Chrome DevTools-Konsole ein, laden Sie die Seite neu und beobachten Sie jeden Kandidaten, den der Browser meldet. Der letzte Kandidat vor der Interaktion ist der relevante.

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.table({
      lcp: Math.round(entry.startTime),
      element: entry.element?.tagName,
      url: entry.url || '',
      size: entry.size,
    });
  }
}).observe({ type: 'largest-contentful-paint', buffered: true });

Wahrscheinlich lazy-geladene Bilder oberhalb der Falz finden

Führen Sie dies in der DevTools-Konsole aus. Es listet Lazy-Bilder auf, deren obere Kante im aktuellen Viewport beginnt; verifizieren Sie den echten LCP-Kandidaten, bevor Sie das Attribut entfernen.

[...document.querySelectorAll('img[loading="lazy"]')]
  .filter((img) => img.getBoundingClientRect().top < innerHeight)
  .map((img) => ({ src: img.currentSrc || img.src, top: img.getBoundingClientRect().top }));

Bildprioritätsattribute in einem Crawler extrahieren

Verwenden Sie dieses XPath in der Screaming Frog-Benutzerdefinierten Extraktion, um Bilder zurückzugeben, die als hohe Priorität markiert sind:

//img[@fetchpriority='high']/@src

Beweisen, dass ein LCP-Fix gelandet ist

Erkennungsreihenfolge-Test

Durchzuführender Test: Nehmen Sie einen DevTools-Performance-Trace nach dem Ändern des Hero-Bilds auf. Erwartetes Ergebnis: Die LCP-Anfrage startet früher und wird nicht lazy-geladen. Fehlerinterpretation: Die Ressource bleibt verborgen, depriorisiert oder hinter einer anderen Abhängigkeit blockiert. Überwachungsfenster: Sofortiges Laborergebnis. Rollback-Auslöser: Die Änderung verzögert eine andere kritische Ressource oder macht das Labor-LCP konsistent schlechter.

Renderverzögerungstest

Durchzuführender Test: Vergleichen Sie den Abschluss der LCP-Ressource und das LCP-Ereignis in äquivalenten Vorher/Nachher-Traces. Erwartetes Ergebnis: Die Element-Render-Verzögerung verringert sich ohne neues Layout oder visuelle Regression. Fehlerinterpretation: CSS, JavaScript oder Schriftarten blockieren weiterhin das Rendering. Überwachungszeitraum: Sofort über repräsentative Viewports. Rollback-Auslöser: Defektes Rendering, fehlende Stile oder ein schlechteres wiederkehrendes LCP.

Feld-Ergebnistest

Durchzuführender Test: Überwachen Sie das URL-Ebene-CrUX oder First-Party-RUM p75 LCP nach der Bereitstellung. Erwartetes Ergebnis: p75 bewegt sich in Richtung des Good-Schwellenwerts oder bleibt innerhalb desselben, ohne INP oder CLS zu verschlechtern. Fehlerinterpretation: Der Laborfall war nicht repräsentativ oder ein anderer Teilbereich dominiert reale Besuche. Überwachungszeitraum: RUM kann führen; CrUX benötigt sein rollierendes 28-Tage-Fenster, um sich zu drehen. Rollback-Auslöser: Eine anhaltende Feldregression, die mit dem Release verbunden ist.

LCP-Metriken, die es wert sind, verfolgt zu werden

Feld-p75-LCP

Metrik: LCP am 75. Perzentil nach Formfaktor. Was es Ihnen sagt: Ob echte Nutzer den Core-Web-Vitals-Lade-Schwellenwert erreichen. So ziehen Sie es: CrUX, Search Console oder First-Party-RUM. Benchmark / realistischer Bereich: Good liegt bei oder unter 2,5 Sekunden; segmentieren Sie mobil und Desktop. Kadenz: Wöchentlich, mit dem rollierenden CrUX-Fenster aufgezeichnet.

LCP-Teilbereichsverteilung

Metrik: TTFB, Ressourcenladeverzögerung, Ladedauer und Element-Render-Verzögerung für LCP. Was es Ihnen sagt: Welche Stufe den Wartevorgang besitzt. So ziehen Sie es: Repräsentative Labor-Traces und Bild-LCP-Teilbereiche aus CrUX/RUM, wo verfügbar. Benchmark / realistischer Bereich: Verwenden Sie die ungefähre 40/10/40/10-Diagnoseaufteilung des Artikels als Leitfaden, nicht als universelles Leistungsversprechen. Kadenz: Nach Vorlagen-Releases und monatlich für Prioritätsvorlagen.

Good-LCP-URL-Abdeckung

Metrik: Wichtige URL-Gruppen mit Good-Feld-LCP. Was es Ihnen sagt: Ob die Verbesserung breit ist oder auf eine Beispielseite beschränkt. So ziehen Sie es: Search Console CWV-Gruppen plus URL-Ebene-CrUX für Prioritätsseiten. Benchmark / realistischer Bereich: Legen Sie eine Basislinie pro Vorlage fest; URLs mit geringem Traffic können individuelle Felddaten vermissen lassen. Kadenz: Wöchentlich.

Testen Sie sich selbst: Largest Contentful Paint

Fünf kurze Fragen zur LCP-Messung und -Diagnose. Wählen Sie für jede eine Antwort und überprüfen Sie dann.

Ressourcen, die Ihre Zeit wert sind

Meine verwandten Artikel

• Was ist Largest Contentful Paint (LCP) und wie lässt es sich verbessern? — mein vollständiger LCP-Leitfaden im Ahrefs-Blog.
• Was sind Core Web Vitals und wie lassen sie sich verbessern? — wie LCP mit INP und CLS zusammenhängt und warum es am schwersten zu beheben ist.
• Einsteigerleitfaden zur technischen SEO — wo die Seitenleistung im größeren Bild sitzt.

Offiziell (Google / Chrome)

• Largest Contentful Paint (LCP) und Optimize LCP — das kanonische Paar.
• How CWV thresholds were defined — das Warum hinter 2,5 s.

Von anderen

• Beheben Sie das Largest Contentful Paint Ihrer Website durch Optimierung des Bildladens — MDNs entwicklerorientierter Ansatz, stark bei Bandbreitenkonflikten und dem JS-Bild-Antimuster.
• Performance — 2025 Web Almanac — HTTP Archives jährlicher Deep-Dive; Quelle für Einführungsstatistiken zu fetchpriority, Preload-Nutzung, Bild- vs. Text-LCP-Aufteilungen und Bestehensquoten nach Gerät.
• Largest Contentful Paint (LCP) — DebugBears Dokumentation behandelt Wasserfallanalysen zur Identifizierung von Teilkomponenten, Progressive-JPEG-Hinweise sowie Edge Cases bei iframes und Soft Navigation.
• Largest Contentful Paint (LCP): Was es ist, wie man es misst und optimiert — corewebvitals.io; echte RUM-Benchmarks, Fallstudien zur Geschäftsauswirkung (Vodafone Italien) und das Google-Flights-fetchpriority-Ergebnis.
• Largest Contentful Paint | MDN Web Docs — MDN-Referenz für die LargestContentfulPaint-API, Elementtypen und Browserkompatibilität.

Statistiken, die sich zu zitieren lohnen

• LCP ist die schwierigste Core Web Vital, die es zu bestehen gilt. Sie hat die meisten Komponenten, weshalb Websites damit mehr kämpfen als mit INP oder CLS. Quelle
• Mobile ist schwieriger als Desktop. Langsamere CPUs und Verbindungen erhöhen LCP, und bei 3G/langsamen Verbindungen ist der 2,5-s-Schwellenwert nahezu unmöglich zu erreichen. Quelle
• Die Bilddownloadzeit ist oft der kleinste Teil von LCP. Chromes Analyse von HTTP-Archive-Daten ergab, dass die Downloaddauer häufig nicht der Engpass ist — TTFB und Discovery-Verzögerung sind es normalerweise. Quelle
• Die CrUX-Abdeckung ist dünn. In unserer Studie über 42 Millionen Seiten hatten nur etwa 11,4 % zugehörige CrUX-Felddaten — die meisten Seiten erhalten nicht genug echten Nutzerverkehr, um gemessen zu werden. Quelle
• 62 % der mobilen Seiten gegenüber 74 % der Desktop-Seiten erreichen ein gutes LCP (2025 Web Almanac). Die mobile Lücke spiegelt langsamere CPUs und Netzwerkverbindungen wider. Quelle
• Nur 2,1 % der mobilen Seiten laden ihr LCP-Bild vorab, obwohl 76 % ein Bild als LCP-Element haben — eine erhebliche verpasste Optimierungsmöglichkeit (2025 Web Almanac). Quelle
• Die Einführung von fetchpriority="high" wuchs von 0,03 % der mobilen Websites im Jahr 2022 auf 17,3 % im Jahr 2025, hauptsächlich getrieben durch WordPress Core, das es hinzufügte (2025 Web Almanac). Google Flights verzeichnete eine LCP-Verbesserung von 700 ms durch dieses einzelne Attribut. Quelle

Videos

• Google Search Central (YouTube) — die Core Web Vitals- und Page-Experience-Erklärungen, einschließlich Chrome-Team-Durchgängen zur LCP-Optimierung. Kanal

Änderungsprotokoll