Largest Contentful Paint (LCP): Definition & Optimierung (2026)

von

Der Largest Contentful Paint (LCP) misst im Kontext von Google-Rankings, wie viel Zeit vergeht, bis das größte Bild, der größte Textblock oder das größte Video im sichtbaren Bereich gerendert ist, gerechnet ab dem Beginn der Navigation.[1] Er ist eine von drei Core Web Vitals neben INP (Reaktionsfähigkeit) und CLS (visuelle Stabilität) und beschreibt die Ladeperformance.[2]

Als Teil der Core Web Vitals gehört LCP zu den Signalen, die Google zur Optimierung empfiehlt.[2]

  • Für Google hat Relevanz Vorrang; gute Page Experience kann bei vielen Anfragen zum Erfolg beitragen (Wie wichtig ist der LCP?).
  • Entscheidend sind Felddaten, Labortools liefern die Diagnose (Messung und Diagnose).
  • Hebel liegen häufig im Ladeablauf vor dem Bilddownload (Optimierung).

Definition und Einordnung

Was bedeutet LCP genau?

LCP steht für Largest Contentful Paint. Gemessen wird die Zeit bis zum Rendern des größten Elements im Viewport, also im sichtbaren Bereich des Browserfensters. In die Zeit fließen das Entladen der Vorseite, der Verbindungsaufbau, Redirects und der TTFB ein.[1] Der TTFB (Time to First Byte) ist die Zeit von der Navigation bis zum ersten Byte der HTML-Antwort.[3]

Als Kandidaten zählen <img>-Elemente, <image>-Elemente in einem <svg>, <video>-Elemente (Posterbild oder erster Frame, je nachdem, was früher da ist), Elemente mit Hintergrundbild über url() und Blockelemente mit Text. Ein vollständiges <svg> zählt aktuell nicht.[1] Chromium-basierte Browser schließen außerdem Elemente mit Opacity 0, vollflächige Viewport-Elemente und Platzhalterbilder mit geringer Entropie (wenig Bildinformation) aus.[1] Der Browser meldet jedes neue größte Element, ausgewertet wird der zuletzt gemeldete Kandidat. Nach Tap, Scroll oder Tastendruck kommen keine neuen Einträge mehr.[1]

Woher ist der Faktor bekannt und wie sicher ist die Evidenz?

Google bestätigt in der Search-Central-Dokumentation, dass die Rankingsysteme die Core Web Vitals nutzen. Ein einzelnes Page-Experience-Signal gibt es laut Google nicht, die Systeme werten mehrere Signale aus, die zur Gesamterfahrung passen.[4] LCP zählt damit zu den von Google bestätigten Faktoren.

Wie stark LCP im Vergleich zu INP, CLS oder anderen Faktoren wiegt, nennt die Dokumentation nicht, ebenso wenig einen Rankingschwellenwert oder eine Effektgröße. Auch die Mindestzahl an Besuchern, ab der CrUX (der Chrome UX Report, Googles Datensatz mit Erfahrungen echter Chrome-Nutzer) eine Seite aufnimmt, gibt Google nicht an.[5]

Wie wichtig ist der LCP?

Wie stark gewichtet Google den LCP?

Für Google hat Relevanz Vorrang: Die Suche zeigt relevante Inhalte auch bei schwacher Page Experience.[4] Gibt es für eine Anfrage viel hilfreichen Content, kann eine gute Page Experience zum Erfolg beitragen.[4] Bewertet wird überwiegend pro Seite, einzelne Einschätzungen gelten site-weit.[4]

Ob LCP bei dir der richtige Hebel ist, hängt davon ab, wo deine Seite gerade steht. Die Ampel im Abschnitt Messung und Diagnose zeigt es.

Typische Missverständnisse

  • „Ein kleineres Bild macht den LCP schnell.“ Bei den meisten Origins (ganzen Websites) mit schlechtem LCP entfallen laut Googles Auswertung weniger als 10 % der LCP-Zeit am 75. Perzentil auf den Bildabruf. Die meisten LCP-Elemente sind Bilder, der Abruf ist aber selten der Engpass.[6]
  • „Lighthouse zeigt, wie es um mein LCP steht.“ Lighthouse ist laut Google ein Diagnosewerkzeug, sein Performance-Score korreliert oft nicht mit den Core Web Vitals aus dem Feld.[7] Im Feld sehen Nutzer je nach Bildschirmgröße, Login, Personalisierung, A/B-Test, installierten Schriften und Fragment-URLs unterschiedliche LCP-Elemente, Lighthouse liefert immer dasselbe.[8]
  • „Perfekte Core-Web-Vitals-Werte bringen Top-Rankings.“ Gute Ergebnisse im Search-Console-Bericht oder in Drittanbieter-Tools garantieren laut Google keine Spitzenplätze. Perfekte Werte allein für SEO anzustreben, ist womöglich nicht der beste Einsatz deiner Zeit.[4]
  • „Langsame Mobilnetze sind die Hauptursache für lange Bildladezeiten.“ Bei Origins mit schlechtem LCP liegt der Median der Bildladedauer am 75. Perzentil mobil nur 20 % über dem Desktop-Wert.[6]

Messung und Diagnose

Selbstaudit: Wo steht deine Seite?

Die Zeit bis zum LCP besteht aus vier Teilen ohne Lücke und Überschneidung: TTFB, Resource Load Delay (Zeit zwischen TTFB und Start des Ladens der LCP-Ressource), Resource Load Duration (Ladedauer der Ressource) und Element Render Delay (Zeit zwischen Ladeende und vollständigem Rendern des Elements).[3] Braucht das LCP-Element keine Ressource, etwa Text in einer Systemschrift, sind die beiden mittleren Teile null.[3] Für die Anteile nennt Google Richtwerte: TTFB etwa 40 %, Load Duration etwa 40 %, beide Delays unter 10 %. Er rät davon ab, sie in absolute Zeiten umzurechnen.[3]

Prüfpunkt Grün Gelb Rot Beleg
LCP im Feld (75. Perzentil, Mobil und Desktop getrennt) 2,5 s oder weniger über 2,5 s bis 4,0 s über 4,0 s [1] [9] [10]
TTFB Anteil bei etwa 40 % der LCP-Zeit Anteil erkennbar höher So hoch, dass 2,5 s kaum oder nicht erreichbar sind; Ursachen prüfen: mehrere Redirects, weit entfernte Nutzer, schwache Netze, fehlender Cache wegen URL-Parametern [3]
Abstand zwischen TTFB und FCP (First Contentful Paint, erster sichtbarer Inhalt) Klein Erkennbar Groß: viele render-blockierende Assets oder viel Arbeit bis zum ersten Inhalt, typisch für Client-Side-Rendering [3]
Abstand zwischen FCP und LCP Klein Erkennbar Groß: LCP-Ressource nicht sofort verfügbar (etwa per JavaScript gesteuert) oder Browser mit anderer Arbeit ausgelastet [3]
Load Delay und Render Delay Beide unter 10 % der LCP-Zeit Über 10 %, der LCP liegt aber im grünen Bereich Über 10 % und LCP nicht im grünen Bereich [3]
Feld gegen Labor (CrUX gegen Lighthouse) Beide zeigen grob dasselbe Bild Sie weichen ab, Ursachen prüfen Deutliche Abweichung: CrUX gilt als das genauere Bild, Lighthouse-Empfehlungen sind nur eingeschränkt nützlich [3] [7]

Startseiten sind oft die langsamsten Seiten, weil Erstbesucher sie mit leerem Cache laden. Vergleiche URL- und Origin-Werte deshalb getrennt.[3] [7]

Labor- und Feldwerte weichen aus bekannten Gründen ab. Im Feld wirken Cache-Status und der bfcache (Back/Forward-Cache des Browsers), dessen Wiederherstellungen als eigene Seitenaufrufe zählen; Labortests kennen ihn nicht.[1] [8] Im Feld endet die Messung außerdem bei der ersten Interaktion des Nutzers.[8] Elemente in iframes zählt die Metrik, das Browser-API nicht. Das erklärt Abweichungen zwischen CrUX und eigenen RUM-Daten (Real User Monitoring, selbst erhobene Felddaten).[1] Zur Priorisierung solltest du laut Google Felddaten nutzen.[8]

Tools und Datenquellen

Tool Bericht oder Kennzahl wofür
CrUX (Chrome UX Report) Feldwerte am 75. Perzentil, rollierend über 28 Tage Datenbasis vieler Google-Tools; Verbesserungen erscheinen verzögert[7]
PageSpeed Insights Bis zu vier CrUX-Ansichten (Mobil und Desktop, jeweils URL und Origin) plus Lighthouse-Labordaten Erster Überblick; ohne URL-Daten fällt die Ansicht auf die Origin zurück[3]
Search Console Core-Web-Vitals-Bericht mit Feldwerten aus CrUX, gruppiert ähnliche URLs, nur indexierte URLs Muster über Seitengruppen erkennen; nicht zum Prüfen einzelner URLs gedacht; ohne ausreichend Daten Rückfall auf die Origin-Gruppe[10]
Lighthouse Labordaten, Diagnose des LCP-Elements mit Aufschlüsselung der Subparts Ursachen finden[3]
Chrome DevTools (Performance-Panel) Lokaler LCP neben dem CrUX-Wert, Insights mit LCP-Subparts Debugging einzelner Seiten[3]
web-vitals-Bibliothek Eigene Felddaten, Attribution-Build mit Subparts Eigene Felddaten erheben[1] [6]
WebPageTest Labordaten mit Netzwerk-Wasserfall LCP-Element und LCP-Ressource im Ladeablauf finden[3]

CrUX nimmt nur öffentlich auffindbare Seiten auf (Status 200, kein noindex) mit ausreichend Besuchern. Erfasst werden Chrome-Nutzer auf Desktop und Android, die Nutzungsstatistiken melden, den Verlauf synchronisieren und keine Sync-Passphrase gesetzt haben. Chrome unter iOS, Android-WebView und andere Chromium-Browser wie Edge liefern keine Daten.[5] Erreicht deine Seite die Schwelle nicht, bleibt die eigene Erhebung von Felddaten.[7]

Optimierung

Die wichtigsten Hebel

Meist verbessert erst das Zusammenspiel mehrerer Maßnahmen den LCP spürbar, denn eine einzelne Änderung an einem Teil reicht selten.[3] Google rät, anhand der Felddaten zu entscheiden, welchen Teil du zuerst angehst.[3]

  1. LCP-Ressource im HTML auffindbar machen (Quick Win). Der Browser findet die Ressource am schnellsten, wenn src oder srcset des LCP-Bildes im ausgelieferten HTML stehen, weil der Preload-Scanner des Browsers das HTML vorab nach Ressourcen absucht. Nicht auffindbar sind per JavaScript eingefügte Bilder, Lazy-Loading-Bibliotheken, die src in data-src verstecken, und CSS-Hintergrundbilder. Solche Ressourcen bekommen ein Preload mit hoher Priorität: <link rel="preload" fetchpriority="high" as="image" href="/path/to/hero-image.webp" type="image/webp">.[3] Der Median-Origin mit schlechtem LCP wartet etwa 1,3 s zwischen TTFB und Bildanfrage, fast das Vierfache der Downloaddauer. Längere Ketten abhängiger Requests gehen mit längerem LCP einher (Median 2150 ms bei keinem, 2540 ms bei einem und 2850 ms bei zwei abhängigen Requests, HTTP-Archive-Daten).[6]
  2. fetchpriority="high" setzen (Quick Win). Browser laden Bilder standardmäßig nicht mit höchster Priorität, weil sie das Rendern nicht blockieren. Setze fetchpriority="high" auf das <img>, das wahrscheinlich das LCP-Element ist. Bei mehr als ein bis zwei Bildern mit hoher Priorität verliert der Hinweis seine Wirkung.[3]
  3. Render-blockierendes CSS und JavaScript reduzieren (Quick Win). Ein Stylesheet, das länger lädt als die LCP-Ressource, hält das Rendern des Elements auf. Halte es kleiner als die LCP-Ressource: ungenutztes CSS entfernen, Nicht-Kritisches nachladen, Kritisches minifizieren und komprimieren. Inlining lohnt nur bei kleinem CSS, da es nicht gecacht wird. Verzichte auf synchrone Skripte im <head>; sehr kleine Skripte kannst du inlinen.[3]
  4. TTFB senken (Quick Win). Reduziere Redirects, etwa aus Anzeigen oder Kurzlinks. Verhindere, dass eindeutige URL-Parameter, etwa für Analytics, den CDN-Cache umgehen und jede Anfrage zum Ursprungsserver läuft. Das gilt auch dann, wenn die Parameter keine anderen Seiten erzeugen.[3]
  5. Ladedauer der LCP-Ressource senken (Quick Win). Liefere die passende Bildgröße, moderne Formate wie AVIF oder WebP und komprimierte Dateien, verkleinere Webfonts, nutze ein CDN oder Image-CDN und setze effiziente Cache-Header, damit wiederkehrende Besucher die Ressource aus dem Cache erhalten. Ist das LCP-Element Text mit Webfont, setze font-display auf einen anderen Wert als auto oder block, dann wartet der Text nicht auf den Font-Download.[3]
  6. Server-Side-Rendering oder Prerendering einsetzen (Langfristig). Server-Side-Rendering (SSR) macht Bilder im HTML auffindbar und braucht kein nachgeladenes JavaScript für den ersten Inhalt. Die zusätzliche Serverzeit erhöht allerdings den TTFB. Static Site Generation (SSG), also HTML im Build-Schritt erzeugen, ist laut Google meist die bessere Wahl, wenn die Architektur es zulässt.[3]
  7. Lange Tasks aufbrechen (Langfristig). Große JavaScript-Dateien belegen den Main Thread, und Browser rendern Bilder dort. Ein laufendes Skript verzögert deshalb auch das Rendern eines bereits geladenen Bildes. Zerlege Tasks, die den Main Thread lange blockieren.[3]

Umsetzung in Schritten

  1. Rufe in PageSpeed Insights die Felddaten für URL und Origin ab, getrennt nach Mobil und Desktop.
  2. Öffne den Core-Web-Vitals-Bericht der Search Console. Priorisiere zuerst Gruppen mit Status „Poor“, danach nach Zahl der betroffenen URLs oder Wichtigkeit der URLs.[10]
  3. Bestimme mit Lighthouse oder den DevTools das LCP-Element und die vier Subparts.
  4. Setze zuerst dort an, wo weder das HTML noch die LCP-Ressource lädt, also bei den beiden Delays.[3] Arbeite dafür die Hebel 1 bis 4 ab.
  5. Miss die Subparts nach jeder Änderung erneut.
  6. Klicke nach der Umsetzung in der Search Console auf „Start Tracking“. Das startet ein 28-Tage-Monitoring der CrUX-Daten und löst keine Neuindexierung aus.[10]
  7. Beobachte den LCP dauerhaft: Nach Googles Analyse fallen die meisten Performance-Verbesserungen innerhalb von sechs Monaten zurück.[7]

Fallstricke und Grenzen

Typische Fehler

  1. Das LCP-Bild per Lazy-Loading laden. Mit loading="lazy" beginnt der Abruf erst, wenn das Layout das Bild im Viewport bestätigt. Das erzeugt immer unnötige Load Delay und schadet dem LCP.[3]
  2. Die LCP-Ressource von einer fremden Origin laden. Der Browser muss zuerst die Verbindung zu dieser Origin aufbauen. Ein Preconnect mildert die Kosten nur teilweise, am besten kommt die Ressource von derselben Origin wie das HTML, gegebenenfalls über einen CDN-Proxy.[3]
  3. Nur einen Subpart optimieren. Eingesparte Zeit kann in einem anderen Teil landen. Google zeigt das an einer Seite, deren LCP-Element bis zum Laden eines Skripts versteckt ist: Die kleinere Bilddatei verkürzt die Load Duration, der LCP bleibt gleich, weil die Zeit im Render Delay landet. Auch A/B-Test-Bibliotheken, die das Element bis zur Variantenentscheidung ausblenden, verzögern das Rendern.[3]

Zusammenspiel mit anderen Faktoren

  • INP und CLS: Der Status einer URL-Gruppe im Search-Console-Bericht richtet sich nach der schwächsten Metrik. Ein gutes LCP allein ergibt also keinen grünen Status.[10]
  • Weitere Page-Experience-Aspekte wie HTTPS, mobile Darstellung und Interstitials: Sie helfen laut Google nicht direkt beim Ranking, passen aber zu dem, was die Systeme belohnen.[4]
  • TTFB: Die Zeit bis zum ersten Byte ist direkter Bestandteil des LCP (siehe Definition) und wirkt auf jeden Schritt danach.[3]

Häufige Fragen zu LCP

Warum verschlechtert sich mein LCP-Status, obwohl ich nichts geändert habe?

Häufig lagen viele Seiten knapp an einer Schwelle, und ein site-weites Ereignis hat sie darüber geschoben, etwa ein Traffic-Anstieg oder eine höhere Latenz des Dienstes, der deine Bilder ausliefert.[10] Auch ein geänderter Nutzermix mit anderen Browserversionen, Ländern oder langsameren Netzen kann wirken, da der Bericht Daten aller Standorte mischt. Prüfe deine Logs und die Gruppenwerte am Rand der Schwelle.[10]

Warum bewertet Google den LCP am 75. Perzentil?

Am 75. Perzentil erreichen drei von vier Besuchen den Zielwert oder unterbieten ihn. Google wählte es, weil der Wert damit für die Mehrheit gilt und weniger von Ausreißern verzerrt wird, etwa von Besuchen mit instabiler Verbindung.[9] Ein höheres Perzentil hinge stärker von Ausreißern ab, ein niedrigeres sagte weniger über die Mehrheit der Besuche aus.[9]

Woher kommt die Grenze von 2,5 Sekunden?

Google leitete sie aus Forschung zur Wahrnehmung von Wartezeiten und aus der Erreichbarkeit im CrUX-Datensatz ab. Im April 2020 erreichten 42 % der Phone-Origins und 51 % der Desktop-Origins den Wert.[9] Eine perfekte Grenze gibt es laut Google nicht, gewählt wurde der am besten passende von mehreren vertretbaren Kandidaten. Viele Sites profitieren davon, über den Zielwert hinaus zu optimieren.[9]

Wird der LCP gemessen, wenn die Seite im Hintergrund-Tab lädt?

Nein, Google-Tools melden den LCP nicht, wenn die Seite im Hintergrund geladen wurde, weil das nicht der vom Nutzer wahrgenommenen Ladezeit entspricht.[1] Das Browser-API meldet Einträge unter Umständen erst, wenn der Tab in den Vordergrund kommt, und damit lange nach dem eigentlichen Laden.[1]

Fazit

LCP misst, wie schnell der Hauptinhalt sichtbar wird, und ist Teil der Core Web Vitals. Prüfe ihn mit Felddaten, finde die Ursache über die Subparts und setze dort an, wo die Zeit vor dem Laden von HTML und Ressource verloren geht. Relevanz hat bei Google Vorrang, gute Page Experience kann bei vielen Anfragen dazu beitragen, dass deine Seite vorn landet.

Quellen

  1. web.dev (Google): Largest Contentful Paint (LCP) (Stand: 04.09.2025). https://web.dev/articles/lcp. Abgerufen am 19.09.2026.
  2. Google Search Central: Understanding Core Web Vitals and Google search results (Stand: 10.12.2025). https://developers.google.com/search/docs/appearance/core-web-vitals. Abgerufen am 19.09.2026.
  3. web.dev (Google): Optimize Largest Contentful Paint (Stand: 31.03.2025). https://web.dev/articles/optimize-lcp. Abgerufen am 19.09.2026.
  4. Google Search Central: Understanding page experience in Google Search results (Stand: 10.12.2025). https://developers.google.com/search/docs/appearance/page-experience. Abgerufen am 19.09.2026.
  5. Chrome for Developers (Google): CrUX methodology (Stand: 20.06.2024). https://developer.chrome.com/docs/crux/methodology. Abgerufen am 19.09.2026.
  6. web.dev Blog (Google): Common misconceptions about how to optimize LCP (Stand: 20.08.2024). https://web.dev/blog/common-misconceptions-lcp. Abgerufen am 19.09.2026.
  7. web.dev (Google): Core Web Vitals workflows with Google tools (Stand: 28.02.2025). https://web.dev/articles/vitals-tools. Abgerufen am 19.09.2026.
  8. web.dev (Google): Why lab and field data can be different (and what to do about it) (Stand: 18.07.2022). https://web.dev/articles/lab-and-field-data-differences. Abgerufen am 19.09.2026.
  9. web.dev (Google): How the Core Web Vitals metrics thresholds were defined (Stand: 07.05.2025). https://web.dev/articles/defining-core-web-vitals-thresholds. Abgerufen am 19.09.2026.
  10. Google Search Console-Hilfe: Core Web Vitals report. https://support.google.com/webmasters/answer/9205520. Abgerufen am 19.09.2026.