Largest Contentful Paint (LCP): Was es ist, wie du ihn misst & optimierst

Was ist der Largest Contentful Paint (LCP)?

Der Largest Contentful Paint ist die Renderzeit des größten Inhaltselements (ein Bild, ein Video oder ein Textblock), das im sichtbaren Bereich des Bildschirms gezeichnet wird. Der LCP-Wert ist die Zeit in Millisekunden zwischen der Anfrage der Seite und dem Moment, in dem das Element im sichtbaren Bereich angezeigt wird.

Manche nennen ihn „last contentful paint“. Es geht um das größte Element: Ein kleineres Element, das später gerendert wird, ändert ihn nicht.

Die Geschichte des Largest Contentful Paint

Warum misst man Ladegeschwindigkeit nicht als „die Zeit, die die Seite zum Laden braucht“?

Weil du bei den meisten modernen Websites nicht sagen kannst, wann die Seite fertig geladen ist. Durch Lazy Loading und progressives Laden kann eine Seite so lange weiterladen, wie der Besucher bleibt. Ein einzelner Zeitpunkt beschreibt die Geschwindigkeit einer Seite nicht.

Eine Seite kann sich während des Ladens in mehreren Momenten langsam anfühlen. Der Server antwortet spät (Time to First Byte), eine Weile wird nichts angezeigt (First Contentful Paint) oder der Hero-Bereich ist noch eine graue Box, wenn der Rest schon da ist (Largest Contentful Paint). Oder der erste Klick bewirkt nichts.

LCP wurde gewählt, weil er dem folgt, was der Besucher sieht. Wenn der LCP eintritt, denken die meisten Besucher, die Seite sei fertig, auch wenn noch Skripte laufen. Die Metrik wurde entwickelt, um eine Frage zu beantworten: „Wann ist der Inhalt einer Seite sichtbar?“.

LCP vs FCP: Was ist der Unterschied?

Largest Contentful Paint (LCP) und First Contentful Paint (FCP) messen beide die Ladeleistung, aber sie messen unterschiedliche Momente. Der FCP feuert, sobald der Browser das erste Pixel Inhalt zeichnet. Das kann eine winzige Navigationsleiste oder ein Lade-Spinner sein. Der LCP feuert, wenn das größte bedeutungsvolle Element im Viewport gerendert wird.

Der FCP sagt dir, dass die Seite begonnen hat zu laden. Der LCP sagt dir, dass die Seite sich geladen anfühlt. Deshalb hat Google den LCP zum Core Web Vital gemacht.

Optimiere bei den meisten Websites zuerst den LCP. Der FCP passiert immer vor dem LCP. Ein schneller LCP bringt also meistens einen schnellen FCP mit sich. Ein schneller FCP sagt wenig über den LCP aus: Eine Seite kann ihren Header bei 0,8 Sekunden rendern und ihr Hero-Bild bei 4.

Warum der LCP wichtig ist

Als Core Web Vital ist der LCP wichtig für SEO. Für deine Besucher ist er noch wichtiger: Niemand wartet gerne. Der meiste Traffic ist mobil, wo Seiten langsamer laden.

• Rankings. LCP ist Teil von Googles Core Web Vitals. Google nutzt die Seiten-Geschwindigkeit als Rankingfaktor.
• Besucher. Ein Besucher, der auf einen weißen Bildschirm oder eine graue Box starrt, wo der Hero-Bereich sein sollte, geht. Der Vodafone-Test unten liefert dazu Zahlen.
• Google Ads. Die Nutzererfahrung auf der Landingpage ist Teil deines Qualitätsfaktors. Eine langsame Landingpage macht jeden Klick teurer.

Fallstudie: Vodafone (31% LCP-Verbesserung, 8% mehr Umsatz)

Vodafone Italien teilte den Traffic 50/50 zwischen der alten Landingpage und einer schnelleren Kopie auf. Diese sah gleich aus und funktionierte identisch. Die schnellere Kopie renderte auf dem Server statt in clientseitigen Widgets. Sie lieferte ein skaliertes Hero-Bild aus, verzögerte Bilder außerhalb des sichtbaren Bereichs und nutzte kleinere SVG- und PNG-Dateien. Der LCP sank von 8,3 auf 5,7 Sekunden (31% schneller) und der Umsatz stieg um 8%. (Vodafone Fallstudie auf web.dev)

Test: Google Flights (fetchpriority sparte 700ms)

In einem Test auf der Google Flights Seite verbesserte fetchpriority="high" auf dem LCP-Bild den LCP von 2,6 auf 1,9 Sekunden. Ohne das Attribut fragt Chrome Bilder mit niedriger Priorität an. Der Browser erhöht die Priorität erst, wenn das Layout zeigt, dass das Bild im Viewport ist. Auf einer stark ausgelasteten Seite bedeutet das hunderte Millisekunden Wartezeit. Erfahre mehr über Ressourcen-Priorisierung für Core Web Vitals.

Welche Elemente zählen als LCP-Elemente?

Nicht jedes Element kann das LCP-Element sein. Es muss im sichtbaren Bereich des Bildschirms (dem Viewport) gezeichnet werden, bevor der Nutzer mit der Seite interagiert.

Das Element muss eines der folgenden sein:

• Ein <img>-Element.
• Ein <image>-Element, das in einem <svg>- Element verschachtelt ist.
• Ein <video>-Element (das Poster-Bild oder der erste Video-Frame wird verwendet, je nachdem, was früher eintritt).
• Ein Element mit einem Hintergrundbild, das über die CSS-Funktion url() geladen wird. Es zählt, aber der Preload-Scanner kann es nicht sehen. Der Browser findet das Bild also spät. Mehr dazu unter Hintergrundbilder verzögern.

• Ein Block-Level-Element, das Textknoten oder andere Inline-Textelemente enthält (bei Inline-Textelementen wie <span> wird das nächste Block-Level-Element wie <div> oder <p> gewertet).

Einige Elemente werden ignoriert: Elemente mit opacity: 0, Bilder, die den gesamten Viewport abdecken (Chrome behandelt diese als Hintergrund), und Platzhalter-Bilder mit niedriger Entropie. Seit Chrome 112 wird ein Bild mit weniger als 0,05 Bits Bilddaten pro angezeigtem Pixel als Platzhalter ignoriert. Chrome ändert diese Regeln von Zeit zu Zeit.

Wie die LCP-Elementgröße gemessen wird

Der Browser berechnet die Größe jedes Kandidaten nach diesen Regeln:

• Nur Viewport: Nur der sichtbare Teil der Seite wird berücksichtigt. Wenn ein Element nur teilweise im sichtbaren Viewport liegt, wird die berechnete Größe abgeschnitten.
• Kein border, padding oder margin: Bei allen Elementen werden Rahmen, Innenabstände (padding) und Außenabstände (margin) komplett ignoriert.
• Textgröße: Textelemente werden als das kleinste Rechteck gemeldet, das um die Textknoten gezeichnet werden kann.
• Bildgröße: Bei Bildern wird die kleinere der beiden Abmessungen verwendet: die intrinsische (die ursprüngliche Breite und Höhe) oder die Anzeigegröße (die Größe auf dem Bildschirm), um die LCP-Elementgröße zu berechnen.
• Erste Größe zählt: Wenn sich das Layout ändert oder sich die Größe eines Elements ändert, wird nur die erste Größe für den LCP berücksichtigt.
• Entfernte Elemente zählen mit: Wenn ein Element aus dem DOM entfernt wird, bleibt es ein LCP-Kandidat.

Das LCP-Element kann sich während des Ladens ändern

Eine Seite rendert in Phasen. Deshalb ändert sich das LCP-Element oft, während die Seite lädt. Bis zur ersten Nutzerinteraktion meldet der Browser jeden neuen LCP-Kandidaten. Wenn ein neues Element gezeichnet wird, das im Viewport sichtbar und größer als der vorherige Kandidat ist, wird es zum neuen LCP-Element.

Erkenntnisse aus LCP Field Data: Bei CoreDash tracken wir täglich Millionen von LCP-Einträgen. Auf Mobilgeräten ist das LCP-Element oft ein Absatz oder eine Überschrift. Auf dem Desktop passt durch den breiteren Viewport ein größeres Bild. Daher hat dieselbe Seite oft auf jedem Gerät ein anderes LCP-Element. Prüfe beides, bevor du entscheidest, was du behebst.

Was ist ein guter LCP-Wert?

Um den LCP-Teil der Core Web Vitals zu bestehen, müssen mindestens 75% deiner Seitenaufrufe einen guten LCP-Wert haben: unter 2,5 Sekunden. Zwischen 2,5 und 4 Sekunden gilt als Optimierung erforderlich, alles über 4 Sekunden ist mangelhaft. Prüfe zuerst den Mobile-Tab in PageSpeed Insights. Die Field Data ganz oben zeigen das 75. Perzentil (p75) der letzten 28 Tage.

Was CoreDash-Daten zeigen

Bild-LCP vs. Text-LCP

Seiten mit bildbasierten LCP-Elementen haben einen p75-LCP von 744ms. Das ist fast doppelt so langsam wie textbasierte LCP-Elemente mit 388ms. Der Großteil dieser Lücke entsteht, weil der Browser das Bild spät findet und anfragt (siehe die vier Phasen unten).

Die Auswirkungen von Preloading und Lazy Loading

Vorgeladene (preloaded) LCP-Bilder haben einen p75 von 364ms und keine mangelhaften Seitenaufrufe. LCP-Bilder mit Lazy Loading liegen bei 720ms, wobei 4,3% der Seitenaufrufe als mangelhaft bewertet werden. Bilder ohne Preload liegen bei 752ms. Nutze niemals Lazy Loading für das LCP-Bild. Sorge dafür, dass es früh angefragt wird: direkt im HTML mit fetchpriority="high" oder über Preload, wenn das nicht möglich ist.

Mobile-LCP vs. Desktop-LCP

Der Mobile-LCP (764ms am 75. Perzentil) ist doppelt so hoch wie der Desktop-LCP (380ms). Mobile Netzwerke sind langsamer und Smartphones haben weniger CPU. Google bewertet Mobile und Desktop separat. Mobile ist der Bereich, in dem die meisten Websites scheitern. Fange also dort an.

LCP im gesamten Web

Im CrUX-Release für August 2026 hatten 68,1% der Origins einen guten LCP-Wert, ein Anstieg gegenüber 66,7% im Vorjahr. Das ist immer noch der niedrigste Wert der drei Core Web Vitals (INP 85,3%, CLS 81,5%). Für die meisten Websites entscheidet also der LCP, ob sie bestehen.

Der HTTP Archive Crawl ergänzt das, was CrUX nicht erfasst. Im Web Almanac 2025 ist das LCP-Element auf 76% der mobilen Seiten ein Bild und etwa 16% der Seiten nutzen Lazy Loading dafür. Nur 17% der mobilen Seiten mit einem LCP-Bild verwenden fetchpriority="high". Etwa 2% laden es vor (Preload).

Wie der LCP gemessen wird: Die vier Schlüsselphasen

Laut Google lässt sich der Largest Contentful Paint in 4 Teilbereiche aufteilen. Jede Phase erfordert eine andere Lösung. Finde also zuerst heraus, welche Phase langsam ist. Eine langsame Time to First Byte (TTFB) erfordert serverseitige Arbeit. Ein langsamer Resource Load Delay erfordert Anpassungen in deinem HTML.

Die LCP-Zeit ist die Summe dieser vier Phasen:

• Time to First Byte (TTFB): Die Serverantwortzeit. Sie umfasst alles vom DNS-Lookup über die TCP/TLS-Verbindung bis zu dem Moment, in dem der Browser das erste Byte des HTML-Dokuments empfängt. Eine langsame TTFB verzögert alles, was danach kommt. Der häufigste Grund ist nicht gecachetes HTML, sodass jeder Besuch die Seite in PHP oder Node neu aufbaut. Ein CDN, das das HTML nicht zwischenspeichert, macht nur die Bilder schneller.
• Resource Load Delay: Die Zeit zwischen dem Abschluss der TTFB und dem Moment, in dem der Browser tatsächlich beginnt, die LCP-Ressource herunterzuladen. Eine lange Verzögerung hier bedeutet, dass der Browser die LCP-Ressource spät gefunden hat. Das kommt meist von CSS-Hintergrundbildern (die der Preload-Scanner nicht entdecken kann) oder von Client-Side Rendering (wo das LCP-Element erst erscheint, nachdem JavaScript ausgeführt wurde). Setze das LCP-Element in das initiale HTML. Nutze Preload für das LCP-Bild nur, wenn das nicht möglich ist.
• Resource Load Duration: Wie lange es dauert, die LCP-Ressource (das Bild, den Font oder das Video) herunterzuladen. Diese Phase hängt von Dateigröße und Netzwerk ab: AVIF oder WebP, ein srcset, damit Smartphones ein passendes Bild bekommen. Auf den meisten Websites ist sie die kürzeste der vier Phasen.
• Element Render Delay: Die Zeit zwischen dem Abschluss des Downloads der LCP-Ressource und dem vollständigen Rendern des Elements auf dem Bildschirm. Das Bild ist da, aber der Browser kann es noch nicht zeichnen. Render-Blocking CSS und JavaScript auf dem Main Thread sind die üblichen Gründe. Ein klassisches Beispiel ist ein A/B-Testing-Snippet, das die Seite versteckt, bis das Test-Skript geladen ist.

Google hat echte Chrome-Navigationen mit einem Bild-LCP untersucht und den p75-LCP in diese Phasen aufgeteilt. Der Median der Origins in jeder Gruppe:

Auf Seiten mit einem mangelhaften LCP nehmen TTFB und Load Delay zusammen über 3,5 Sekunden in Anspruch. Das Herunterladen des Bildes dauert 350ms. Die meisten Origins mit einem mangelhaften LCP verbringen weniger als 10% ihres LCP-Werts mit dem Download des LCP-Bildes.

Die Schritte zum Finden und Beheben jeder Phase findest du unter LCP-Probleme identifizieren &amp; beheben.

Häufige LCP-Fehler

Fehler 1: Lazy Loading für das LCP-Bild

loading="lazy" sagt dem Browser, dass er mit dem Download warten soll, bis das Bild in der Nähe des Viewports ist. Das LCP-Bild ist bereits im Viewport. Der Browser muss also erst das Layout berechnen, um das herauszufinden, und startet erst dann den Download. Themes und Page Builder fügen das Attribut oft jedem Bild hinzu, auch dem Hero-Bild. Entferne es vom LCP-Bild. Das ist alles. Laut dem Web Almanac 2025 tun das etwa 16% der Seiten. Lies den Guide dazu, wie man Lazy Loading beim LCP-Bild behebt.

Fehler 2: Das LCP-Bild wird spät gefunden

Ein Slider oder ein clientseitig gerenderter Hero setzt die Bild-URL erst auf die Seite, nachdem das CSS geparst wurde oder JavaScript gelaufen ist. Das kostet hunderte Millisekunden, bevor der Download überhaupt startet. Die beste Lösung ist ein normales <img>-Tag im HTML. Wenn das nicht möglich ist, füge einen Preload-Hint in den <head> ein:

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

Der Browser startet den Download sofort. Ein Preload allein erhöht die Priorität nicht. Behalte also fetchpriority="high" bei, sonst wartet das Bild immer noch hinter Stylesheets und Skripten. Mehr im Guide zum Preloading des LCP-Bildes.

Fehler 3: Ein CSS-Hintergrundbild als LCP-Element

Der Preload-Scanner kann ein background-image: url(...) nicht sehen. Der Browser findet das Bild erst, nachdem er das HTML und das CSS heruntergeladen und die Regel einem Element auf der Seite zugeordnet hat. Das fügt Resource Load Delay hinzu. Die Lösung ist, stattdessen ein Standard-<img>-Tag mit dem Attribut fetchpriority="high" zu verwenden:

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

Jetzt findet der Preload-Scanner es im HTML, und fetchpriority="high" setzt es an die Spitze der Warteschlange. Mehr im Guide zur Ressourcen-Priorisierung.

Wie man den Largest Contentful Paint misst

Den Largest Contentful Paint mit JavaScript messen

Der schnellste Weg ist ein PerformanceObserver. Dieses Snippet loggt die LCP-Zeit und das Element:

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 });

Für mehr als einen schnellen Check nutzt du am besten die Web Vitals Library.

Largest Contentful Paint (LCP) in den Chrome DevTools messen

1. Öffne die Chrome DevTools, indem du Ctrl+Shift+I (oder Cmd+Option+I auf dem Mac) drückst.
2. Gehe in das Performance-Panel. Es zeigt sofort den LCP der aktuellen Seite an, samt LCP-Element.
3. Klicke auf den Reload-Button im Panel, um einen Trace aufzuzeichnen. Die LCP-Markierung im Trace zeigt das LCP-Element und seine vier Phasen.

Die vollständige Anleitung, worauf du im Trace achten musst, findest du unter LCP mit Chrome DevTools diagnostizieren.

Den Largest Contentful Paint mit Lab und Field Tools messen

Lab Data und Field Data haben unterschiedliche Aufgaben. Du brauchst beides.

• Field Data (RUM und CrUX) nutzt Google, um zu entscheiden, ob du bestehst. Es ist das, was deine echten Nutzer erleben. Starte hier, um herauszufinden, ob du ein Problem hast.
• Lab Data (Lighthouse etc.) ist ein kontrollierter Test. Google nutzt es nicht für das Ranking, aber du brauchst es zum Debuggen: Es sagt dir, warum du ein Problem hast.

Die Tools:

Den Largest Contentful Paint verbessern

Nimm dein langsamstes Template für Mobile und sieh dir seine vier LCP-Phasen an: CoreDash zeigt sie pro Seite für echte Besucher, DevTools für einen einzelnen Ladevorgang. In den Field Data oben sind TTFB und Load Delay die großen Blöcke auf fast jeder Seite mit mangelhaftem LCP. Fang also dort an.

Das Hero-Bild in AVIF zu konvertieren, ist das, was jeder zuerst versucht. Auf einer Seite mit 4 Sekunden LCP macht der gesamte Download etwa 350ms aus. Eine kleinere Datei spart also nur einen Bruchteil davon. Mach es, aber mach es zuletzt.

Pro Phase:

• TTFB: Cache das HTML, auf dem Server oder im CDN. Lies mehr in unserem Guide zur TTFB-Optimierung.
• Resource Load Delay: ein <img> im HTML, kein loading="lazy", fetchpriority="high". Siehe Resource Load Delay beheben.
• Resource Load Duration: eine kleinere Datei, passend für das Gerät skaliert. Siehe Wie man das LCP-Bild optimiert. Du kannst auch lesen, wie wir den LCP bei einem echten Projekt um 70% gesenkt haben.
• Element Render Delay: weniger Render-Blocking CSS, Skripte verzögert (deferred), keine Anti-Flicker-Snippets. Siehe Element Render Delay beheben.

Verwandte Guides

Jeder Teil des LCP hat seinen eigenen Guide:

• LCP-Probleme identifizieren &amp; beheben: Finde heraus, welche Phase langsam ist, mit DevTools, WebPageTest und CoreDash.
• LCP mit Chrome DevTools diagnostizieren: Der LCP-Marker in einem Performance-Trace.
• Das LCP-Bild optimieren: Formate, Größen und srcset.
• Resource Load Delay: Das LCP-Bild früh anfragen.
• Resource Load Duration: Der Download an sich.
• Element Render Delay: Wenn das Bild da ist, aber noch nicht gerendert wurde.