LCP-Subparts analysieren: Wo die Ladezeit verloren geht

LCP ist eine Summe, kein Messwert

Der Schwellenwert ist bekannt: Websites sollten einen LCP von 2,5 Sekunden oder weniger für mindestens 75 Prozent der Seitenaufrufe anstreben (web.dev, Optimize Largest Contentful Paint). Rund 40 Prozent der Websites im Chrome UX Report verfehlen diesen empfohlenen Schwellenwert (web.dev, The most effective ways to improve Core Web Vitals). Was die Vorgabe verschweigt, ist die Zusammensetzung. Zwei Seiten mit identischem LCP von 3,8 Sekunden können vollkommen unterschiedliche Probleme haben und brauchen entsprechend unterschiedliche Maßnahmen.

Wie verbreitet das Problem ist, zeigt der Blick auf die Gerätegruppen: Im Web Almanac 2025 erreichen 74 Prozent der Desktop-Seiten und 62 Prozent der mobilen Seiten ein gutes LCP; schlechte Werte treten mobil mit 13 Prozent fast doppelt so häufig auf wie auf dem Desktop mit 7 Prozent (HTTP Archive, Web Almanac 2025, Performance). Diese Verteilung sagt allerdings nur, wie viele Seiten ein Problem haben, nicht welches.

Die Spezifikation liefert die Bausteine für die Antwort. Das LargestContentfulPaint-Interface stellt unter anderem loadTime, renderTime, size, url und element bereit (W3C, Largest Contentful Paint, Working Draft vom 13.07.2026). Aus diesen Zeitstempeln, kombiniert mit Navigation- und Resource-Timing-Daten, lässt sich rekonstruieren, wann der Browser das erste Byte des Dokuments erhielt, wann er die LCP-Ressource anforderte, wann deren Download abgeschlossen war und wann das Element schließlich gerendert wurde.

Chrome benennt diese vier Abschnitte in den Performance-Insights explizit als LCP breakdown und formuliert die Handlungsregel knapp: Die Dauer jeder Phase soll so weit wie möglich reduziert werden, besonders die der Delay-Phasen; der überwiegende Teil der LCP-Zeit soll auf das Laden der Ressourcen entfallen, nicht auf Wartezeiten (Chrome for Developers, LCP breakdown). Diese Regel ist der Kern des gesamten Themas.

Die vier Teilstrecken im Einzelnen

Die vier Abschnitte sind lückenlos aneinandergereiht: Jeder beginnt dort, wo der vorherige endet, und ihre Summe ergibt den LCP-Wert. Die folgenden Definitionen stammen aus der Google-Dokumentation (web.dev, Optimize Largest Contentful Paint; Chrome for Developers, LCP breakdown).

Zwei dieser vier Abschnitte sind Wartezeiten (Resource Load Delay, Element Render Delay), zwei sind Arbeit (TTFB, Resource Load Duration). Diese Unterscheidung trägt die gesamte Priorisierung: Wartezeit ist Verschwendung und lässt sich prinzipiell auf nahezu null drücken. Arbeit lässt sich beschleunigen, aber nicht abschaffen.

Die Zielverteilung: 40 / unter 10 / 40 / unter 10

Google nennt für die vier Teilstrecken konkrete Zielanteile am Gesamt-LCP (web.dev, Optimize Largest Contentful Paint). Umgerechnet auf das 2.500-Millisekunden-Budget ergeben sich daraus absolute Richtwerte:

Beide Delay-Anteile zusammen sollen also unter 20 Prozent des LCP bleiben — bei einem 2,5-Sekunden-Budget rund 500 Millisekunden für beide Wartezeiten gemeinsam. Google formuliert dazu unmissverständlich: Der überwiegende Teil der LCP-Zeit soll auf das Laden des HTML-Dokuments und der LCP-Quelle entfallen (web.dev, Optimize Largest Contentful Paint). Wichtig ist die Einordnung, die Google selbst mitliefert: Diese Aufteilungen sind Richtwerte, keine strikten Regeln (web.dev).

Was Felddaten stattdessen zeigen

Google hat die vier Teilstrecken über den Chrome UX Report ausgewertet und die Origins nach ihrer LCP-Bewertung gruppiert. Die folgenden Werte sind jeweils der Median über alle Origins einer Gruppe, gebildet aus dem 75. Perzentil jeder einzelnen Teilstrecke je Origin (web.dev, Common misconceptions about how to optimize LCP).

Rechnet man die Anteile aus, kippt das Bild gegenüber der Zielverteilung. Bei Origins mit schlechtem LCP entfallen rund 53 Prozent auf TTFB und rund 30 Prozent auf Resource Load Delay — aber nur rund 8 Prozent auf den Download der LCP-Ressource, also auf genau den Posten, an dem die meisten Optimierungsprojekte ansetzen (eigene Berechnung auf Basis von web.dev, Common misconceptions about how to optimize LCP). Google bestätigt die Größenordnung direkt: Die Mehrheit der Origins mit schlechtem LCP verbringt weniger als 10 Prozent ihrer p75-LCP-Zeit mit dem Download des LCP-Bildes (web.dev).

Ein methodischer Hinweis gehört dazu: Die Summe der vier Medianwerte ist eine Näherung und kein exakter p75-LCP-Wert einer real existierenden Seite. Mediane einzelner Teilstrecken addieren sich nicht sauber zum Median der Summe. Für die Größenverhältnisse — und nur darum geht es hier — ist die Rechnung dennoch belastbar, weil die Abstände zwischen den Teilstrecken erheblich sind.

Die Median-Seite mit schlechtem LCP wartet fast viermal so lange darauf, den Download des LCP-Bildes zu beginnen, wie der Download selbst dauert — 1,3 Sekunden zwischen TTFB und der Anforderung des Bildes.

— web.dev, Common misconceptions about how to optimize LCP (Google), übersetzt

Warum „Bild kleiner machen“ die falsche Antwort ist

Der Reflex ist verständlich. Das LCP-Element ist auf 76 Prozent der mobilen und 85,3 Prozent der Desktop-Seiten ein Bild (HTTP Archive, Web Almanac 2025, Performance). Wenn ein Bild die Metrik bestimmt, liegt es nahe, am Bild zu arbeiten. Die Teilstrecken-Rechnung zeigt, dass diese Schlussfolgerung nicht trägt.

Setzen wir die Medianwerte einer Seite mit schlechtem LCP an — rund 4.270 Millisekunden — und rechnen vier Szenarien durch. Zur Einordnung: Gut ist ein LCP bis 2.500 Millisekunden, verbesserungswürdig bis 4.000 Millisekunden, darüber gilt er als schlecht (web.dev, Optimize Largest Contentful Paint).

1. Das Bild um die Hälfte verkleinern. Die Resource Load Duration sinkt von 350 auf 175 Millisekunden. Neuer LCP: rund 4.095 Millisekunden. Der Wert bleibt in der Kategorie „schlecht“, die Verbesserung beträgt rund 4 Prozent.
2. Das Bild vollständig entfernen. Selbst wenn der Download komplett verschwände, sänke der LCP nur auf rund 3.920 Millisekunden — knapp aus der Kategorie „schlecht“ heraus, aber weiterhin rund 1,4 Sekunden über dem Zielwert. Der theoretisch maximale Gewinn der gesamten Bildoptimierung liegt bei 350 Millisekunden.
3. Den Resource Load Delay eliminieren. Fällt die Wartezeit vor dem Download weg, sinkt der LCP von 4.270 auf rund 2.980 Millisekunden — ein Sprung von „schlecht“ zu „verbesserungswürdig“ durch eine architektonische Änderung, ohne ein einziges Byte am Bild zu ändern.
4. Beides zusammen. Delay eliminiert und Bild halbiert: rund 2.805 Millisekunden. Auch das reicht nicht für ein gutes LCP — weil der größte Posten unberührt bleibt. Bei 2.270 Millisekunden TTFB blieben vom 2.500-Millisekunden-Budget nur 230 Millisekunden für alles Übrige.

Die Rechnung ist bewusst grob, weil die Medianwerte aus unterschiedlichen Verteilungen stammen. Die Rangfolge der Hebel ändert sich dadurch aber nicht: Der Download der LCP-Ressource ist bei schlechtem LCP der kleinste der vier Posten. Wer dort optimiert, verbessert ausgerechnet den Abschnitt, der dem Zielbild ohnehin schon entspricht.

Resource Load Delay: die Teilstrecke, die verschwinden kann

Diese Teilstrecke verdient die meiste Aufmerksamkeit, weil sie strukturell anders ist als die anderen drei. Google bringt den Unterschied auf den Punkt: TTFB lasse sich verbessern, aber jede Verbesserung stoße an physikalische Grenzen — Resource Load Delay lasse sich dagegen potenziell eliminieren und sei in der Praxis nur durch die eigene Auslieferungsarchitektur begrenzt (web.dev, Common misconceptions about how to optimize LCP).

Resource Load Delay ist die Zeit, in der der Browser das LCP-Bild laden könnte, es aber nicht tut — weil er noch nicht weiß, dass es existiert, oder weil ihm signalisiert wurde, es sei unwichtig. Beides sind Entscheidungen der Website, keine Eigenschaften des Netzes. Die typischen Ursachen sind gut vermessen:

• Das Bild steht nicht im HTML. 35 Prozent der LCP-Bilder haben eine Quell-URL, die in der initialen HTML-Antwort nicht auffindbar ist (web.dev, The most effective ways to improve Core Web Vitals, auf Basis des Web Almanac). Der Preload-Scanner des Browsers kann nicht anfordern, was er nicht sieht — das Bild wartet, bis JavaScript oder CSS es nachreichen.
• Das Bild steckt hinter data-src. Rund 5,9 Prozent der mobilen Seiten verbergen ihre LCP-Bildquelle hinter einem data-src-Attribut (HTTP Archive, Web Almanac 2025, Performance). Damit ist der Download zwingend an die Ausführung von JavaScript gekoppelt.
• Das LCP-Element ist verzögert geladen. 16 bis 17 Prozent der Seiten laden ihr LCP-Bild per Lazy-Loading — ein Anteil, der seit 2024 konstant ist (HTTP Archive, Web Almanac 2025, Performance). Google formuliert dazu ungewöhnlich direkt: Das LCP-Bild solle nicht per loading="lazy" geladen werden, weil daraus unnötiger Resource Load Delay entstehe (web.dev, Optimize Largest Contentful Paint).
• Das Bild hat keine Priorität. fetchpriority="high" ist auf 17 Prozent der mobilen Seiten mit LCP-Bild im Einsatz, gegenüber 15 Prozent im Vorjahr (HTTP Archive, Web Almanac 2025, Performance). Ohne diesen Hinweis stuft der Browser das Bild zunächst niedrig ein und stellt es hinter Stylesheets und Skripte zurück.
• Das Bild hängt an einer Anforderungskette. Der Median-LCP steigt von 2.150 Millisekunden ohne vorgelagerte Abhängigkeit auf 2.850 Millisekunden bei zwei Abhängigkeiten (web.dev auf Basis von HTTP-Archive-Daten). Jedes Glied in der Kette ist Wartezeit.

Die Gegenmaßnahmen sind vergleichsweise billig und tragen nicht die Zielkonflikte einer Server-Umstellung: die LCP-Ressource als reguläres img-Element mit auffindbarer src im HTML ausliefern, kein loading="lazy" auf dem LCP-Element, fetchpriority="high" auf dem wahrscheinlichen LCP-Bild setzen und — wo das Bild aus CSS oder JavaScript stammt und nicht ins HTML wandern kann — per link rel="preload" vorziehen (web.dev, Optimize Largest Contentful Paint). Preload wird bislang nur auf 2,1 bis 2,2 Prozent der Seiten eingesetzt (HTTP Archive, Web Almanac 2025, Performance), obwohl es genau für diesen Fall gedacht ist.

Wo diese Attribute von einem Plugin oder Theme gesetzt werden, führt der Weg über dessen Konfiguration — und das setzt voraus, dass die eingesetzten Komponenten samt Version überhaupt bekannt sind. Dieselbe Inventarliste, die für die Priorisierung von Schwachstellen-Feeds wie EUVD und CVE gebraucht wird, zahlt sich hier ein zweites Mal aus.

TTFB: der größte Posten mit der härtesten Grenze

Bei Origins mit schlechtem LCP ist TTFB mit 2.270 Millisekunden der mit Abstand größte Einzelposten, rund 53 Prozent des Gesamtwerts (web.dev, Common misconceptions about how to optimize LCP; eigene Berechnung). Bei Origins mit gutem LCP sind es 600 Millisekunden (web.dev). Der Abstand zwischen beiden Gruppen beträgt 1.670 Millisekunden — mehr als der Abstand bei allen drei übrigen Teilstrecken zusammen, der bei 1.260 Millisekunden liegt (eigene Berechnung auf Basis von web.dev).

TTFB ist damit der wichtigste Posten und zugleich der unbequemste. Er enthält Anteile, die sich nicht wegoptimieren lassen: Die Signallaufzeit zwischen Nutzer und Rechenzentrum ist durch die Lichtgeschwindigkeit begrenzt, der TLS-Handshake braucht Round-Trips, die DNS-Auflösung braucht mindestens eine Abfrage. Was sich bewegen lässt, sind Server-Verarbeitungszeit, Anzahl der Weiterleitungen, Caching-Verhalten und geografische Distanz. Der Beitrag zur systematischen Senkung der Server-Antwortzeit behandelt diese Hebel im Detail; die Wirkung eines CDN auf die Auslieferungsdistanz ist dabei häufig der größte Einzelhebel.

Element Render Delay: der Rest, den niemand misst

Die vierte Teilstrecke ist die unauffälligste und in den Felddaten überraschend stabil: 230 Millisekunden bei gutem, 310 bei verbesserungswürdigem und 360 Millisekunden bei schlechtem LCP (web.dev, Common misconceptions about how to optimize LCP). Der Abstand zwischen bester und schlechtester Gruppe beträgt nur 130 Millisekunden — die geringste Spreizung aller vier Abschnitte.

Das macht Render Delay im Durchschnitt zum kleinsten Hebel, aber nicht zum irrelevanten. Bei Text-LCP — 23,7 Prozent der mobilen und 14,4 Prozent der Desktop-Seiten (HTTP Archive, Web Almanac 2025, Performance) — entfallen Resource Load Delay und Resource Load Duration vollständig, weil keine Ressource geladen werden muss (Chrome for Developers, LCP breakdown). Der LCP besteht dann nur noch aus TTFB und Render Delay, und die gesamte Bildoptimierungs-Debatte geht am Thema vorbei. Die typischen Verursacher:

• Render-blockierende Stylesheets und Skripte. Solange ein blockierendes Asset lädt, rendert der Browser nichts — auch nicht das längst heruntergeladene LCP-Bild.
• Späte Web Fonts. Bei Text-LCP verzögert eine noch nicht geladene Schrift das Rendern des Textes unmittelbar.
• Client-seitiges Rendering und Hydration. Entsteht der Inhalt erst durch JavaScript, verschiebt sich das Rendern hinter die Ausführung des Bundles. Bricht das Bundle, rendert der Inhalt gar nicht — ein Fall für Frontend-Fehler-Monitoring. Bei Single-Page-Anwendungen kommt hinzu, dass Soft Navigations die Messung selbst verändern.
• Blockierter Main Thread. Lange Aufgaben verzögern das Rendern genauso, wie sie Interaktionen und damit INP verzögern — beide Metriken teilen sich hier die Ursache.

Felddaten statt Einzelmessung im Labor

Die gesamte Argumentation dieses Beitrags steht und fällt mit der Datenqualität. Eine einzelne Labormessung auf einer Entwicklermaschine mit Glasfaseranschluss liefert ebenfalls vier Teilstrecken — aber die einer Person, nicht die Ihrer Kunden. Die Zielverteilung gegen einen solchen Einzelwert zu halten, führt systematisch zu falschen Prioritäten, weil Labormessungen die TTFB-Realität schlechter Netze und die Cache-Zustände echter Wiederkehrer nicht abbilden.

Der Chrome UX Report zeigt gut, warum Felddaten strukturell anders sind — und wo ihre Grenzen liegen. Aufgenommen werden nur Nutzer, die Nutzungsstatistiken aktiviert haben, ihren Browserverlauf synchronisieren, keine Sync-Passphrase gesetzt haben und eine unterstützte Plattform verwenden; Chrome auf iOS, Android WebView und andere Chromium-Browser sind ausgeschlossen (Google, Chrome UX Report Dokumentation). Zusätzlich brauchen Origins und einzelne Seiten eine Mindestzahl an Besuchen, um überhaupt aufgenommen zu werden (Google, Chrome UX Report Dokumentation).

Beide Datenquellen haben ihre Berechtigung, und die Unterschiede sind ausführlich im Beitrag zum Vergleich von Feld- und Labordaten beschrieben. Für die Subpart-Priorisierung gilt aber eine klare Reihenfolge: Die Entscheidung, welche Teilstrecke bearbeitet wird, gehört an Felddaten. Die Kontrolle, ob eine Änderung gewirkt hat, gehört zusätzlich ins Labor. Der Lighthouse-Score allein trägt diese Entscheidung nicht, weil er auf einem simulierten Einzellauf beruht.

Das ist der Grund, warum die Web-Vitals-Erfassung in XICTRAQ am echten Besuch ansetzt: Der Tracker misst LCP, CLS und INP im Browser Ihrer Besucher, cookielos und ohne Drittanbieter, mit den Geräten und Verbindungen, die tatsächlich vorkommen. Anders als beim Chrome UX Report entsteht die Verteilung aus Ihrem eigenen Traffic — ohne Mindest-Besucherzahl und ohne den Ausschluss ganzer Browser-Populationen. Wie die Werte im Performance-Tab zusammenlaufen, zeigt die Live-Demo des Dashboards; wie sich daraus Performance-Budgets mit Alarmierung bauen lassen, ist ein eigenes Thema.

Grenzen der Subpart-Analyse

Die Zerlegung ist ein Priorisierungswerkzeug, kein Orakel. Vier Einschränkungen gehören ehrlich dazu:

• Das LCP-Element wechselt. Die Spezifikation sieht vor, dass bei jedem neuen größten Inhalt ein neuer Eintrag erzeugt wird, und der Algorithmus endet, sobald Scroll- oder Eingabe-Ereignisse auftreten (W3C, Largest Contentful Paint, Working Draft vom 13.07.2026). Welches Element am Ende zählt, kann je nach Viewport, Consent-Banner und Scrollverhalten variieren — und damit auch die Zusammensetzung der Teilstrecken.
• Die Teilstrecken sind nicht unabhängig. Ein hoher TTFB verschiebt alle nachfolgenden Abschnitte auf der Zeitachse. Wer TTFB senkt, verändert damit auch, wann der Preload-Scanner arbeitet und wie Prioritäten im Netzwerk-Stack wirken. Die vier Werte lassen sich getrennt messen, aber nicht getrennt optimieren.
• Aggregierte Werte verdecken Segmente. Der Median über Origins beschreibt keinen realen Kunden. Ein guter Gesamtwert kann eine schlechte Mobilfunk-Kohorte enthalten. Umgekehrt ist die Bildladedauer bei Origins mit schlechtem LCP auf Mobilgeräten nur rund 20 Prozent langsamer als auf dem Desktop (web.dev, Common misconceptions about how to optimize LCP) — der große Unterschied zwischen den Gerätegruppen entsteht also anderswo.
• Die Zielverteilung ist ein Richtwert. Google sagt das ausdrücklich (web.dev, Optimize Largest Contentful Paint). Eine Seite mit 1.200 Millisekunden LCP, von denen 70 Prozent auf TTFB entfallen, verletzt die Verteilung und hat trotzdem ein gutes LCP. Die Verteilung wird erst dann interessant, wenn der Gesamtwert die Schwelle reißt.

Die Teilstrecken in die Priorisierung holen

Die praktische Reihenfolge folgt direkt aus den Zahlen und lässt sich als Arbeitsmuster zusammenfassen:

1. Teilstrecken aus Felddaten holen, nicht aus einem Einzellauf. Ohne die Aufteilung ist jede Maßnahme geraten. Das gilt auch, wenn der Gesamtwert grün ist — eine Teilstrecke nahe an ihrer Grenze ist die nächste Regression.
2. Die Delay-Anteile zusammenrechnen. Liegen Resource Load Delay und Element Render Delay gemeinsam über 20 Prozent des LCP, ist dort der erste Hebel — unabhängig davon, wie groß das Bild ist. Bei Origins mit schlechtem LCP liegt dieser Anteil bei rund 39 Prozent (eigene Berechnung auf Basis von web.dev, Common misconceptions about how to optimize LCP).
3. Resource Load Delay zuerst angehen. Diese Teilstrecke hat erfahrungsgemäß das beste Verhältnis aus Aufwand und Wirkung, weil sie architektonisch bedingt ist: LCP-Ressource im HTML auffindbar machen, Lazy-Loading vom LCP-Element nehmen, fetchpriority setzen, Anforderungsketten auflösen.
4. Erst danach TTFB. Der größte Posten, aber der teuerste Umbau. Die Arbeit lohnt sich trotzdem, sobald TTFB mehr als die Hälfte des Budgets frisst — dann führt in der Regel kein anderer Weg zum Ziel.
5. Resource Load Duration zuletzt — es sei denn, die Messung sagt etwas anderes. Macht diese Teilstrecke tatsächlich rund 40 Prozent oder mehr aus, ist Bildoptimierung genau richtig. In den Felddaten schlechter Origins ist sie es mit rund 8 Prozent nicht (web.dev, Common misconceptions about how to optimize LCP; eigene Berechnung).

Die Zerlegung verhindert vor allem eines: Monate an Arbeit, die messbar nichts bewegt. Wer 350 Millisekunden Download optimiert, während 1.290 Millisekunden Wartezeit unangetastet bleiben, arbeitet sorgfältig am kleinsten Posten. Die vier Teilstrecken sind die günstigste verfügbare Information darüber, wo diese Arbeit stattdessen hingehört — und sie kosten nichts außer der Bereitschaft, vor dem Optimieren zu messen.