Largest Contentful Paint: Das entscheidende Element identifizieren und optimieren

1. LCP als wichtigste Ladezeit-Metrik der Core Web Vitals

Largest Contentful Paint misst den Zeitpunkt, an dem das größte, im initial sichtbaren Bereich der Seite gerenderte Element vollständig dargestellt ist, meist ein Hero-Bild, eine große Überschrift oder ein Block-Level-Textelement. Diese Metrik korreliert nachweislich stark mit dem subjektiven Eindruck von Ladegeschwindigkeit, da sie genau den Moment erfasst, in dem der Hauptinhalt einer Seite für den Nutzer sichtbar und damit nutzbar wird, im Gegensatz zu früheren Metriken wie First Paint, die auch durch für den Nutzer irrelevante, kleine Elemente ausgelöst werden konnten.

Google definiert einen LCP-Wert von 2.5 Sekunden oder darunter als gut, wobei dieser Schwellenwert am 75. Perzentil aller Seitenaufrufe gemessen wird, nicht am Median. Diese Wahl bedeutet, dass auch die langsameren, oft mobilen oder unter schlechteren Netzwerkbedingungen stattfindenden Seitenaufrufe explizit berücksichtigt werden müssen, und eine Optimierung, die nur den Durchschnittsfall verbessert, den tatsächlich gemessenen LCP-Wert unter Umständen kaum verändert.

2. Das LCP-Element pro Seite ermitteln

Welches Element auf einer bestimmten Seite tatsächlich als LCP-Element zählt, lässt sich nicht zuverlässig erraten, sondern muss über die PerformanceObserver-API mit dem Eintragstyp largest-contentful-paint direkt aus dem Browser ausgelesen werden. Dieser Observer feuert bei jedem Kandidaten, der zum bisher größten sichtbaren Element wird, und liefert eine Referenz auf das konkrete DOM-Element über die element-Eigenschaft, sodass sich der tatsächliche LCP-Kandidat programmatisch bestimmen lässt, statt ihn anhand einer visuellen Einschätzung zu vermuten.

In der Produktion ist es sinnvoll, diesen Wert nicht nur einmalig im Labor zu prüfen, sondern kontinuierlich per Real User Monitoring zu erfassen, da sich das LCP-Element je nach Viewport-Größe, geladenen A/B-Test-Varianten oder personalisiertem Content von Aufruf zu Aufruf unterscheiden kann. Das folgende Beispiel zeigt einen minimalen Observer, der bei jedem neuen LCP-Kandidaten das Element und den bisherigen Zeitwert protokolliert.

// LCP-Element und Zeitwert per PerformanceObserver ermitteln
const observer = new PerformanceObserver((entryList) => {
  const entries = entryList.getEntries();
  const letzterEintrag = entries[entries.length - 1];

  console.log('LCP-Kandidat:', letzterEintrag.element);
  console.log('Zeit bis zu diesem Kandidaten:', letzterEintrag.startTime);
  console.log('URL der Ressource (falls Bild):', letzterEintrag.url || 'kein Bild');
});

observer.observe({ type: 'largest-contentful-paint', buffered: true });

// Finalen Wert erst beim ersten Nutzerinteraktions- oder Sichtbarkeitswechsel festschreiben
['keydown', 'click', 'visibilitychange'].forEach((eventName) => {
  addEventListener(eventName, () => observer.takeRecords(), { once: true, capture: true });
});

3. Warum das LCP-Element oft nicht das offensichtliche ist

Ein häufiges Missverständnis ist die Annahme, das LCP-Element sei automatisch das große Hero-Bild ganz oben auf der Seite, obwohl in vielen realen Fällen ein anderes Element diese Rolle einnimmt. Auf einer Blog-Artikelseite kann etwa ein langer, mehrzeiliger Überschriftenblock flächenmäßig größer sein als ein kleineres Header-Bild, wodurch nicht das Bild, sondern der Text zum LCP-Element wird und entsprechend andere Optimierungsmaßnahmen erfordert als eine reine Bildoptimierung.

Noch überraschender wird es bei Seiten mit dynamisch geladenem Content, etwa einem Karussell, das beim initialen Rendern zunächst ein kleines Platzhalterbild zeigt und erst nach dem Laden von JavaScript durch das eigentliche, größere Bild ersetzt wird. In diesem Fall kann der LCP-Zeitpunkt fälschlicherweise auf das kleine Platzhalterbild fallen, obwohl der Nutzer das große Bild als eigentlich relevanten Inhalt wahrnimmt, was zeigt, wie wichtig die programmatische Verifikation über den PerformanceObserver gegenüber einer rein visuellen Einschätzung ist.

4. Die vier Phasen einer LCP-Zeit im Überblick

Sobald das LCP-Element feststeht, lässt sich die gesamte LCP-Zeit in vier klar abgrenzbare Phasen zerlegen, die jeweils von unterschiedlichen technischen Faktoren beeinflusst werden: Time to First Byte, die Zeit bis zur ersten Serverantwort, Load Delay, die Zeit zwischen TTFB und dem Beginn des Ladens der LCP-Ressource, Load Time, die eigentliche Download-Dauer der Ressource, und Render Delay, die Zeit zwischen abgeschlossenem Download und tatsächlichem Rendern auf dem Bildschirm.

Diese Aufteilung ist deshalb so wertvoll, weil jede Phase durch vollkommen unterschiedliche Maßnahmen verbessert wird und eine pauschale Aussage wie die Seite schneller machen zu wollen ohne Kenntnis der dominanten Phase fast immer an der falschen Stelle ansetzt. Ein Team, das viel Aufwand in die Bildkompression steckt, obwohl in Wirklichkeit die Load-Delay-Phase durch ein blockierendes Skript verursacht wird, verbessert den LCP-Wert kaum, obwohl objektiv wertvolle Arbeit geleistet wurde.

5. Phase eins: TTFB gezielt angehen

Die TTFB-Phase wird primär durch Serverantwortzeit, Netzwerklatenz und die Entfernung zwischen Nutzer und Server bestimmt und ist damit die einzige der vier Phasen, die kaum durch Frontend-Maßnahmen, sondern fast ausschließlich durch Backend- und Infrastrukturentscheidungen beeinflusst wird. Eine langsame Datenbankabfrage, ein überlasteter Applikationsserver oder das Fehlen eines Edge-Caches für häufig aufgerufene Seiten fallen direkt in diese Phase und lassen sich unabhängig von allen anderen LCP-bezogenen Maßnahmen angehen.

Ein CDN mit Edge-Caching für weitgehend statische Seiten, eine Optimierung langsamer Datenbankabfragen und die geografische Nähe des Servers zum Nutzer sind die wirksamsten Hebel gegen eine hohe TTFB-Phase. Für dynamisch generierte, personalisierte Seiten, bei denen vollständiges Caching nicht möglich ist, hilft zusätzlich Streaming SSR, da der Shell bereits gesendet werden kann, während personalisierte Daten im Hintergrund noch geladen werden, was die effektiv wahrgenommene TTFB für das LCP-Element senkt.

6. Phase zwei: Load Delay gezielt angehen

Load Delay entsteht, wenn zwischen dem Eintreffen des HTML-Dokuments und dem tatsächlichen Start des Downloads der LCP-Ressource unnötig viel Zeit vergeht, häufig verursacht durch render-blockierende Skripte oder Stylesheets, die vor der LCP-Ressource geladen werden müssen, oder durch ein spätes Entdecken der Ressource, weil sie erst per JavaScript in den DOM eingefügt wird, statt direkt im initialen HTML zu stehen.

Die wirksamsten Maßnahmen gegen Load Delay sind, die LCP-Ressource direkt und statisch im HTML zu referenzieren, damit sie vom Preload-Scanner sofort erkannt wird, sowie render-blockierende Ressourcen vor der LCP-Ressource zu vermeiden oder zumindest zu verkleinern. Ergänzend hilft ein gezieltes fetchpriority="high" auf dem LCP-Element, um es innerhalb der bereits frühen Erkennung zusätzlich gegenüber konkurrierenden Ressourcen zu bevorzugen.

7. Phase drei: Load Time gezielt angehen

Load Time bezeichnet die reine Download-Dauer der LCP-Ressource selbst, sobald der Request gestartet wurde, und wird primär durch Dateigröße, Kompression und die Bandbreite der Verbindung bestimmt. Für Bild-LCP-Elemente bedeutet das konkret, moderne Formate wie AVIF oder WebP mit angemessener Kompression einzusetzen, die richtige Bildgröße für den tatsächlichen Viewport per srcset auszuliefern und die Ressource über ein CDN mit guter geografischer Abdeckung zu servieren.

Für Text-LCP-Elemente, etwa eine große Überschrift, fällt die Load-Time-Phase meist kaum ins Gewicht, da Text selbst kaum Bytes benötigt, es sei denn, das Rendern des Textes hängt indirekt von einer noch ladenden Webfont ab. In diesem Fall verschiebt sich der eigentliche Engpass faktisch in die Load-Time-Phase der Schriftdatei, weshalb eine Optimierung des Font-Ladens, etwa per preload und einer möglichst kleinen, auf die tatsächlich benutzten Zeichen reduzierten Font-Subset-Datei, hier den größten Hebel darstellt.

8. Phase vier: Render Delay gezielt angehen

Render Delay ist die Zeit zwischen abgeschlossenem Download der LCP-Ressource und ihrem tatsächlichen Erscheinen auf dem Bildschirm, und wird häufig unterschätzt, obwohl sie bei client-seitig gerenderten Anwendungen einen erheblichen Anteil der Gesamtzeit ausmachen kann. Ursachen sind typischerweise ein langer, blockierender JavaScript-Task auf dem Hauptthread, der das eigentliche Rendern verzögert, obwohl die Ressource selbst längst heruntergeladen ist, oder eine ineffiziente CSS-Kaskade, die das finale Layout erst nach mehreren Neuberechnungen stabilisiert.

Die effektivsten Maßnahmen gegen Render Delay sind, lange JavaScript-Tasks in kleinere Einheiten aufzuteilen, damit der Hauptthread nicht über längere Zeiträume blockiert bleibt, und kritisches CSS für den initial sichtbaren Bereich inline auszuliefern statt es aus einer externen, erst noch zu ladenden Datei zu beziehen. Bei React- oder ähnlichen Frameworks hilft zusätzlich, das LCP-Element nicht hinter einer Suspense-Boundary mit künstlicher Verzögerung zu platzieren, wenn es für den ersten sichtbaren Content kritisch ist.

9. Warum phasenbasierte Diagnose besser ist als pauschale Optimierung

Der entscheidende Vorteil einer phasenbasierten Diagnose gegenüber der pauschalen Frage die Seite schneller zu machen ist, dass sich Optimierungsaufwand gezielt auf die tatsächlich dominante Phase konzentrieren lässt, statt gleichmäßig über alle vier Phasen verteilt zu werden, wo er in drei von vier Fällen kaum Wirkung zeigt. Tools wie das Chrome-DevTools-Performance-Panel oder spezialisierte Web-Vitals-Bibliotheken zeigen die vier Phasen mittlerweile explizit als separate Zeitabschnitte an, sodass sich die dominante Phase in wenigen Minuten identifizieren lässt.

In der Praxis bewährt sich ein wiederkehrender Prozess: Nach jeder größeren Änderung an der Seite wird die LCP-Phasenverteilung erneut gemessen, um zu prüfen, ob sich die dominante Phase verschoben hat, etwa weil ein zuvor gutes TTFB durch eine neue, aufwendigere Backend-Logik plötzlich zur größten Phase geworden ist. Diese kontinuierliche, phasenbezogene Kontrolle verhindert, dass Optimierungsaufwand in eine Phase investiert wird, die zwar früher relevant war, mittlerweile aber nicht mehr die eigentliche Ursache der LCP-Zeit ist.

10. Zusammenfassung

11. FAQ: LCP identifizieren und optimieren: Das Wichtigste auf einen Blick