Wie sich Largest Contentful Paint in vier lösbare Teile zerlegt

Was ist LCP (Largest Contentful Paint) und was ist ein guter Wert?

Google bewertet Largest Contentful Paint bei 2.5 Sekunden oder weniger als gut, zwischen 2.5 und 4.0 Sekunden als verbesserungswürdig und über 4.0 Sekunden als schlecht, gelesen am 75. Perzentil der Seitenaufrufe und getrennt für Mobile und Desktop bewertet (web.dev, "Largest Contentful Paint (LCP)", aktualisiert 4. September 2025). Die Metrik markiert den Moment, in dem das größte im Viewport sichtbare Bild oder Textblock fertig gerendert war, und das ist der beste Näherungswert des Browsers für den Moment, in dem ein Besucher die Seite als angekommen erlebt. Vergleichen Sie Ihre Zahl zuerst mit 2.5 Sekunden bei p75, denn ein bestandener Durchschnitt mit durchgefallenem p75 ist immer noch eine durchgefallene Seite.

Die Größe wird nur innerhalb des Viewports beurteilt, und bei Bildern meldet der Browser die sichtbare oder die intrinsische Größe, je nachdem, welche kleiner ist.

Welche Elemente können das LCP-Element sein?

Die LCP-Spezifikation zählt fünf Arten von Elementen, der Gewinner auf Ihrer Seite ist also eines davon und nichts anderes. Alles außerhalb dieser Liste, canvas-Elemente und CSS-Verläufe eingeschlossen, kann den Titel nicht übernehmen, egal wie viel Bildschirm es füllt.

Zulässiges Element	Was der Browser misst
<img>	Sichtbare oder intrinsische Größe, je nachdem, welche kleiner ist
<image> innerhalb von <svg>	Dieselbe Regel wie bei <img>
<video>	Das Poster-Bild oder das erste gezeichnete Frame
Jedes Element mit einem url()-Hintergrundbild	Die gezeichnete Fläche des Elements
Blockelemente, die Textknoten enthalten	Das kleinste Rechteck um alle Textknoten

Identifizieren Sie Ihres, bevor Sie irgendetwas anfassen. Die Chrome DevTools benennen das Gewinnerelement im Performance-Panel, und Feld-Tools hängen es an jedes Sample an, was wichtig ist, weil die beiden selten übereinstimmen.

Was sind die vier Teilabschnitte von Largest Contentful Paint?

Google zerlegt Largest Contentful Paint in time to first byte (Zeit bis zum ersten Byte), resource load delay (Wartezeit bis zum Start des Ladens), resource load duration (Ladedauer der Ressource) und element render delay (Wartezeit bis zum Rendern des Elements), vier aufeinanderfolgende Spannen, die zusammen die ganze Metrik ergeben. Das Chrome-Team veröffentlicht in "Optimize Largest Contentful Paint" für jede einen Zielanteil (web.dev, aktualisiert 31. März 2025): etwa 40% für time to first byte, unter 10% für resource load delay, etwa 40% für resource load duration und unter 10% für element render delay. Messen Sie die Anteile, bevor Sie eine Korrektur wählen, denn ein Teilabschnitt, der bereits in seinem Budget liegt, kann die Sekunden nicht zurückgeben, die Sie brauchen.

Teilabschnitt	Was er abdeckt	Zielanteil	Was ihn langsam macht	Die Korrektur
Time to first byte	Navigationsstart bis zum Eintreffen des ersten Bytes der HTML-Antwort	~40%	Weiterleitungsketten, nicht gecachte Origin-Antworten, langsame Backend-Arbeit, Entfernung zum Origin	Weiterleitungen streichen, gecachtes HTML von CDN-Edge-Knoten ausliefern, Backend-Verarbeitungszeit senken
Resource load delay	Erstes Byte bis der Browser mit dem Abruf der LCP-Ressource beginnt	<10%	Das Bild wird nur in CSS oder JS referenziert, der Preload-Scanner sieht es daher nie; loading="lazy" am Hero; Client-seitiges Rendering fügt es zu spät ein	Das LCP-Bild ins initiale HTML setzen, <link rel="preload" fetchpriority="high"> ergänzen, wenn es nur über CSS oder JS erreichbar ist, Lazy Loading am Hero entfernen
Resource load duration	Der Abruf der LCP-Ressource selbst, von Anfang bis Ende	~40%	Zu große oder unkomprimierte Bilder, veraltete Formate, Bandbreitenkonkurrenz, fehlende Cache-Header	Komprimieren und skalieren, AVIF oder WebP ausliefern, über ein CDN bereitstellen, lange Cache-Lebensdauern setzen, kleine Ressourcen inline einbetten
Element render delay	Ressource fertig geladen bis das Element tatsächlich gezeichnet ist	<10%	Renderblockierende Stylesheets und Skripte, lange Main-Thread-Tasks, Hydration, die den ersten Paint blockiert	Blockierendes CSS und JS deferren oder inline einbetten, auf dem Server rendern, lange Tasks aufteilen

Wie teilt sich ein Largest Contentful Paint von 4.2 Sekunden auf die vier Teile auf?

Die Aufteilung macht aus einer nutzlosen Zahl ein eindeutiges Ziel, denn die Metrik ist eine einfache Summe:

LCP = time to first byte + resource load delay + resource load duration + element render delay

Nehmen Sie eine Seite mit einem p75-LCP von 4.2 Sekunden, was schlecht ist. Die Felddaten teilen ihn auf in 0.9s time to first byte, 2.0s resource load delay, 1.0s resource load duration und 0.3s element render delay. Wenden Sie die Zielanteile auf 4.2 Sekunden an, um das Budget jedes Teilabschnitts zu erhalten.

Teilabschnitt	Gemessen	Anteil an 4.2s	Budget bei 4.2s	Urteil
Time to first byte	0.9s	21%	1.68s	Im Budget
Resource load delay	2.0s	48%	0.42s	4.8x darüber
Resource load duration	1.0s	24%	1.68s	Im Budget
Element render delay	0.3s	7%	0.42s	Im Budget

Drei der vier sind gesund. Das Hero-Bild wird erst zwei volle Sekunden nach dem Eintreffen des HTML angefordert, was auf die Erkennung zeigt: Das Bild steckt hinter einer CSS-Regel, hinter einem Skript oder hinter loading="lazy". Es stärker zu komprimieren würde die 1.0s angreifen, die bereits in Ordnung sind, und die Seite bliebe schlecht.

Beheben Sie das Erkennungsproblem, und der resource load delay fällt auf etwa 0.2s. Die neue Summe lautet 0.9 + 0.2 + 1.0 + 0.3 = 2.4s, und die besteht. Eine Änderung, 1.8 Sekunden, kein Bild neu kodiert. Übertragen Sie dieselbe Aufschlüsselung auf Cumulative Layout Shift und Interaction to Next Paint, und entscheiden Sie damit, was für eine konkrete Seite ein guter LCP ist.

Warum wechselt das LCP-Element zwischen Mobile und Desktop?

Das LCP-Element ist das jeweils größte im Viewport dieses Besuchers, eine Seite, die über Breakpoints hinweg umbricht, übergibt den Titel also auf jedem Gerät einem anderen Element. Ein 1200px breites Desktop-Hero-Foto kann auf Mobile durch eine Media Query ausgeblendet sein, wo stattdessen der Textblock der Überschrift zum größten gezeichneten Element wird. Die beiden Zahlen teilen dann keinen Mechanismus: Der Desktop-LCP wird von resource load duration bestimmt, der mobile LCP von time to first byte und element render delay, weil Text keinen eigenen Abruf braucht.

Das ist die Falle hinter den meisten gescheiterten LCP-Arbeiten. Ein Team preloadet das Hero-Bild, sieht den Desktop-LCP sinken und den mobilen p75 sich nicht bewegen, weil dieses Bild auf Mobile nie das LCP-Element war. Google bewertet Mobile und Desktop getrennt, also debuggen Sie sie getrennt: Holen Sie das LCP-Element je Formfaktor aus den Felddaten und rechnen Sie mit zwei verschiedenen Korrekturen. Wenn Text den Titel gewinnt, verschiebt eine renderblockierende Webschrift die ganze Metrik in den element render delay, und keine Bildarbeit rührt sie an.

Gleiche Seite, anderes LCP-Element

DesktopHero-Foto, 1200px breit, gewinnt nach Größe; LCP wird von resource load duration dominiert

MobileEine Media Query blendet den Hero aus, stattdessen gewinnt der Überschrift-Textblock; LCP wird von time to first byte und render delay dominiert

Warum verschlechtert Lazy Loading eines Hero-Bildes den LCP?

loading="lazy" am LCP-Bild fügt immer resource load delay hinzu, weil der Preload-Scanner es beim HTML-Parsing überspringt und der Abruf darauf wartet, dass das Layout läuft und das Element in Viewport-Nähe platziert. Das Chrome-Team sagt das in "Optimize Largest Contentful Paint" unmissverständlich (web.dev, aktualisiert 31. März 2025): "a lazy-loaded LCP image will always lead to unnecessary resource load delay", also: Ein lazy geladenes LCP-Bild führt immer zu unnötigem resource load delay. Die Wartezeit bringt nichts, denn ein Hero above the fold liegt bereits im Viewport.

Der Schaden kommt über Voreinstellungen. Ein CMS oder eine Komponentenbibliothek, die loading="lazy" auf jedes Bild stempelt, liegt bei den 40 unterhalb der Falz richtig und bei dem einen ganz oben falsch. Setzen Sie am Hero loading="eager" und fetchpriority="high", behalten Sie Lazy Loading überall sonst, und bestätigen Sie es dann in Felddaten statt in einem Lab-Lauf.

Wie sehen Sie den LCP, den Ihre echten Besucher bekommen haben?

Felddaten sind die einzige Quelle, die das LCP-Element und die Aufteilung der Teilabschnitte von echten Geräten in echten Netzen meldet, und darum liegt Real User Monitoring unter jeder Zahl auf dieser Seite. Ein Lab-Lauf liefert einen wiederholbaren LCP für eine Maschine, die Sie konfiguriert haben; der p75, der über Ihr Core Web Vitals Urteil entscheidet, stammt aus den Besuchen, die Sie tatsächlich bekommen haben.

Das Gewicht ist die Beschränkung, denn ein Monitoring-Skript, das die Seite verzögert, verfälscht genau die Metrik, die es meldet. Flowsery sammelt Felddaten über ein Skript unter 10 KB, cookiefrei und in der EU gehostet, ohne Daten-Sampling, sodass der p75 aus jeder Sitzung statt aus einem Ausschnitt kommt. Es zeichnet die Sitzung zusammen mit den Timings auf und markiert Rage Clicks, Dead Clicks, JavaScript-Fehler und Abbrüche, was aus einem langsamen p75 eine Aufzeichnung macht, die Sie ansehen können.

Häufig gestellte Fragen

Wird Largest Contentful Paint vor oder nach der Nutzerinteraktion gemessen?

Der Browser meldet ab der ersten Nutzerinteraktion keine neuen LCP-Kandidaten mehr, ob das ein Scroll, ein Tap oder ein Tastendruck ist. Alles, was danach gezeichnet wird, wird nie zum LCP-Element, egal wie groß es ist. Die Grenze hält die Metrik an den initialen Ladevorgang gebunden statt an Inhalte, die der Besucher ins Bild gescrollt hat.

Muss das LCP-Element auf der Seite bleiben?

Nein. Sobald ein Element als largest contentful paint erfasst ist, behält es den Titel, auch wenn es aus dem Viewport scrollt oder das DOM ganz verlässt, es sei denn, danach rendert ein größeres Element. Ein Splash-Bild, das nach 500ms verschwindet, setzt trotzdem Ihren LCP, und in einem Karussell gewinnt die erste Folie, während die späteren nichts ändern.

Warum ist mein Lab-LCP schnell und mein Feld-LCP schlecht?

Lab-Tools messen ein Gerät auf einer Verbindung, die Sie konfiguriert haben, und Felddaten messen die Geräte, die Ihr Publikum tatsächlich hat. Ein Lighthouse-LCP von 1.6s und ein Feld-p75 von 4.2s sind beide korrekte Antworten auf verschiedene Fragen. Prüfen Sie eine Korrektur im Lab, entscheiden Sie im Feld, ob die Seite besteht.

Behebt ein CDN Largest Contentful Paint?

Ein CDN senkt zwei der vier Teilabschnitte: time to first byte, indem es das HTML von einem Edge-Knoten nahe am Besucher ausliefert, und resource load duration, indem es das Bild genauso ausliefert. Es tut nichts gegen resource load delay durch späte Erkennung und nichts gegen element render delay durch renderblockierende Skripte. Teilen Sie Ihren LCP zuerst auf, dann ist die Antwort schon sichtbar.

Kann ein Video das LCP-Element sein?

Ja. Video-Elemente sind zulässig, und der Browser misst das Poster-Bild oder das erste gezeichnete Frame. Ein Poster an einem Video above the fold gibt dem Browser etwas zum Zeichnen, bevor die Videodaten eintreffen; ohne Poster wandert der LCP-Titel zu dem, was sonst am größten ist.

Wie viele Samples brauche ich, bevor eine LCP-Zahl etwas bedeutet?

So viele, dass sich das 75. Perzentil nicht mehr bewegt, wenn ein einzelnes ungewöhnliches Gerät auftaucht. Eine Route mit 40 Besuchen pro Woche liefert einen p75, der mit einem einzigen Besucher auf einem langsamen Handy ausschlägt, aggregieren Sie also auf das Seitentemplate oder verbreitern Sie das Zeitfenster. Nach Land und Gerät gleichzeitig aufzuteilen vervielfacht den nötigen Traffic, weil jedes Segment seine eigene Verteilung trägt.

Kann ein CSS-Farbverlauf das LCP-Element sein?

Die LCP-Spezifikation erkennt fünf Arten von Elementen an: Bilder, SVG-Bilder, Videos, Elemente mit einem url()-Hintergrundbild und Textblöcke. CSS-Farbverläufe und Canvas-Elemente liegen außerhalb dieser Liste, keines von beiden kann den Titel gewinnen, egal wie viel vom Viewport es füllt.

Kann eine Überschrift statt eines Bildes zum LCP-Element werden?

Jedes Block-Element mit Textknoten qualifiziert sich dafür, gemessen als das kleinste Rechteck um diese Knoten. Genau das passiert bei mobilen Layouts, wenn eine Media Query das Hero-Foto ausblendet und der Überschrift-Textblock zum größten gerenderten Element wird.

Löst das Komprimieren des Hero-Bilds immer einen langsamen LCP?

Nur wenn resource load duration die Teilphase ist, die ihr Budget überschreitet. Im Beispiel mit 4.2 Sekunden auf dieser Seite lag resource load duration mit 1.0s bereits innerhalb des Budgets, während resource load delay das 4,8-fache überschritt. Stärkeres Komprimieren hätte die Seite genauso schlecht gelassen. Prüfen Sie den Split, bevor Sie das Bild anfassen.

Welchen Anteil am LCP sollte resource load duration einnehmen?

Etwa 40%, denselben Zielanteil wie time to first byte. Die beiden übrigen Teilphasen, resource load delay und element render delay, sollten jeweils unter 10% des Gesamtwerts bleiben.