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

Was ist der Largest Contentful Paint (LCP)?

Der Largest Contentful Paint is eine Messung der Renderzeit des größten Inhaltselements (vom Typ Bild, Video oder Text), das im sichtbaren Teil des Bildschirms dargestellt wird. Der LCP-Wert gibt die Zeit in Millisekunden zwischen dem Anfordern der Seite und dem Anzeigen dieses größten Inhaltselements im sichtbaren Teil der Webseite (above the fold) an.

Geschichte des Largest Contentful Paint

Wenn du darüber nachdenkst, wirkt der LCP vielleicht wie ein trivialer Messwert, um den Lade-Teil der Core Web Vitals darzustellen. Warum misst man die Ladegeschwindigkeit nicht einfach als „die Zeit, die die Seite zum Laden braucht“?

Das liegt daran, dass es bei den meisten modernen Webseiten schwierig (oder sogar unmöglich) ist, zu definieren, wann die Seite geladen ist. Immer mehr Webseiten nutzen Techniken wie lazy loading oder progressives Laden, bei denen die Seite im Grunde endlos weiterladen kann. Das bedeutet, dass die Seitengeschwindigkeit nicht durch einen einzelnen Zeitpunkt gemessen werden kann.

Es gibt beim Laden einer Seite mehrere Momente, die dazu führen können, dass ein Nutzer die Seite als schnell oder langsam empfindet. Zum Beispiel sind die Serververzögerung (Time to First Byte), das erste Mal, dass Inhalt sichtbar ist (First Contentful Paint), der Zeitpunkt, an dem der sichtbare Viewport vollständig erscheint (Largest Contentful Paint) und der Moment, in dem die Seite interaktiv wird (wenn das Anklicken eines Links möglich ist), allesamt Punkte während des Ladevorgangs, an denen die Website langsam oder schnell wirken kann!

Der Largest Contentful Paint (LCP) wurde gewählt, weil er sich auf die User Experience des Besuchers konzentriert. Sobald der LCP eintritt, kannst du davon ausgehen, dass der Besucher die Seite als fertig geladen empfindet (selbst wenn im Hintergrund noch Prozesse laufen). Der LCP wurde entwickelt, um folgende Frage zu beantworten: „Wann ist der Inhalt einer Seite sichtbar?“. Deshalb gilt der LCP als zentraler Indikator für nutzerzentrierte Performance.

LCP vs. FCP: Was ist der Unterschied?

Sowohl der Largest Contentful Paint (LCP) als auch der First Contentful Paint (FCP) messen die Ladeleistung, erfassen aber grundlegend unterschiedliche Momente im Ablauf des Seitenladevorgangs. Der FCP wird ausgelöst, sobald der Browser das erste Pixel an Inhalt zeichnet – das kann eine winzige Navigationsleiste oder ein Ladesymbol sein. Der LCP wird ausgelöst, wenn das größte aussagekräftige Element im Viewport gerendert wird.

Stell es dir so vor: Der FCP sagt dir, dass die Seite zu laden begonnen hat; der LCP sagt dir, dass sich die Seite geladen anfühlt. Google hat den LCP als Core Web Vital ausgewählt, weil er die von Nutzern wahrgenommene „Geschwindigkeit“ genauer widerspiegelt.

Für die meisten Webseiten sollte die Optimierung des LCP Priorität haben. Wenn dein LCP schnell ist, wird dein FCP fast immer ebenfalls schnell sein, da der FCP früher im Ladeablauf stattfindet. Umgekehrt gilt das nicht: Ein schneller FCP garantiert keinen schnellen LCP.

Warum der LCP für dein Unternehmen wichtig ist

Der Largest Contentful Paint ist einer der drei Core Web Vitals. Als Core Web Vital ist der Largest Contentful Paint wichtig für SEO, aber noch wichtiger: Der LCP ist entscheidend für die UX. Besucher warten nicht gern. Angesichts des stetig wachsenden mobilen Traffics (der meist langsamer ist als Desktop-Traffic) ist die Optimierung des Largest Contentful Paint absolut sinnvoll.

• Für SEO. Ja, Google konzentriert sich darauf, die besten Seiten in seinen Suchergebnissen anzuzeigen. Der LCP ist Teil von Googles Core Web Vitals. Google sagt ganz klar, dass die Seitengeschwindigkeit ein Faktor für die Suchergebnisse ist.
• Für Besucher: Laut einer aktuellen Google-Studie verdoppelt sich bei einer Ladezeit von 3 Sekunden die Wahrscheinlichkeit, dass ein Nutzer die Seite verlässt. Das kennst du wahrscheinlich von dir selbst. Beim Surfen im Internet gibt es kaum etwas Nervigeres als eine langsam ladende Website. Die Wahrscheinlichkeit ist groß, dass du eine langsam ladende Seite schnell wieder verlässt.
• Weitere Gründe: Die Ladezeit ist ein Faktor für deinen Google Ad Score. Das bedeutet, dass du deine Anzeigen günstiger einkaufen kannst. Zudem ist das Bestehen der Core Web Vitals eine der Voraussetzungen für Googles Top-Stories-Box.

Ein schneller LCP vermittelt dem Besucher das Gefühl, dass die Seite zügig lädt. Dadurch verlässt der Besucher die Seite seltener.

Fallstudie: Vodafone (31 % LCP-Verbesserung, 8 % mehr Verkäufe)

Vodafone Italien führte ein kontrolliertes Experiment zur Optimierung ihres LCP-Werts durch. Durch die Senkung des LCP um 31 % verzeichneten sie einen Anstieg der Verkäufe um 8 %. Das ist keine bloße Korrelation, sondern ein direkter A/B-Test. Er beweist, dass schnelleres gefühltes Laden zu mehr Umsatz führt. Die Optimierung konzentrierte sich auf das Vorladen des LCP-Bildes und das Reduzieren von render blocking Ressourcen. Lies die vollständige Vodafone-Fallstudie auf web.dev.

Fallstudie: Google Flights (fetchpriority sparte 700 ms)

Das Google Flights-Team fügte seinem Hero-Bild fetchpriority="high" hinzu und verbesserte den LCP um 700 Millisekunden. Diese einzelne Änderung des HTML-Attributs war die wirkungsvollste Optimierung in ihrem Performance-Sprint. Das Attribut fetchpriority weist den Browser an, den Download des LCP-Bildes gegenüber anderen Ressourcen zu bevorzugen. Wie das Google Flights-Experiment zeigt, kann der Effekt dramatisch sein. Erfahre mehr über die Ressourcen-Priorisierung für Core Web Vitals.

Welche Elemente gelten als LCP-Elemente?

Nicht alle Elemente kommen als LCP-Element infrage. Das größte Inhaltselement muss auf dem sichtbaren Teil des Bildschirms (dem Viewport) dargestellt werden, bevor der Nutzer mit der Seite interagiert hat.

Das Element muss eines der folgenden sein:

• Ein <img>-Element.
• Ein in ein <svg>-Element geschachteltes <image>-Element.
• Ein <video>-Element (es wird das Poster-Bild oder der erste Video-Frame verwendet, je nachdem, was früher eintrifft).
• Ein Element mit einem Hintergrundbild, das über die CSS-Funktion url() geladen wird. (Hinweis: Dies ist ein Anti-Pattern für die LCP-Optimierung, da das Bild dadurch für den Preload-Scanner des Browsers nicht auffindbar ist. Lies dazu unseren Leitfaden zum Aufschieben von Hintergrundbildern).

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

Aktuell sind bestimmte Elemente als LCP-Kandidaten ausgeschlossen. Dazu gehören mit opacity: 0 ausgeblendete Elemente, Bilder, die 100 % der Viewport-Größe ausfüllen (Cover-Bilder), und Platzhalter (Bilder mit niedriger Entropie). Denk daran: Das kann sich ändern, wenn sich die Spezifikation weiterentwickelt!

Technischer Hintergrund: So wird die LCP-Elementgröße gemessen

Der LCP identifiziert das größte sichtbare Inhaltselement im Viewport und berechnet dessen Größe basierend auf präzisen Regeln. Diese Regeln sorgen für Konsistenz und Genauigkeit, selbst bei komplexen Layouts.

• Nur der Viewport: Nur der sichtbare Teil der Seite wird berücksichtigt. Wenn ein Element nur teilweise im sichtbaren Viewport liegt, wird die berücksichtigte Größe abgeschnitten.
• Keine Rahmen, Paddings oder Margins: Bei allen Elementen werden Rahmen, Padding und Margin von Texten und Bildern komplett ignoriert.
• Textgröße: Textelemente werden als das kleinste Rechteck gemeldet, das um die Textknoten gezeichnet werden kann.
• Bildgröße: Bei Bildern wird der kleinere Wert aus den intrinsischen Abmessungen (die Originalbreite und -höhe) und der Darstellungsgröße (die Größe auf dem Bildschirm) verwendet, um die LCP-Elementgröße zu berechnen.
• Die erste Größe zählt: Wenn sich das Layout oder 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 weiterhin ein LCP-Kandidat.

Die Dynamik des LCP

Der Largest Contentful Paint (LCP) ist ein dynamischer Messwert. Da das Rendern komplex sein und in Phasen ablaufen kann, ist es normal, dass sich das LCP-Element während des Ladevorgangs ändert. Vor der ersten Nutzerinteraktion identifiziert der Performance Observer des Browsers alle Elemente, die als LCP-Kandidaten infrage kommen. Wird ein neues Element gerendert, das sowohl im Viewport sichtbar als auch größer als das zuvor identifizierte LCP-Element ist, wird es zum neuen LCP.

Erkenntnisse aus LCP-field data: Bei CoreDash erfassen wir täglich Millionen von LCP-Einträgen. Es zeigt sich, dass bei mobilen Seitenaufrufen das LCP-Element oft ein textbasiertes Element ist – entweder ein Absatz oder eine Überschrift. Im Durchschnitt (oder genauer gesagt beim 75. Perzentil) werden die Core Web Vitals bestanden, wenn das LCP-Element ein Textknoten oder ein normales Bild ist. Wenn das LCP-Element ein Hintergrundbild, ein Video oder ein Bild mit lazy loading ist, schlagen die Core Web Vitals meistens fehl.

Was ist ein guter LCP-Wert?

Um die Core Web Vitals für den Largest Contentful Paint zu bestehen, müssen mindestens 75 % deiner Besucher einen „guten“ LCP-Wert haben. Ein LCP-Wert zwischen 0 und 2,5 Sekunden gilt als gut, ein LCP-Wert zwischen 2,5 und 4 Sekunden muss verbessert werden und ein LCP-Wert von über 4 Sekunden gilt als schlecht.

Was LCP-Daten aus der Praxis zeigen

CoreDash erfasst täglich Millionen realer LCP-Messungen von Nutzern. Hier ist, was die Daten über die LCP-Performance im gesamten Web verraten.

Bild-LCP vs. Text-LCP

Seiten mit bildbasierten LCP-Elementen haben einen LCP im 75. Perzentil von 744 ms – fast doppelt so langsam wie textbasierte LCP-Elemente mit 388 ms. Dies bestätigt, dass die Bildoptimierung der Hebel mit der größten Wirkung zur Verbesserung von LCP-Werten ist. Wenn dein LCP-Element ein Bild ist, musst du es besonders aggressiv optimieren.

Die Auswirkungen von Vorladen und lazy loading

Vorgeladene LCP-Bilder erreichen zu 100 % „gute“ Werte mit einem 75. Perzentil von 364 ms. Im Gegensatz dazu gehören LCP-Bilder mit lazy loading mit 720 ms zu den langsamsten, wobei 4,3 % der Seitenladevorgänge als „schlecht“ bewertet werden. Nicht vorgeladene Bilder schneiden mit 752 ms fast genauso schlecht ab. Das Fazit ist klar: Lade dein LCP-Bild vor und verwende dafür niemals lazy loading.

Mobiles vs. Desktop-LCP

Der mobile LCP (764 ms im 75. Perzentil) ist doppelt so langsam wie der Desktop-LCP (380 ms). Diese Lücke wird durch langsamere Mobilfunknetze und weniger leistungsfähige Mobilprozessoren verursacht. Da Google Mobile-First-Indexing nutzt, sollte die Optimierung des mobilen LCP die Priorität sein.

Globale LCP-Statistiken

Laut dem HTTP Archive Web Almanac 2025 erreichen weltweit 62 % der mobilen Seiten einen guten LCP-Wert (unter 2,5 Sekunden) – im Vergleich zu 44 % im Jahr 2022. Der LCP ist nach wie vor das am schwersten zu bestehende Core Web Vital und das Hauptnadelöhr für die CWV-Gesamtergebnisse. Zudem sind 73 % der mobilen LCP-Elemente Bilder und 16 % der mobilen Websites nutzen fälschlicherweise lazy loading für ihr LCP-Bild.

So wird der LCP gemessen: Die vier Schlüsselphasen

Laut Google lässt sich der Largest Contentful Paint in vier Teilbereiche unterteilen. Zu verstehen, welche Phase den Flaschenhals verursacht, ist für eine effiziente Optimierung unerlässlich, da jede Phase eine völlig andere Lösung erfordert. Ein langsamer Time to First Byte (TTFB) erfordert serverseitige Anpassungen, während ein langsamer Resource Load Delay Änderungen an deinem HTML benötigt.

Die endgültige LCP-Zeit einer Seite ist kein einzelner, monolithischer Wert. Sie ist die Summe aus vier verschiedenen Teilbereichen. Das Verständnis dieser Aufschlüsselung ist der Schlüssel zur effizienten Diagnose und Behebung von LCP-Problemen.

Hier ist die Aufschlüsselung der vier Phasen:

• Time to First Byte (TTFB): Das ist die reine Server-Antwortzeit. Sie umfasst alles von der DNS-Abfrage über die TCP/TLS-Verbindung bis zu dem Moment, in dem der Browser das erste Byte des HTML-Dokuments empfängt. Ein langsamer TTFB ist ein grundlegendes Problem, das deinen LCP immer ruinieren wird. Im gesamten Web verbringen Websites mit einem schlechten LCP durchschnittlich 2,27 Sekunden allein mit dem TTFB – das ist fast der gesamte Grenzwert von 2,5 Sekunden. Die Optimierung des TTFB umfasst serverseitiges Caching, CDN-Konfiguration und effizienten Backend-Code.
• Resource Load Delay: Das ist die „Entdeckungslücke“. Er misst die Zeit zwischen dem Abschluss des TTFB und dem tatsächlichen Start des Ladevorgangs der LCP-Ressource durch den Browser. Eine lange Verzögerung an dieser Stelle bedeutet, dass der Browser die LCP-Ressource erst spät gefunden hat. Dies ist das klassische Symptom bei der Verwendung von CSS-Hintergrundbildern (die der Preload-Scanner nicht entdecken kann) oder bei Client-Side-Rendering (wo das LCP-Element erst nach der Ausführung von JavaScript erscheint). Die Lösung besteht darin, sicherzustellen, dass sich dein LCP-Element im initialen HTML befindet, und das LCP-Bild vorzuladen, falls der Browser es nicht früh genug entdecken kann.
• Resource Load Duration: Das ist die Dauer für das tatsächliche Herunterladen der LCP-Ressourcendatei (Bild, Schriftart oder Video). In dieser Phase dreht sich alles um Dateigröße und Netzwerkbedingungen. Optimierung bedeutet hier: Nutzung moderner Bildformate wie AVIF oder WebP, Implementierung responsiver Bilder mit srcset und die Bereitstellung von Assets über ein CDN mit angemessener Komprimierung.
• Element Render Delay: Das ist die letzte Verzögerung. Er misst die Zeit zwischen dem Ende des Downloads der LCP-Ressource und dem vollständigen Rendern des Elements auf dem Bildschirm. Diese Verzögerung wird fast immer dadurch verursacht, dass der main thread des Browsers durch andere Aufgaben blockiert wird, insbesondere durch JavaScript-Verarbeitung. Render blocking CSS und synchrone Skripte sind hierfür die häufigsten Ursachen.

Jeder dieser Schwerpunkte kann optimiert werden, um den Largest Contentful Paint zu verbessern. Um zu verstehen, welche Schritte du unternehmen musst, lies LCP-Probleme identifizieren &amp; beheben.

Häufige LCP-Fehler

Nach der Analyse von Millionen von Seitenladevorgängen durch CoreDash treten drei LCP-Fehler weitaus häufiger auf als alle anderen. Das Vermeiden dieser Fehler verhilft den meisten Webseiten zu einem bestandenen LCP-Wert.

Fehler 1: LCP-Bild mit lazy loading laden

Das Hinzufügen von loading="lazy" zu deinem Hero-Bild ist der mit Abstand häufigste LCP-Fehler. lazy loading weist den Browser an, den Download des Bildes absichtlich zu verzögern, bis es in den Viewport gescrollt wird. Für dein LCP-Bild (das sich bereits im Viewport befindet) führt dies zu einer völlig unnötigen Verzögerung. Laut CrUX-Daten machen 16 % der mobilen Websites diesen Fehler. Die Daten von CoreDash zeigen, dass per lazy loading geladene LCP-Bilder im 75. Perzentil bei 720 ms liegen und 4,3 % der Seitenaufrufe als „schlecht“ eingestuft werden – im Vergleich zu 364 ms und 0 % „schlecht“ bei vorab geladenen Bildern. Lies unseren vollständigen Leitfaden zur Behebung eines LCP-Bildes mit lazy loading.

Fehler 2: Kein Vorladen des LCP-Bildes

Selbst ohne lazy loading versäumen es viele Webseiten, den Browser früh genug auf das LCP-Bild hinzuweisen. Wird die Bild-URL erst nach dem Parsen von CSS oder dem Ausführen von JavaScript entdeckt, verschwendet der Browser Hunderte von Millisekunden, bevor er überhaupt mit dem Download beginnt. Die Lösung besteht darin, einen Preload-Hinweis im <head> deines Dokuments hinzuzufügen:

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

Dies weist den Browser an, das Bild sofort herunterzuladen, ohne auf CSS oder Layoutberechnungen zu warten. Kombiniere es mit fetchpriority="high" für maximale Wirkung. Erfahre mehr in unserem Leitfaden zum Vorladen des LCP-Bildes.

Fehler 3: Verwendung eines CSS-Hintergrundbildes für den LCP

CSS-Hintergrundbilder, die über background-image: url(...) geladen werden, sind für den Preload-Scanner des Browsers unsichtbar. Der Browser kann sie erst entdecken, wenn er das HTML heruntergeladen, das CSS geparst und den Render-Tree erstellt hat. Dies führt zu einem erheblichen Resource Load Delay. Laut CrUX-Daten nutzen 9 % der mobilen Seiten ein CSS-Hintergrundbild als LCP-Element. 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">

Das Attribut fetchpriority="high" ist ein direktes Signal an den Browser, dass dieses Bild die Ressource mit der höchsten Priorität auf der Seite ist. Wie die Google Flights-Fallstudie gezeigt hat, kann dieses eine Attribut den LCP um 700 ms senken. Für ein tieferes Verständnis lies unseren Leitfaden zur Ressourcen-Priorisierung.

So misst man den Largest Contentful Paint

Der Largest Contentful Paint (LCP) kann mit reinem JavaScript sowie mit lab data- und field data-Tools gemessen werden. Beide Ansätze haben Vor- und Nachteile.

Den Largest Contentful Paint mit JavaScript messen

Um den Largest Contentful Paint (LCP) mit JavaScript zu messen, bietet die Performance Observer API eine schnelle Lösung. Das folgende Code-Snippet zeigt, wie du den LCP-Wert und die Element-Informationen erfassen kannst:

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

Dieses Snippet verfolgt den LCP-Eintrag während der Berichterstellung und gibt seinen Zeitstempel sowie die Element-Details in der Konsole aus. Für umfangreichere Einblicke empfiehlt sich die Nutzung der Web Vitals Library.

Den Largest Contentful Paint (LCP) in den Chrome DevTools messen

1. Öffne die Chrome DevTools durch Drücken von Strg+Shift+I (oder Cmd+Option+I auf dem Mac).
2. Navigiere zum Tab Performance.
3. Lade die Seite neu, um die Core Web Vitals anzuzeigen.

Der Performance-Tab der DevTools zeigt nun Informationen zu den Core Web Vitals an, einschließlich des Zeitpunkts und des Elements des Largest Contentful Paint.

Den Largest Contentful Paint mit lab data und field data messen

Machen wir uns eines klar: lab data und field data dienen zwei völlig unterschiedlichen Zwecken. Du benötigst beide.

• field data (RUM und CrUX) ist die einzige Datenbasis, die für das Bestehen der Core Web Vitals tatsächlich zählt. Sie zeigt, was deine echten Nutzer erleben. Google verwendet diese Daten aus seinem CrUX-Datensatz. Du beginnst hier, um herauszufinden, ob du überhaupt ein Problem hast.
• lab data (Lighthouse etc.) basiert auf einem kontrollierten Test. Google nutzt sie zwar nicht für das Ranking, aber sie ist für das Debugging unerlässlich. Du nutzt sie, um die Ursache deines Problems herauszufinden.

Hier ist ein kurzer Überblick über die wichtigsten Tools:

Für die meisten Webseiten sollte die Optimierung des LCP Priorität haben. Wenn dein LCP schnell ist, wird dein FCP fast immer ebenfalls schnell sein, da der FCP früher im Ladeablauf stattfindet. Umgekehrt gilt das nicht: Ein schneller FCP garantiert keinen schnellen LCP.

Warum der LCP für dein Unternehmen wichtig ist

Der Largest Contentful Paint ist einer der drei Core Web Vitals. Als Core Web Vital ist der Largest Contentful Paint wichtig für SEO, aber noch wichtiger: Der LCP ist entscheidend für die UX. Besucher warten nicht gern. Angesichts des stetig wachsenden mobilen Traffics (der meist langsamer ist als Desktop-Traffic) ist die Optimierung des Largest Contentful Paint absolut sinnvoll.

• Für SEO. Ja, Google konzentriert sich darauf, die besten Seiten in seinen Suchergebnissen anzuzeigen. Der LCP ist Teil von Googles Core Web Vitals. Google sagt ganz klar, dass die Seitengeschwindigkeit ein Faktor für die Suchergebnisse ist.
• Für Besucher: Laut einer aktuellen Google-Studie verdoppelt sich bei einer Ladezeit von 3 Sekunden die Wahrscheinlichkeit, dass ein Nutzer die Seite verlässt. Das kennst du wahrscheinlich von dir selbst. Beim Surfen im Internet gibt es kaum etwas Nervigeres als eine langsam ladende Website. Die Wahrscheinlichkeit ist groß, dass du eine langsam ladende Seite schnell wieder verlässt.
• Weitere Gründe: Die Ladezeit ist ein Faktor für deinen Google Ad Score. Das bedeutet, dass du deine Anzeigen günstiger einkaufen kannst. Zudem ist das Bestehen der Core Web Vitals eine der Voraussetzungen für Googles Top-Stories-Box.

Ein schneller LCP vermittelt dem Besucher das Gefühl, dass die Seite zügig lädt. Dadurch verlässt der Besucher die Seite seltener.

Fallstudie: Vodafone (31 % LCP-Verbesserung, 8 % mehr Verkäufe)

Vodafone Italien führte ein kontrolliertes Experiment zur Optimierung ihres LCP-Werts durch. Durch die Senkung des LCP um 31 % verzeichneten sie einen Anstieg der Verkäufe um 8 %. Das ist keine bloße Korrelation, sondern ein direkter A/B-Test. Er beweist, dass schnelleres gefühltes Laden zu mehr Umsatz führt. Die Optimierung konzentrierte sich auf das Vorladen des LCP-Bildes und das Reduzieren von render blocking Ressourcen. Lies die vollständige Vodafone-Fallstudie auf web.dev.

Fallstudie: Google Flights (fetchpriority sparte 700 ms)

Das Google Flights-Team fügte seinem Hero-Bild fetchpriority="high" hinzu und verbesserte den LCP um 700 Millisekunden. Diese einzelne Änderung des HTML-Attributs war die wirkungsvollste Optimierung in ihrem Performance-Sprint. Das Attribut fetchpriority weist den Browser an, den Download des LCP-Bildes gegenüber anderen Ressourcen zu bevorzugen. Wie das Google Flights-Experiment zeigt, kann der Effekt dramatisch sein. Erfahre mehr über die Ressourcen-Priorisierung für Core Web Vitals.

Welche Elemente gelten als LCP-Elemente?

Nicht alle Elemente kommen als LCP-Element infrage. Das größte Inhaltselement muss auf dem sichtbaren Teil des Bildschirms (dem Viewport) dargestellt werden, bevor der Nutzer mit der Seite interagiert hat.

Das Element muss eines der folgenden sein:

• Ein <img>-Element.
• Ein in ein <svg>-Element geschachteltes <image>-Element.
• Ein <video>-Element (es wird das Poster-Bild oder der erste Video-Frame verwendet, je nachdem, was früher eintrifft).
• Ein Element mit einem Hintergrundbild, das über die CSS-Funktion url() geladen wird. (Hinweis: Dies ist ein Anti-Pattern für die LCP-Optimierung, da das Bild dadurch für den Preload-Scanner des Browsers nicht auffindbar ist. Lies dazu unseren Leitfaden zum Aufschieben von Hintergrundbildern).

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

Aktuell sind bestimmte Elemente als LCP-Kandidaten ausgeschlossen. Dazu gehören mit opacity: 0 ausgeblendete Elemente, Bilder, die 100 % der Viewport-Größe ausfüllen (Cover-Bilder), und Platzhalter (Bilder mit niedriger Entropie). Denk daran: Das kann sich ändern, wenn sich die Spezifikation weiterentwickelt!

Technischer Hintergrund: So wird die LCP-Elementgröße gemessen

Der LCP identifiziert das größte sichtbare Inhaltselement im Viewport und berechnet dessen Größe basierend auf präzisen Regeln. Diese Regeln sorgen für Konsistenz und Genauigkeit, selbst bei komplexen Layouts.

• Nur der Viewport: Nur der sichtbare Teil der Seite wird berücksichtigt. Wenn ein Element nur teilweise im sichtbaren Viewport liegt, wird die berücksichtigte Größe abgeschnitten.
• Keine Rahmen, Paddings oder Margins: Bei allen Elementen werden Rahmen, Padding und Margin von Texten und Bildern komplett ignoriert.
• Textgröße: Textelemente werden als das kleinste Rechteck gemeldet, das um die Textknoten gezeichnet werden kann.
• Bildgröße: Bei Bildern wird der kleinere Wert aus den intrinsischen Abmessungen (die Originalbreite und -höhe) und der Darstellungsgröße (die Größe auf dem Bildschirm) verwendet, um die LCP-Elementgröße zu berechnen.
• Die erste Größe zählt: Wenn sich das Layout oder 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 weiterhin ein LCP-Kandidat.

Die Dynamik des LCP

Der Largest Contentful Paint (LCP) ist ein dynamischer Messwert. Da das Rendern komplex sein und in Phasen ablaufen kann, ist es normal, dass sich das LCP-Element während des Ladevorgangs ändert. Vor der ersten Nutzerinteraktion identifiziert der Performance Observer des Browsers alle Elemente, die als LCP-Kandidaten infrage kommen. Wird ein neues Element gerendert, das sowohl im Viewport sichtbar als auch größer als das zuvor identifizierte LCP-Element ist, wird es zum neuen LCP.

Erkenntnisse aus LCP-field data: Bei CoreDash erfassen wir täglich Millionen von LCP-Einträgen. Es zeigt sich, dass bei mobilen Seitenaufrufen das LCP-Element oft ein textbasiertes Element ist – entweder ein Absatz oder eine Überschrift. Im Durchschnitt (oder genauer gesagt beim 75. Perzentil) werden die Core Web Vitals bestanden, wenn das LCP-Element ein Textknoten oder ein normales Bild ist. Wenn das LCP-Element ein Hintergrundbild, ein Video oder ein Bild mit lazy loading ist, schlagen die Core Web Vitals meistens fehl.

Was ist ein guter LCP-Wert?

Um die Core Web Vitals für den Largest Contentful Paint zu bestehen, müssen mindestens 75 % deiner Besucher einen „guten“ LCP-Wert haben. Ein LCP-Wert zwischen 0 und 2,5 Sekunden gilt als gut, ein LCP-Wert zwischen 2,5 und 4 Sekunden muss verbessert werden und ein LCP-Wert von über 4 Sekunden gilt als schlecht.

Was LCP-Daten aus der Praxis zeigen

CoreDash erfasst täglich Millionen realer LCP-Messungen von Nutzern. Hier ist, was die Daten über die LCP-Performance im gesamten Web verraten.

Bild-LCP vs. Text-LCP

Seiten mit bildbasierten LCP-Elementen haben einen LCP im 75. Perzentil von 744 ms – fast doppelt so langsam wie textbasierte LCP-Elemente mit 388 ms. Dies bestätigt, dass die Bildoptimierung der Hebel mit der größten Wirkung zur Verbesserung von LCP-Werten ist. Wenn dein LCP-Element ein Bild ist, musst du es besonders aggressiv optimieren.

Die Auswirkungen von Vorladen und lazy loading

Vorgeladene LCP-Bilder erreichen zu 100 % „gute“ Werte mit einem 75. Perzentil von 364 ms. Im Gegensatz dazu gehören LCP-Bilder mit lazy loading mit 720 ms zu den langsamsten, wobei 4,3 % der Seitenladevorgänge als „schlecht“ bewertet werden. Nicht vorgeladene Bilder schneiden mit 752 ms fast genauso schlecht ab. Das Fazit ist klar: Lade dein LCP-Bild vor und verwende dafür niemals lazy loading.

Mobiles vs. Desktop-LCP

Der mobile LCP (764 ms im 75. Perzentil) ist doppelt so langsam wie der Desktop-LCP (380 ms). Diese Lücke wird durch langsamere Mobilfunknetze und weniger leistungsfähige Mobilprozessoren verursacht. Da Google Mobile-First-Indexing nutzt, sollte die Optimierung des mobilen LCP die Priorität sein.

Globale LCP-Statistiken

Laut dem HTTP Archive Web Almanac 2025 erreichen weltweit 62 % der mobilen Seiten einen guten LCP-Wert (unter 2,5 Sekunden) – im Vergleich zu 44 % im Jahr 2022. Der LCP ist nach wie vor das am schwersten zu bestehende Core Web Vital und das Hauptnadelöhr für die CWV-Gesamtergebnisse. Zudem sind 73 % der mobilen LCP-Elemente Bilder und 16 % der mobilen Websites nutzen fälschlicherweise lazy loading für ihr LCP-Bild.

So wird der LCP gemessen: Die vier Schlüsselphasen

Laut Google lässt sich der Largest Contentful Paint in vier Teilbereiche unterteilen. Zu verstehen, welche Phase den Flaschenhals verursacht, ist für eine effiziente Optimierung unerlässlich, da jede Phase eine völlig andere Lösung erfordert. Ein langsamer Time to First Byte (TTFB) erfordert serverseitige Anpassungen, während ein langsamer Resource Load Delay Änderungen an deinem HTML benötigt.

Die endgültige LCP-Zeit einer Seite ist kein einzelner, monolithischer Wert. Sie ist die Summe aus vier verschiedenen Teilbereichen. Das Verständnis dieser Aufschlüsselung ist der Schlüssel zur effizienten Diagnose und Behebung von LCP-Problemen.

Hier ist die Aufschlüsselung der vier Phasen:

• Time to First Byte (TTFB): Das ist die reine Server-Antwortzeit. Sie umfasst alles von der DNS-Abfrage über die TCP/TLS-Verbindung bis zu dem Moment, in dem der Browser das erste Byte des HTML-Dokuments empfängt. Ein langsamer TTFB ist ein grundlegendes Problem, das deinen LCP immer ruinieren wird. Im gesamten Web verbringen Websites mit einem schlechten LCP durchschnittlich 2,27 Sekunden allein mit dem TTFB – das ist fast der gesamte Grenzwert von 2,5 Sekunden. Die Optimierung des TTFB umfasst serverseitiges Caching, CDN-Konfiguration und effizienten Backend-Code.
• Resource Load Delay: Das ist die „Entdeckungslücke“. Er misst die Zeit zwischen dem Abschluss des TTFB und dem tatsächlichen Start des Ladevorgangs der LCP-Ressource durch den Browser. Eine lange Verzögerung an dieser Stelle bedeutet, dass der Browser die LCP-Ressource erst spät gefunden hat. Dies ist das klassische Symptom bei der Verwendung von CSS-Hintergrundbildern (die der Preload-Scanner nicht entdecken kann) oder bei Client-Side-Rendering (wo das LCP-Element erst nach der Ausführung von JavaScript erscheint). Die Lösung besteht darin, sicherzustellen, dass sich dein LCP-Element im initialen HTML befindet, und das LCP-Bild vorzuladen, falls der Browser es nicht früh genug entdecken kann.
• Resource Load Duration: Das ist die Dauer für das tatsächliche Herunterladen der LCP-Ressourcendatei (Bild, Schriftart oder Video). In dieser Phase dreht sich alles um Dateigröße und Netzwerkbedingungen. Optimierung bedeutet hier: Nutzung moderner Bildformate wie AVIF oder WebP, Implementierung responsiver Bilder mit srcset und die Bereitstellung von Assets über ein CDN mit angemessener Komprimierung.
• Element Render Delay: Das ist die letzte Verzögerung. Er misst die Zeit zwischen dem Ende des Downloads der LCP-Ressource und dem vollständigen Rendern des Elements auf dem Bildschirm. Diese Verzögerung wird fast immer dadurch verursacht, dass der main thread des Browsers durch andere Aufgaben blockiert wird, insbesondere durch JavaScript-Verarbeitung. Render blocking CSS und synchrone Skripte sind hierfür die häufigsten Ursachen.

Jeder dieser Schwerpunkte kann optimiert werden, um den Largest Contentful Paint zu verbessern. Um zu verstehen, welche Schritte du unternehmen musst, lies LCP-Probleme identifizieren &amp; beheben.

Häufige LCP-Fehler

Nach der Analyse von Millionen von Seitenladevorgängen durch CoreDash treten drei LCP-Fehler weitaus häufiger auf als alle anderen. Das Vermeiden dieser Fehler verhilft den meisten Webseiten zu einem bestandenen LCP-Wert.

Fehler 1: LCP-Bild mit lazy loading laden

Das Hinzufügen von loading="lazy" zu deinem Hero-Bild ist der mit Abstand häufigste LCP-Fehler. lazy loading weist den Browser an, den Download des Bildes absichtlich zu verzögern, bis es in den Viewport gescrollt wird. Für dein LCP-Bild (das sich bereits im Viewport befindet) führt dies zu einer völlig unnötigen Verzögerung. Laut CrUX-Daten machen 16 % der mobilen Websites diesen Fehler. Die Daten von CoreDash zeigen, dass per lazy loading geladene LCP-Bilder im 75. Perzentil bei 720 ms liegen und 4,3 % der Seitenaufrufe als „schlecht“ eingestuft werden – im Vergleich zu 364 ms und 0 % „schlecht“ bei vorab geladenen Bildern. Lies unseren vollständigen Leitfaden zur Behebung eines LCP-Bildes mit lazy loading.

Fehler 2: Kein Vorladen des LCP-Bildes

Selbst ohne lazy loading versäumen es viele Webseiten, den Browser früh genug auf das LCP-Bild hinzuweisen. Wird die Bild-URL erst nach dem Parsen von CSS oder dem Ausführen von JavaScript entdeckt, verschwendet der Browser Hunderte von Millisekunden, bevor er überhaupt mit dem Download beginnt. Die Lösung besteht darin, einen Preload-Hinweis im <head> deines Dokuments hinzuzufügen:

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

Dies weist den Browser an, das Bild sofort herunterzuladen, ohne auf CSS oder Layoutberechnungen zu warten. Kombiniere es mit fetchpriority="high" für maximale Wirkung. Erfahre mehr in unserem Leitfaden zum Vorladen des LCP-Bildes.

Fehler 3: Verwendung eines CSS-Hintergrundbildes für den LCP

CSS-Hintergrundbilder, die über background-image: url(...) geladen werden, sind für den Preload-Scanner des Browsers unsichtbar. Der Browser kann sie erst entdecken, wenn er das HTML heruntergeladen, das CSS geparst und den Render-Tree erstellt hat. Dies führt zu einem erheblichen Resource Load Delay. Laut CrUX-Daten nutzen 9 % der mobilen Seiten ein CSS-Hintergrundbild als LCP-Element. 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">

Das Attribut fetchpriority="high" ist ein direktes Signal an den Browser, dass dieses Bild die Ressource mit der höchsten Priorität auf der Seite ist. Wie die Google Flights-Fallstudie gezeigt hat, kann dieses eine Attribut den LCP um 700 ms senken. Für ein tieferes Verständnis lies unseren Leitfaden zur Ressourcen-Priorisierung.

So misst man den Largest Contentful Paint

Der Largest Contentful Paint (LCP) kann mit reinem JavaScript sowie mit lab data- und field data-Tools gemessen werden. Beide Ansätze haben Vor- und Nachteile.

Den Largest Contentful Paint mit JavaScript messen

Um den Largest Contentful Paint (LCP) mit JavaScript zu messen, bietet die Performance Observer API eine schnelle Lösung. Das folgende Code-Snippet zeigt, wie du den LCP-Wert und die Element-Informationen erfassen kannst:

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

Dieses Snippet verfolgt den LCP-Eintrag während der Berichterstellung und gibt seinen Zeitstempel sowie die Element-Details in der Konsole aus. Für umfangreichere Einblicke empfiehlt sich die Nutzung der Web Vitals Library.

Den Largest Contentful Paint (LCP) in den Chrome DevTools messen

1. Öffne die Chrome DevTools durch Drücken von Strg+Shift+I (oder Cmd+Option+I auf dem Mac).
2. Navigiere zum Tab Performance.
3. Lade die Seite neu, um die Core Web Vitals anzuzeigen.

Der Performance-Tab der DevTools zeigt nun Informationen zu den Core Web Vitals an, einschließlich des Zeitpunkts und des Elements des Largest Contentful Paint.

Den Largest Contentful Paint mit lab data und field data messen

Machen wir uns eines klar: lab data und field data dienen zwei völlig unterschiedlichen Zwecken. Du benötigst beide.

• field data (RUM und CrUX) ist die einzige Datenbasis, die für das Bestehen der Core Web Vitals tatsächlich zählt. Sie zeigt, was deine echten Nutzer erleben. Google verwendet diese Daten aus seinem CrUX-Datensatz. Du beginnst hier, um herauszufinden, ob du überhaupt ein Problem hast.
• lab data (Lighthouse etc.) basiert auf einem kontrollierten Test. Google nutzt sie zwar nicht für das Ranking, aber sie ist für das Debugging unerlässlich. Du nutzt sie, um die Ursache deines Problems herauszufinden.

Hier ist ein kurzer Überblick über die wichtigsten Tools:

Den Largest Contentful Paint verbessern

Die Optimierung des LCP erfordert einen systematischen Ansatz, der alle vier Phasen abdeckt. Alles, was vor der Darstellung des LCP-Elements geschieht – sei es netzwerkbedingt oder CPU-intensiv –, kann den LCP-Wert beeinflussen. Konzentriere dich nicht nur auf eine einzige Lösung, sondern verstehe die gesamte Kette. Hier ist die grundlegende Strategie:

• TTFB optimieren: Dein Server muss schnell sein. Wenn dein TTFB langsam ist, hilft alles andere nichts. Dazu gehören serverseitiges Caching, die Nutzung eines CDN und effizienter Backend-Code. Lies mehr dazu in unserem Leitfaden zur TTFB-Optimierung.
• Resource Load Delay beseitigen: Stelle sicher, dass sich das LCP-Element im initialen HTML befindet, damit der Preload-Scanner des Browsers es sofort finden kann. Vermeide CSS-Hintergrundbilder für den LCP. Lade kritische Bilder vor, die erst spät entdeckt werden. Erfahre in unserem Leitfaden zur Behebung des Resource Load Delay, wie das geht.
• Ressourcen-Ladezeit verkürzen: Mach die LCP-Datei kleiner. Das bedeutet den Einsatz moderner Bildformate wie AVIF, responsiver Bilder und angemessener Komprimierung. Lies unseren vollständigen Leitfaden zur Optimierung des LCP-Bildes. Du kannst auch nachlesen, wie wir den LCP bei einem echten Projekt um 70 % gesenkt haben.
• Element Render Delay verkürzen: Blockiere den main thread nicht länger. Verschiebe unkritisches JavaScript, teile long tasks auf und minimiere render blocking CSS. Dies wird in unserem Leitfaden zur Behebung des Element Render Delay behandelt.

Verwandte Leitfäden

Diese Übersichtsseite behandelt den Largest Contentful Paint auf einer übergeordneten Ebene. Für detaillierte, praxisnahe Anleitungen zu jedem Aspekt der LCP-Optimierung entdecke diese speziellen Leitfäden:

• LCP-Probleme identifizieren &amp; beheben: Eine Schritt-für-Schritt-Anleitung zur Diagnose, um mit Chrome DevTools, WebPageTest und CoreDash genau herauszufinden, was deinen LCP verlangsamt.
• Das LCP-Bild optimieren: Alles über Bildformate, responsive Bilder, Komprimierung und die Bereitstellung des optimalen Bildes für jedes Gerät.
• Resource Load Delay: So stellst du sicher, dass der Browser deine LCP-Ressource so früh wie möglich entdeckt – inklusive Vorladen, fetchpriority und der Vermeidung von CSS-Hintergrundbildern.
• Resource Load Duration: Reduzierung der tatsächlichen Downloadzeit der LCP-Ressource durch Dateigrößenoptimierung, CDN-Konfiguration und moderne Komprimierung.
• Element Render Delay: Beseitigung der Verzögerung zwischen dem Ressourcen-Download und dem Rendern auf dem Bildschirm durch Reduzierung der main thread-Blockierung durch JavaScript und CSS.