Largest Contentful Paint (LCP)

Kurzdefinition

Largest Contentful Paint, kurz LCP, misst, wie lange es dauert, bis das größte sichtbare Inhaltselement im Viewport gerendert ist. Die Uhr läuft ab dem Moment, in dem der Nutzer die Navigation zur Seite startet. Das Element kann ein Bild sein, ein Video-Poster oder das erste Videobild, ein per CSS geladenes Hintergrundbild oder ein Textblock.

LCP ist eines der drei Core Web Vitals, neben Interaction to Next Paint (INP) und Cumulative Layout Shift (CLS). Die Metrik beschreibt das Laden aus Sicht der Besucher. Sie fragt nicht, wann der Server geantwortet hat oder wann alles fertig war, sondern: Wann war das sichtbar, weswegen ich gekommen bin?

Die Grenzwerte, die zählen

Google und das Chrome-Team veröffentlichen drei Bereiche für LCP:

• Gut: höchstens 2,5 Sekunden
• Verbesserungswürdig: mehr als 2,5 und bis zu 4 Sekunden
• Schlecht: mehr als 4 Sekunden

Bewertet wird kein Durchschnitt. Eine Seite oder URL-Gruppe erfüllt den Grenzwert, wenn mindestens 75 Prozent der Seitenaufrufe im guten Bereich liegen. Mobil und Desktop werden getrennt betrachtet. Eine Seite kann also auf dem Desktop bestehen und mobil durchfallen. Das ist ein häufiges Muster, weil Smartphones langsamere Prozessoren und weniger stabile Verbindungen haben.

Das 75. Perzentil ist bewusst gewählt. Einzelne extreme Aufrufe dominieren das Ergebnis nicht, trotzdem musst du dich um den langsameren Teil deines Publikums kümmern und nicht nur um den Idealfall im Büro-WLAN.

Welches Element zum LCP-Element wird

Der Browser weiß vorher nicht, welches Element das größte sein wird. Während die Seite lädt, meldet er jedes Mal einen neuen LCP-Kandidaten, wenn ein größeres Element gezeichnet wird. Der letzte Kandidat vor der ersten Interaktion ist der endgültige Wert. Ein Tippen, ein Klick, ein Tastendruck oder ein Scrollen beendet die Beobachtung, weil sich durch die Interaktion meist ändert, was der Nutzer sieht.

Diese Elementtypen können LCP-Kandidaten werden:

• <img>-Elemente, bei animierten Bildern das erste Frame
• <image>-Elemente innerhalb eines SVG
• <video>-Elemente über das Poster-Bild oder das erste gerenderte Frame
• Elemente mit einem Hintergrundbild, das über url() geladen wird, aber keine CSS-Verläufe
• Block-Elemente, die Text enthalten

Für die Größe zählt nur der Teil eines Elements, der im Viewport sichtbar ist. Außenabstände, Innenabstände und Rahmen zählen nicht mit. Bei skalierten Bildern nimmt der Browser den kleineren Wert aus angezeigter und tatsächlicher Bildgröße. Ein hochskaliertes Vorschaubild bekommt also keinen Bonus.

Chrome wendet außerdem einige Heuristiken an. Elemente mit einer Deckkraft von null werden ignoriert, Elemente, die den ganzen Viewport bedecken, gelten als Hintergrund statt als Inhalt, und informationsarme Platzhalterbilder werden ausgeschlossen. Deshalb ist das LCP-Element manchmal nicht das, was du erwartest. Auf vielen Websites ist es eine Überschrift oder ein Einleitungsabsatz, auf manchen der Text eines Cookie-Banners.

Felddaten und Labordaten

LCP existiert in zwei Welten. Wer die beiden verwechselt, versteht die Metrik meistens falsch.

Felddaten entscheiden über den Status

Felddaten stammen aus echten Seitenaufrufen. Der Chrome User Experience Report (CrUX) sammelt sie bei Chrome-Nutzern, die der Übermittlung zugestimmt haben, und fasst sie über ein rollierendes Fenster von 28 Tagen zusammen. PageSpeed Insights zeigt diese Daten für eine URL oder den gesamten Origin, sobald genug Traffic vorhanden ist. Der Core-Web-Vitals-Bericht in der Google Search Console gruppiert ähnliche URLs und stuft sie als gut, verbesserungswürdig oder schlecht ein.

Zwei Folgen sind in der Praxis wichtig. Erstens erscheint eine Verbesserung in den Felddaten nur nach und nach, weil sich das 28-Tage-Fenster erst mit neuen Aufrufen füllen muss. Zweitens bildet CrUX nur Chrome-Nutzer ab. Wenn ein großer Teil deines Publikums Safari auf dem iPhone nutzt, sagen dir die Felddaten über diese Gruppe nichts direkt.

Labordaten erklären die Ursache

Labordaten entstehen in einem kontrollierten Test, etwa mit Lighthouse, dem Lighthouse-Lauf in PageSpeed Insights oder dem Performance-Panel der Chrome DevTools. Ein Labortest lädt die Seite einmal unter festgelegten Bedingungen, meist mit einem emulierten Mittelklasse-Smartphone und gedrosseltem Netzwerk.

Laborwerte sind reproduzierbar und zeigen den Wasserfall, das LCP-Element und die blockierenden Ressourcen. Sie zeigen nicht, was wiederkehrende Besucher mit gefülltem Cache, Nutzer hinter einem Consent-Banner oder Menschen mit Glasfaseranschluss erleben. Ein Labor-LCP von 3,1 Sekunden und ein Feld-LCP von 2,2 Sekunden widersprechen sich nicht. Sie beschreiben verschiedene Aufrufe.

Eine brauchbare Regel: Mit Felddaten entscheidest du, ob und wo es ein Problem gibt. Mit Labordaten findest du heraus, warum.

Die vier LCP-Phasen

Die Optimierungsanleitung auf web.dev zerlegt LCP in vier aufeinanderfolgende Phasen. Wer in diesen Phasen denkt, macht aus "die Seite ist langsam" eine konkrete Frage.

1. Time to First Byte (TTFB): vom Start der Navigation bis zum ersten Byte der HTML-Antwort. Langsame Server, fehlendes Caching, Weiterleitungen und große Entfernungen zum Nutzer schlagen hier zu Buche.
2. Ladeverzögerung der Ressource: die Zeit zwischen TTFB und dem Moment, in dem der Browser die LCP-Ressource anfordert. Eine große Verzögerung bedeutet, dass der Browser das Bild spät entdeckt hat, etwa weil JavaScript es einfügt oder CSS es referenziert.
3. Ladedauer der Ressource: wie lange der Download der LCP-Ressource selbst dauert. Zu große Dateien, fehlende Komprimierung und eine ausgelastete Verbindung treiben diesen Wert nach oben.
4. Renderverzögerung des Elements: die Zeit zwischen fertigem Download und tatsächlicher Darstellung. Render-blockierende Stylesheets, lange JavaScript-Tasks oder ein clientseitiges Framework, das die Komponente noch nicht gerendert hat, verursachen diese Verzögerung.

Ist das LCP-Element ein Text, liegen die beiden Ressourcen-Phasen nahe null, und die Zeit verteilt sich auf TTFB und Renderverzögerung. web.dev nennt als grobe Orientierung, dass der Großteil der Zeit auf TTFB und Download entfallen sollte und Ladeverzögerung sowie Renderverzögerung klein bleiben. Sieh das als Diagnosehilfe, nicht als festes Budget.

Was einen langsamen LCP meistens verursacht

Auf sehr unterschiedlichen Websites tauchen dieselben Muster auf:

• Das Hero-Bild wird spät entdeckt. Ein Slider-Skript, ein CSS-Hintergrund oder eine clientseitige Komponente fügt das Bild erst nach dem JavaScript ein. Der Download startet Sekunden nach dem HTML.
• Das LCP-Bild wird per Lazy Loading geladen. loading="lazy" ist für Bilder weiter unten sinnvoll. Beim wichtigsten Bild im sichtbaren Bereich verzögert es genau die Ressource, auf die alle warten.
• Das Bild ist viel größer als nötig. Ein 2.400 Pixel breites JPEG für einen 390 Pixel breiten Smartphone-Bildschirm verschwendet den Großteil der Übertragung.
• Der Server antwortet langsam. Ungecachte Seiten, langsame Datenbankabfragen und Weiterleitungsketten schieben alles nach hinten, bevor der Browser überhaupt anfangen kann.
• Clientseitiges Rendering verzögert den Inhalt. Ist das HTML nur eine leere Hülle und baut ein JavaScript-Bundle die Seite auf, kann das LCP-Element erst erscheinen, wenn das Bundle geladen und ausgeführt ist.
• Render-blockierendes CSS und Webfonts. Große Stylesheets im <head> und Schriften, die Text bis zum Laden verstecken, können ein fertig geladenes Element am Erscheinen hindern.

Wie du LCP verbesserst

Beginne mit der Phase, die am meisten Zeit kostet. An der Renderverzögerung zu feilen bringt wenig, wenn die TTFB zwei Sekunden frisst.

Für die TTFB cachst du HTML, wo es geht, lieferst über ein CDN nah an deinen Nutzern aus, entfernst Weiterleitungen und schaust dir die langsamste Backend-Arbeit des Templates an. Server-gerendertes oder statisches HTML schlägt meist eine clientseitige Hülle. Das ist ein Grund, warum Teams sich für Content-Seiten Server-Side Rendering ansehen.

Gegen die Ladeverzögerung machst du das LCP-Bild im ursprünglichen HTML auffindbar. Nutze ein normales <img> mit src oder srcset statt eines per JavaScript eingefügten Elements. Muss das Bild aus CSS kommen, hilft ein <link rel="preload">. Gib dem LCP-Bild fetchpriority="high", damit der Browser es nicht hinter unwichtigere Ressourcen einreiht, und entferne loading="lazy".

html<img
  src="/images/hero-800.avif"
  srcset="/images/hero-400.avif 400w, /images/hero-800.avif 800w, /images/hero-1600.avif 1600w"
  sizes="(max-width: 600px) 100vw, 800px"
  width="800" height="450"
  fetchpriority="high"
  alt="Team prüft einen Crawl-Bericht">

Für die Ladedauer lieferst du moderne Formate wie AVIF oder WebP aus, bietest über srcset und sizes passende Größen an und komprimierst sauber. Formate und Größen behandelt der Eintrag zur Bildoptimierung ausführlicher.

Gegen die Renderverzögerung reduzierst du render-blockierendes CSS, verschiebst nicht kritisches JavaScript, hältst lange Tasks aus dem kritischen Pfad heraus und sorgst dafür, dass Webfonts Text nicht lange verstecken. Ist das LCP-Element Text, steckt die Zeit meistens hier.

Zwei Browser-Funktionen können LCP bei wiederholten oder vorhersehbaren Navigationen fast auf null bringen: der Back/Forward-Cache, der eine Seite aus dem Speicher wiederherstellt, und spekulatives Vorrendern über die Speculation Rules API. Beides hängt davon ab, wie deine Website gebaut ist. Teste es, bevor du dich darauf verlässt.

Ein Beispiel Schritt für Schritt

Ein Reiseportal sieht in der Search Console einen schlechten mobilen LCP für sein Artikel-Template. PageSpeed Insights bestätigt einen Feld-LCP von etwa 4,3 Sekunden im 75. Perzentil. Der Labortest identifiziert das Titelbild des Artikels als LCP-Element.

Der Wasserfall zeigt das eigentliche Problem. Das HTML kommt nach 600 Millisekunden an, aber der Download des Titelbilds beginnt erst nach 2,1 Sekunden, weil ein Galerie-Skript es einfügt. Das Bild selbst ist ein 380 KB großes JPEG in Desktop-Größe.

Das Team ändert drei Dinge: Das erste Galeriebild wird ein normales <img> im Server-HTML mit fetchpriority="high", das Bild wird in responsiven AVIF-Größen ausgeliefert, und das Galerie-Skript lädt erst nach dem ersten Bild. In den nächsten Labortests sinkt die Ladeverzögerung auf wenige hundert Millisekunden, und der LCP fällt unter 2,5 Sekunden. Bis sich die URL-Gruppe in der Search Console bewegt, braucht es mehrere Wochen neuer Aufrufe. Das ist normal.

LCP und SEO

Google gibt an, dass die Core Web Vitals als Teil der Page Experience in die Ranking-Systeme einfließen, und empfiehlt gute Werte. Gleichzeitig sagt Google, dass eine gute Page Experience keine Relevanz ersetzt. Eine schnelle Seite, die die falsche Frage beantwortet, überholt keine langsamere Seite, die die richtige beantwortet.

LCP ist damit eher ein Tiebreaker und ein Nutzbarkeitsthema als ein zentraler Ranking-Hebel. Das praktischere Argument sind die Besucher. Wer auf den Hauptinhalt wartet, springt ab oder verliert die Geduld, und das wirkt sich unabhängig von Rankings auf Conversions aus. Weil Google bei den meisten Websites die mobile Version indexiert, verdient der mobile LCP deiner wichtigen Templates den ersten Blick.

Diagnose in sinnvoller Reihenfolge

1. Öffne den Core-Web-Vitals-Bericht in der Search Console und trenne Mobil von Desktop.
2. Finde die URL-Gruppen mit schlechtem oder verbesserungswürdigem LCP und notiere, zu welchen Templates sie gehören.
3. Prüfe in PageSpeed Insights die Felddaten einer repräsentativen URL und des Origins.
4. Führe einen Labortest aus und bestimme das LCP-Element. Ist es das Element, das du erwartet hast?
5. Zerlege den Labor-LCP in die vier Phasen und finde die größte.
6. Behebe die größte Phase im Template, nicht nur auf der Beispiel-URL.
7. Prüfe die Änderung nach dem Deployment im Labor.
8. Warte auf neue Felddaten, bevor du das Problem als gelöst betrachtest.

Häufige Fehler

• den Lighthouse-Score optimieren statt des Feld-LCP echter Nutzer
• das wichtigste Bild im sichtbaren Bereich per Lazy Loading laden
• viele Bilder gleichzeitig vorladen, wodurch die Priorität des einen wichtigen Bildes verwässert
• annehmen, das LCP-Element sei das Hero-Bild, ohne es zu prüfen
• eine Änderung nach einem Tag bewerten, obwohl CrUX noch die letzten 28 Tage abbildet
• nur auf dem Desktop testen, obwohl Google und die meisten Besucher die mobile Version nutzen
• einen grünen LCP als Beleg für eine gute Page Experience lesen, obwohl INP oder CLS schlecht sind

Crawl-Foundry-Perspektive

Für Performance-Messungen nutzt der Site Audit von Crawl Foundry den offiziellen Lighthouse-Runner (Lighthouse 13) auf unseren eigenen Servern, jede Messung läuft als isolierte Aufgabe. Der Site Audit selbst ist eine bezahlte Datenaktion, deren Preis du vor dem Start siehst. Die Lighthouse-Messung selbst kostet dich nichts extra. Du bekommst Laborwerte für die getesteten URLs unter gleichbleibenden Bedingungen.

Diese Werte sind Labordaten. Sie helfen dir, das LCP-Element und die langsame Phase zu finden, ersetzen aber weder die CrUX-Felddaten noch den Core-Web-Vitals-Bericht der Search Console. Diese bleiben die Quellen dafür, wie echte Nutzer deine Seiten erleben. Weil derselbe Crawl auch Statuscodes, Indexierbarkeit und interne Links erfasst, hilft dir der Site Audit für technisches SEO, LCP-Arbeit dort anzusetzen, wo sie zählt: auf indexierbaren URLs, die ranken sollen, und nicht auf Seiten, die ohnehin nicht in die Suche gehören.

Verwandte Begriffe

• Seitengeschwindigkeit
• Page-Experience-Metriken
• Website-Geschwindigkeit optimieren
• JavaScript-Rendering für SEO
• Mobile-First-Indexierung

Quellen für den Review

• web.dev: Largest Contentful Paint (LCP)
• web.dev: Largest Contentful Paint optimieren
• web.dev: So wurden die Grenzwerte der Core Web Vitals festgelegt
• Google Search Central: Core Web Vitals und Google-Suchergebnisse
• Chrome for Developers: CrUX-Methodik
• W3C: Largest Contentful Paint Specification
• MDN Web Docs: LargestContentfulPaint