Largest Contentful Paint (LCP): Was er ist, wie du ihn misst und optimierst

Wie wird der LCP berechnet?

Chrome misst den LCP eines Seitenaufrufs vom Moment der Anfrage durch den Besucher bis zum Rendern des größten Elements im Viewport. Bei jedem Rendern eines noch größeren Elements meldet Chrome einen neuen Kandidaten – bis zum ersten Tippen, Scrollen oder Tastendruck des Besuchers. Der letzte Kandidat ist der LCP-Wert.

Das LCP-Element kann sich also ändern: Zuerst ist die Überschrift am größten, dann löst das Hero-Bild sie ab. „Last contentful paint“ ist halb richtig, „least contentful paint“ ist falsch: Der letzte Kandidat zählt, und das ist immer das bis dahin größte gerenderte Element. Google bewertet das 75. Perzentil dieser Werte über 28 Tage.

Warum nutzt der LCP das größte Element?

Moderne Seiten haben keinen festen Zeitpunkt, an dem sie fertig geladen sind: Lazy Loading und Skripte laden Daten nach, solange der Besucher auf der Seite bleibt. Der LCP misst, wann das größte Element – der Hauptinhalt – auf dem Bildschirm zu sehen ist. Das Speed-Metrics-Team von Chrome hat die Metrik rund um eine Frage entwickelt: „Wann ist der Hauptinhalt der Seite für den Nutzer sichtbar?“

LCP vs. FCP: Was ist der Unterschied?

Der First Contentful Paint (FCP) ist der Moment, in dem der Browser den ersten Text oder das erste Bild rendert. Der Largest Contentful Paint (LCP) ist der Moment, in dem er das größte Element im Viewport rendert. Der FCP zeigt dir, dass die Seite zu laden beginnt. Der LCP zeigt dir, wann sich die Seite geladen anfühlt.

Ein schneller FCP mit einem späten LCP weist auf das LCP-Bild hin oder auf etwas, das es verdeckt. Sind beide spät, fang beim Server und den Dateien im Head an.

Warum ist der LCP wichtig?

Die meisten Websites, die bei den Core Web Vitals durchfallen, scheitern am LCP: Im CrUX-Release vom September 2026 hatten 68,3 % aller Origins einen guten LCP – gegenüber 81,7 % bei CLS und 85,4 % bei INP. Google nutzt den LCP echter Chrome-Besucher in seinen Page-Experience-Rankingsignalen.

Welche Elemente können das LCP-Element sein?

Das LCP-Element ist das größte dieser Elemente im Viewport: ein <img>, ein <image> innerhalb eines <svg>, das Poster oder der erste Frame eines Videos, ein Element mit CSS-url()-Hintergrund oder ein Textblock.

Chrome übergeht Elemente mit Opacity 0, Bilder, die den gesamten Viewport abdecken, und Low-Entropy-Bilder: Seit Chrome 112 gilt ein Bild mit weniger als 0,05 Bit an Bilddaten pro angezeigtem Pixel als Low-Entropy. Die Größe eines Kandidaten folgt drei Regeln:

• Nur der Teil innerhalb des Viewports zählt, ohne Padding, Border oder Margin.
• Text zählt als das kleinste Rechteck um seine Textzeilen.
• Ein Bild zählt mit dem kleineren Wert aus nativer Pixelgröße und angezeigter Größe auf dem Bildschirm.

Ein Fade-in ab Opacity 0 zählt erst, wenn das Einblenden endet. Das gesamte Einblenden verlängert also den LCP.

Wie findest du dein LCP-Element?

Öffne das Performance-Panel in den Chrome DevTools: Noch vor der Aufnahme nennt es das LCP-Element der Seite. PageSpeed Insights und Lighthouse zeigen es im Hinweis zum LCP-Breakdown. CoreDash meldet den LCP pro Element für echte Besucher. Prüfe Smartphone und Desktop getrennt: Auf dem Smartphone kann eine Überschrift größer sein als der sichtbare Teil des Fotos.

Was ist ein guter LCP-Wert?

Ein guter LCP liegt bei 2,5 Sekunden oder weniger für mindestens 75 % der Seitenaufrufe. Werte von 2,5 bis 4 Sekunden gelten als verbesserungswürdig, mehr als 4 Sekunden als schlecht.

Der p75-LCP (75. Perzentil) ist der Wert, den drei von vier Seitenaufrufen erreichen oder unterbieten. Prüfe zuerst den Mobil-Tab von PageSpeed Insights: Die Field Data ganz oben zeigt das p75 der letzten 28 Tage. Wenn die Search Console „LCP-Problem: Länger als 2,5 s (Mobilgerät)“ meldet, liegt eine Gruppe deiner URLs für Smartphone-Besucher über 2,5 Sekunden. Der Leitfaden LCP-Probleme erkennen und beheben führt dich von diesem Bericht zur Ursache. In Lighthouse macht der LCP ein Viertel des Performance-Scores aus. Google bewertet für das Ranking aber den LCP deiner echten Besucher.

Was zeigen Daten echter Besucher über langsame LCP-Werte?

Laut dem State of Web Vitals bestehen Websites, deren LCP-Bild aus einem Stylesheet stammt, den LCP auf Smartphones seltener als Websites mit dem Bild im HTML: 77 % gegenüber 84 %. Das ist eine Korrelation. In denselben Daten bestehen 70 % der WordPress-Websites den LCP auf Smartphones, verglichen mit 95 % der Shopify-Websites.

CoreDash hat in den 28 Tagen bis zum 7. November 2026 echte Seitenaufrufe bei 149 Projekten gemessen. Zusammengenommen lag deren LCP-p75 bei rund 1,8 Sekunden auf Smartphones und 1,7 Sekunden auf dem Desktop. Bei einem Bild-LCP auf Smartphones lag das p75 der einzelnen Phasen bei 580 ms Time to First Byte, 350 ms Resource Load Delay, 130 ms Resource Load Duration und 550 ms Element Render Delay. Jeder Wert ist das p75 dieser einzelnen Phase. Zusammengerechnet ergeben die vier Werte daher nicht den LCP.

Öffne für deine eigenen Besucher den LCP in CoreDash auf Mobilgeräten und schau dir den Phase-Breakdown an.

CoreDash Phase-Breakdown: Der längste Balken ist der Teil, den du zuerst optimieren solltest.

Was sind die vier Teile (Phasen) des LCP?

Der LCP eines Bilds besteht aus vier aufeinanderfolgenden Phasen: Time to First Byte, Resource Load Delay, Resource Load Duration und Element Render Delay. Ein Text-LCP hat nur die erste und die letzte Phase: Das Warten auf Stylesheets und einen Webfont zählt als Render Delay.

Von links nach rechts: Das Warten auf das HTML, das Warten auf die Bildanfrage, der Download und das Warten, bis das Bild gerendert wird.

Laut dem State of Web Vitals ist Time to First Byte auf zwei von drei Websites der größte Teil des mobilen LCP. Der Bild-Download ist nur bei etwa jeder fünfzigsten Seite die größte Phase. Das Komprimieren des LCP-Bilds ist der Fix, den die meisten zuerst versuchen – auf den meisten Websites verkürzt das jedoch die kleinste Phase.

Lighthouse und die DevTools zeigen die Phasen im Hinweis zum LCP-Breakdown (ältere Bezeichnungen: „Largest Contentful Paint element“, „LCP by phase“).

Auf einer Testseite im Stil einer Makler-Website mit WordPress, Elementor und einem Slider sank der LCP auf einem gedrosselten Smartphone von 6,70 auf 2,18 Sekunden, als wir eine Phase nach der anderen optimierten. Das Foto nach WebP zu konvertieren, verkürzte den Download um 2,5 Sekunden. Davon wanderten allerdings 1,9 Sekunden in das Element Render Delay, weil eine Entrance-Animation das Foto bis zum Ende des Fade-ins zurückhielt. LCP breakdown zeigt jeden Schritt.

Wie findest du heraus, was deinen LCP bremst?

Starte mit Field Data auf Mobilgeräten: Welche Seiten fallen beim LCP für echte Besucher durch (die Search Console gruppiert sie) und welche der vier Phasen ist dort die größte (CoreDash zeigt beides)? Prüfe auch den Trend: Ein plötzlicher Sprung deutet auf ein Release hin, ein langsamer Anstieg auf nach und nach angehäufte Third-Party-Skripte. Teste dann eine dieser Seiten:

1. PageSpeed Insights, Mobil-Tab: der schnellste LCP-Test mit dem Field-LCP und einem Lighthouse-Lauf.
2. Chrome DevTools: Zeichne einen Trace im Performance-Panel auf einem gedrosselten Smartphone auf und öffne den LCP-Breakdown in der Insights-Sidebar. LCP mit den Chrome DevTools diagnostizieren führt durch den Trace.

Das Performance-Panel vor der Aufnahme: der lokale LCP, das Field-p75 und das LCP-Element.

Dieses Snippet loggt jeden LCP-Kandidaten mit Zeit und Element. Der letzte ist der LCP. Für mehr als einen schnellen Check nutzt du die web-vitals-Bibliothek.

new PerformanceObserver((list) => {
  const lcpEntry = list.getEntries().at(-1);
  console.log('LCP value: ', lcpEntry.startTime);
  console.log('LCP element: ', lcpEntry.element, lcpEntry.url);
}).observe({ type: 'largest-contentful-paint', buffered: true });

Lighthouse lädt deine Seite einmal auf einem simulierten Smartphone. Google bewertet im Ranking dagegen das 75. Perzentil aus 28 Tagen echter Besuche. Dieses Muster sehe ich bei fast jedem Audit: Auf dem Entwickler-Rechner passt alles, im CrUX-p75 fällt die Seite durch. In PageSpeed Insights stammen die Zeilen des LCP-Breakdowns aus einem schnellen Testlauf – sie ergeben in der Summe also nicht den LCP. Lab and field data erklärt, welcher Wert wofür da ist.

Wie optimierst du einen langsamen LCP?

Optimiere zuerst die längste der vier Phasen. Auf den meisten Seiten ist das Time to First Byte – starte also mit einem Page-Cache. Danach folgt ein LCP-Bild, das der Browser zu spät findet. Eine kleinere Bilddatei bringt meistens am wenigsten.

Ein langsamer Server (Time to First Byte)

Aktiviere einen Page-Cache in deinem Cache-Plugin oder beim Hoster, damit der Server eine zwischengespeicherte Kopie der Seite ausliefert. Eingeloggte Nutzer, ein Warenkorb-Cookie und unbekannte Query-Strings umgehen diese Kopie oft. Jeder Redirect kostet einen zusätzlichen Roundtrip. Für Entwickler: Cache das HTML auch auf dem CDN. Alle Details zur Serverzeit findest du im Leitfaden zu Time to first byte.

Ein Bild, das der Browser zu spät findet (Resource Load Delay)

Ein <img> im HTML wird bereits angefordert, während das HTML noch eintrifft. Ein Foto im Hintergrund einer Section, in einem Slider-Skript oder mit loading="lazy" wartet auf das Stylesheet, das Skript oder das Layout. Schalte Lazy Loading für das erste Bild ab, nutze ein normales Bild-Element statt eines CSS-Hintergrunds und mach den ersten Slide zu einem einfachen Bild.

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

Auf einer Hotel-Testseite war dasselbe Foto als <img> mit fetchpriority="high" nach 2,02 Sekunden auf dem Bildschirm, mit loading="lazy" erst nach 3,64 Sekunden. In einem Test bei Google Flights senkte fetchpriority="high" den LCP von 2,6 auf 1,9 Sekunden (web.dev). Ich habe damit bis zu 30 % schnellere LCP-Werte gemessen. Der Fix scheitert, wenn ein Lazy-Load-Plugin die URL in data-src verschiebt oder ein Logo in doppelter Größe das fetchpriority="high" abgreift, das WordPress dem ersten großen Bild zuweist. Auch ein Preload für ein Foto, das nicht im HTML stehen kann, braucht fetchpriority="high". LCP request discovery erklärt die Schritte für jede Plattform.

Eine große Bilddatei (Resource Load Duration)

Liefere die Größe aus, die der Bildschirm braucht – als WebP oder AVIF. Ein Bild-Plugin wie Imagify oder ShortPixel übernimmt das Konvertieren. Ein Section-Hintergrund oder ein Slider liefert dieselbe Datei an jeden Bildschirm aus. Ein <img> mit srcset erlaubt dem Smartphone hingegen, eine kleinere Variante zu wählen:

<img src="hero-828.webp"
     srcset="hero-480.webp 480w, hero-828.webp 828w, hero-1200.webp 1200w"
     sizes="100vw" width="1200" height="800" fetchpriority="high" alt="...">

Liegt ein LCP-Bild auf einer anderen Domain, wartet der Browser auf eine eigene Verbindung: Verschiebe es auf deine eigene Domain. Nutze ein Preconnect nur dann, wenn das nicht geht. LCP-Bild optimieren liefert Formate und Größen.

Ein Bild, das auf die Anzeige wartet (Element Render Delay)

Das LCP-Bild ist heruntergeladen, wird von der Seite aber noch blockiert: durch eine Entrance-Animation, einen Slider, der Slides bis zum Skriptstart ausblendet, bis zum ersten Tippen verzögerte Skripte oder das Anti-Flicker-Snippet eines A/B-Tests. Schalte die Entrance-Animation der ersten Section aus und zeige den ersten Slide direkt im HTML. Muss das Foto einblenden, starte im Stylesheet fast sichtbar:

.hero {
  animation: fadeIn 1s both;
}
@keyframes fadeIn {
  from { opacity: 0.01; }
  to { opacity: 1; }
}

In React mit Motion (Framer Motion) gibst du dem LCP-Element initial={false}. Im Trace ist der Long Task zwischen Download und Paint viel häufiger ein Tag Manager oder Consent-Skript als dein eigener Code.

Das Foto wartet außerdem auf jeden render-blocking Request. Halte jedes render-blocking Stylesheet komprimiert unter rund 15 kB, fasse winzige Dateien zusammen und verzichte auf @import. Critical CSS – die übliche Empfehlung an dieser Stelle – rendert die Seite erst mit einem Teil des CSS und passt das Styling an, sobald der Rest eintrifft. Zudem wird Inline-CSS bei jedem Seitenaufruf erneut heruntergeladen. Ein Text-LCP mit einem Webfont kann auf den Font warten (Font display). Die Einstellungen für verschiedene Page-Builder findest du im LCP breakdown.

WordPress

• Page-Cache: WP Rocket, LiteSpeed Cache oder dein Hoster. Teste die Seite ausgeloggt.
• Das erste Bild: „Optimize Critical Images“ von WP Rocket, „Exclude Leading Images“ von Perfmatters oder „Viewport Images“ von LiteSpeed Cache nehmen es vom Lazy Loading aus. Nutze in Elementor ein Image-Widget statt eines Container-Hintergrunds. Das Plugin dieser Website, WP Core Web Vitals, lernt das LCP-Bild pro Bildschirmgröße anhand deiner Besucher und lädt es zuerst mit hoher Priorität.
• Render Delay: Setze in Elementor bei der ersten Section Advanced > Motion Effects > Entrance Animation auf None. WP Rocket, Perfmatters und LiteSpeed Cache können Skripte bis zum ersten Tippen oder Scrollen zurückhalten. Wenn das Skript für dein Foto dazugehört, wartet das Foto genau auf diesen Fingertipp. Schließe die Skripte des Page-Builders von dieser Verzögerung aus. Lass Critical CSS und Remove Unused CSS ausgeschaltet: Sie machen mehr Ärger, als sie nützen.

Shopify

Server, Cache und Bildformate liegen bei Shopify. Die Redirects und das Theme liegen bei dir. Dawn, Horizon und darauf basierende Themes weisen dem Bild in der ersten Section fetchpriority="high" zu: Mach das Banner zur ersten Section. Unter Theme settings > Animations blendet Dawns „Reveal sections on scroll“ fast sofort sichtbar ein. In anderen Themes solltest du das abschalten und das Element Render Delay vergleichen. Ein Hero-Bereich, den eine App per JavaScript aufbaut, startet immer spät – egal, was das Theme tut: Nutze eine Theme-Section.

Hat dein LCP-Fix echte Besucher erreicht?

CoreDash zeigt dir einen Fix in den Daten echter Besucher Tag für Tag: Filtere auf Mobilgeräten nach den geänderten Seiten. Die Search Console blickt auf die letzten 28 Tage zurück. Zwei Wochen nach dem Go-live eines Fixes zeigt sie zur Hälfte noch den alten Stand. Es dauert bis zu 28 Tage, bis alles grün wird.

Lass Lighthouse noch einmal laufen und vergleiche alle vier Phasen mit dem Test vor dem Fix. Wenn ein Wert sinkt und ein anderer um etwa denselben Betrag steigt, wartet das Bild jetzt auf etwas anderes.

Manche LCP-Probleme erfordern mehr als eine Einstellung: ein Server oder Theme, das du nicht ändern kannst, oder eine Verzögerung, die nach jedem Fix in die nächste Phase wandert. In einer Core Web Vitals Power Hour prüfen wir gemeinsam deine Field Data und den Trace deines langsamsten Templates. Wir legen fest, welche Phase du zuerst angehst und wie du das auf deiner Plattform löst.