Wenn eine Seite langsam wirkt, zeigt jedes Messwerkzeug denselben einzelnen Wert: den Largest Contentful Paint, kurz LCP. Er verrät, wann das größte sichtbare Element geladen und gerendert ist -- doch als bloße Zahl sagt er nicht, warum es so lange dauert. Genau hier setzen viele Optimierungen falsch an: Sie behandeln das LCP als eine einzige Bremse und probieren wahllos Maßnahmen durch, vom Bildkomprimieren über Preloading bis zum Server-Tuning, ohne zu wissen, welcher Schritt der eigentliche Engpass ist. Der LCP zerfällt aber in vier klar abgegrenzte Teilzeiten, die sogenannten Subparts: die Zeit bis zum ersten Byte (TTFB), die Ladeverzögerung, die Ladezeit und die Renderverzögerung (web.dev). Wer diese vier Phasen einzeln misst, sieht sofort, wo die Zeit tatsächlich vergeht -- und optimiert gezielt statt im Rundumschlag. Dieser Beitrag zerlegt den LCP Schritt für Schritt, ordnet jeder Phase ihren Budget-Anteil zu und zeigt, wie aus der Subpart-Analyse eine priorisierte Maßnahmenliste entsteht. In unserer Core-Web-Vitals-Optimierung steht diese Zerlegung stets am Anfang, bevor wir eine einzige Zeile ändern.
Warum ein einzelner LCP-Wert in die Irre führt
Das LCP ist die anspruchsvollste der drei Core Web Vitals. Während die Reaktionsschnelligkeit und die visuelle Stabilität auf vielen Seiten im grünen Bereich liegen, erreichen nur 62 Prozent (Web Almanac 2025) der mobilen Websites ein gutes LCP unter 2,5 Sekunden. Der Grund ist, dass das LCP von einer ganzen Kette technischer Schritte abhängt -- vom ersten Netzwerkkontakt bis zum fertig gezeichneten Element. Zwei Seiten können denselben Messwert von etwa 3,2 Sekunden aufweisen und trotzdem völlig verschiedene Ursachen haben: Bei der einen kostet die langsame Serverantwort die meiste Zeit, bei der anderen ein spät entdecktes, riesiges Hintergrundbild. Wer nur den Gesamtwert kennt, tappt bei der Ursachensuche im Dunkeln.
Deshalb hat das Chrome-Team ein Modell etabliert, das den LCP in vier aufeinanderfolgende Phasen zerlegt (web.dev). Jede Phase beginnt dort, wo die vorige endet, und zusammen ergeben sie exakt den gemessenen LCP-Wert. Auf einem Zeitstrahl von der Navigation bis zum sichtbaren Element folgen sie streng nacheinander: zuerst die Serverzeit, dann die Wartezeit bis zum Start des Downloads, dann der Download selbst und schließlich die Zeit bis zur Darstellung. Diese Aufteilung ist keine Theorie, sondern lässt sich in den gängigen Diagnosewerkzeugen direkt ablesen. Sobald die vier Zahlen vorliegen, ist die wichtigste Frage beantwortet: Welche Phase frisst den größten Anteil -- und verdient damit die erste Maßnahme?
Die vier Subparts des LCP im Überblick
Subpart 1: TTFB -- die Serverzeit bis zum ersten Byte
Die erste Phase ist die Zeit bis zum ersten Byte, kurz TTFB. Sie umfasst alles, was passiert, bevor der Browser das erste Byte des HTML-Dokuments erhält: die DNS-Auflösung, den Verbindungsaufbau samt TLS-Handshake, etwaige Weiterleitungen und vor allem die Denkzeit des Servers, bis er die Antwort erzeugt hat. Als Richtwert sollte die TTFB rund 40 Prozent (web.dev) des gesamten LCP-Budgets nicht überschreiten. Bei einem Ziel von 2,5 Sekunden bedeutet das grob eine TTFB von rund einer Sekunde oder darunter. Ist die Serverantwort langsam, verschiebt sich alles Nachfolgende nach hinten -- kein noch so kleines Bild kann dann ein gutes LCP retten, weil die Ressource erst nach dem ersten Byte überhaupt angefordert werden kann.
Häufige Ursachen für eine hohe TTFB sind ungecachte, dynamisch erzeugte Seiten, langsame Datenbankabfragen, überlastete Hosting-Umgebungen und unnötige Weiterleitungsketten. Gerade Letztere werden oft unterschätzt: Jeder zusätzliche Hop -- von HTTP auf HTTPS, von non-www auf www, von einem alten auf einen neuen Slug -- kostet einen kompletten Roundtrip, bevor das eigentliche Laden beginnt. Wie sich solche Weiterleitungsketten als versteckte Ladebremse auf einen Hop reduzieren lassen, behandeln wir gesondert. Die grundlegenden Server-Hebel -- Caching, schnelleres Hosting, schlanke Backends -- fassen wir im Beitrag zur Serverantwortzeit und TTFB zusammen und in der Server-Optimierung als Leistung.
Subpart 2: die Ladeverzögerung der Ressource
Die zweite Phase ist die tückischste, weil in ihr nichts Produktives geschieht. Die Ladeverzögerung ist die Zeitspanne zwischen dem Eintreffen des ersten Bytes und dem Moment, in dem der Browser tatsächlich beginnt, die LCP-Ressource herunterzuladen. Idealerweise ist diese Spanne nahezu null; als Budget gelten unter 10 Prozent (web.dev) des LCP. In der Praxis ist sie jedoch oft erschreckend groß, weil der Browser die wichtigste Ressource erst spät entdeckt oder zu niedrig einstuft. Jede Millisekunde hier ist verschenkte Zeit, in der die Leitung frei stünde, aber ungenutzt bleibt.
Die typischen Gründe: Das LCP-Bild wird per CSS-Hintergrund geladen und taucht daher nicht im HTML auf, sodass der Browser es erst nach dem Verarbeiten des Stylesheets findet. Oder es steht zwar als Bild im Markup, wird aber standardmäßig mit niedriger Priorität behandelt und hinter Skripte eingereiht. Die Gegenmittel sind gut dokumentiert und kostengünstig: die Ressource früh per Preload anzukündigen, ihr mit einem Priority Hint hohe Priorität zu geben und das LCP-Element nicht ins Lazy Loading zu schieben. Weil hier reine Wartezeit steckt, liefern gerade diese Handgriffe oft die schnellsten Gewinne der gesamten Frontend-Optimierung.
Die Verzögerungen sind verschenkte Zeit
Subpart 3: die reine Ladezeit der Ressource
Die dritte Phase ist die einzige, in der die LCP-Ressource wirklich über die Leitung geht: die Ladezeit. Sie misst, wie lange der Download vom ersten bis zum letzten Byte der Ressource dauert. Als Richtwert gelten hier -- wie bei der TTFB -- rund 40 Prozent (web.dev) des LCP-Budgets. Zusammen teilen sich TTFB und Ladezeit damit etwa 80 Prozent (web.dev) der Zeit; sie sind die beiden produktiven Phasen, in denen tatsächlich Daten fließen. Die Ladezeit hängt direkt von der Dateigröße, dem Bildformat, der Kompression und der verfügbaren Bandbreite ab -- und davon, ob andere Downloads gleichzeitig um dieselbe Leitung konkurrieren.
Der wirksamste Hebel ist fast stets die Größe der Ressource. Ein modernes Format wie AVIF oder WebP, eine an die tatsächliche Darstellungsgröße angepasste Auflösung über srcset und eine passende Kompression reduzieren das Gewicht oft um ein Vielfaches, ohne sichtbaren Qualitätsverlust. Ergänzend sorgt ein CDN dafür, dass die Bytes aus geografischer Nähe kommen und die Leitung nicht durch nebensächliche Downloads verstopft wird. Für wiederkehrende Besucher lässt sich die Ladezeit sogar nahezu auf null senken, wenn die Ressource per Service Worker und Precaching bereits lokal vorliegt. Wichtig bleibt die Reihenfolge: Erst wenn Ladeverzögerung und Renderverzögerung klein sind, lohnt die Feinarbeit an der Ladezeit -- sonst optimiert man an einer Phase, die gar nicht der Engpass ist.
Modernes Bildformat
AVIF und WebP liefern bei vergleichbarer Qualität deutlich kleinere Dateien als ältere Formate. Für das LCP-Bild ist der Umstieg einer der größten Hebel bei der Ladezeit.
Responsive Auflösung
Über srcset und sizes erhält jedes Gerät genau die Bildgröße, die es darstellt. Ein Smartphone lädt so kein Desktop-Bild -- weniger Bytes, kürzere Ladezeit.
Auslieferung über ein CDN
Ein Content Delivery Network verkürzt die Wege, verteilt die Last und hält die Leitung frei. Die LCP-Ressource trifft dadurch früher und ohne Konkurrenz ein.
Subpart 4: die Renderverzögerung bis zur Darstellung
Die vierte Phase beginnt, sobald die LCP-Ressource vollständig geladen ist, und endet, wenn das Element tatsächlich auf dem Bildschirm erscheint. Diese Renderverzögerung sollte klein sein -- unter 10 Prozent (web.dev) des Budgets. Ist sie groß, hat der Browser die Ressource zwar in der Hand, kann sie aber nicht zeichnen, weil er anderweitig blockiert ist. Typische Ursachen sind renderblockierendes CSS und JavaScript im Dokumentkopf, lange Aufgaben auf dem Hauptthread, die den Browser beschäftigt halten, sowie Schriften oder Hydration bei clientseitig gerenderten Anwendungen.
Ist das LCP-Element reiner Text statt eines Bildes, entfallen Ladeverzögerung und Ladezeit vollständig -- dann besteht das LCP nur aus TTFB und Renderverzögerung, und Letztere wird zum entscheidenden Hebel. Häufig blockiert eine benutzerdefinierte Web-Schrift die Darstellung, oder ein umfangreiches Skript hält den Hauptthread besetzt. Die Gegenmittel: kritisches CSS inline im Kopf, nicht benötigtes JavaScript aufschieben und lange Aufgaben in kleinere Häppchen zerlegen. Welche Befunde im Diagnosebericht auf ein solches Renderproblem hindeuten und wie man sie sortiert, zeigt unser Beitrag zum Lesen des Lighthouse-Reports.
Das Budget: 40 zu 40 zu unter 20
Aus den vier Richtwerten ergibt sich eine einfache Faustregel für ein gutes LCP: etwa 40 Prozent (web.dev) für die TTFB, etwa 40 Prozent (web.dev) für die Ladezeit und zusammen höchstens 20 Prozent (web.dev) für die beiden Verzögerungen. Anders gesagt: Rund vier Fünftel der Zeit sollten in die beiden produktiven Phasen fließen, in denen der Server antwortet und die Ressource lädt. Der Rest -- die reinen Wartezeiten -- gehört so klein wie möglich gehalten. Diese Verteilung ist kein Naturgesetz, sondern ein Zielkorridor: Er sagt, wo man landen möchte, und macht sofort sichtbar, welche Phase aus dem Rahmen fällt.
| Subpart | Budget-Anteil | Typische Ursache bei Überschreitung | Wichtigster Hebel |
|---|---|---|---|
| TTFB (Serverzeit) | rund 40 % | Ungecachte Seiten, langsame Datenbank, Redirect-Ketten | Caching, Hosting, schlankes Backend |
| Ladeverzögerung | unter 10 % | Spät entdeckte oder niedrig priorisierte Ressource | Preload, Priority Hint, kein Lazy Loading |
| Ladezeit | rund 40 % | Zu große Datei, altes Format, keine Kompression | Modernes Format, srcset, CDN |
| Renderverzögerung | unter 10 % | Renderblockendes CSS/JS, lange Hauptthread-Aufgaben | Kritisches CSS, JavaScript aufschieben |
Der Kern in einem Satz
So messen Sie die vier Phasen konkret
Die Subpart-Aufteilung lässt sich mit frei verfügbaren Werkzeugen ablesen. Der Diagnosebericht von Lighthouse weist den LCP bereits nach den vier Phasen aufgeschlüsselt aus, samt Anteil in Millisekunden. Im Performance-Panel der Chrome-Entwicklerwerkzeuge zeigt der Netzwerk-Wasserfall, wann der Server antwortet, wann die LCP-Ressource startet und wann sie fertig lädt. Die quelloffene web-vitals-Bibliothek liefert in ihrer Attribution-Variante dieselbe Aufschlüsselung sogar aus echten Nutzersitzungen. Wichtig ist, im Labor mit realistischer Drosselung zu messen: Ein schnelles Büronetz verschleiert genau die Verzögerungen, die auf Mobilgeräten am stärksten wehtun.
- Das LCP-Element bestimmen -- per Labortest und Felddaten, nicht per Vermutung
- Den LCP in die vier Subparts aufschlüsseln (Lighthouse oder web-vitals-Attribution)
- Die Phase mit dem größten Zeitanteil identifizieren -- das ist der Engpass
- Zuerst die beiden Verzögerungen prüfen: Sind sie zusammen größer als 20 Prozent?
- Den passenden Hebel wählen und nur diese eine Phase gezielt optimieren
- Nach der Änderung erneut messen -- idealerweise in den Felddaten der echten Nutzer
Labor- und Felddaten ergänzen sich dabei. Ein Labortest zeigt reproduzierbar, wie sich eine Änderung auswirkt; die Felddaten zeigen, was echte Nutzer auf ihren Geräten und Netzen erleben. Weil sich das LCP-Element je nach Bildschirmgröße unterscheiden kann, ist der Blick ins Feld unverzichtbar -- wie sich RUM, CrUX und Performance-Budgets sinnvoll verbinden lassen, vertiefen wir gesondert. Grundsätzlich gilt: Erst wenn dieselbe Phase im Labor und im Feld als Engpass erscheint, ist die Maßnahme sicher priorisiert.
Vom Messwert zur priorisierten Maßnahmenliste
Der eigentliche Wert der Subpart-Analyse liegt in der Priorisierung. Statt einer langen Liste gut gemeinter Empfehlungen entsteht eine Rangfolge: Ganz oben steht die Phase mit dem größten Zeitanteil, darunter die zweitgrößte, und Maßnahmen an bereits schlanken Phasen entfallen ganz. Wenn die TTFB 60 Prozent des LCP frisst, ist das Komprimieren eines ohnehin kleinen Bildes verschwendete Mühe -- der Hebel liegt beim Server. Ist umgekehrt die Serverzeit gut, aber die Ladezeit hoch, führt kein noch so schnelles Backend weiter, sondern nur eine leichtere Ressource. Diese Klarheit spart Aufwand und liefert schneller sichtbare Ergebnisse.
Die Subpart-Analyse verwandelt eine vage Ahnung in eine belastbare Reihenfolge. Wir optimieren nicht alles ein bisschen, sondern die eine Phase, die den Wert wirklich hochtreibt -- und messen danach, ob sich der Engpass verschoben hat.
Genau so gehen wir in einem strukturierten Performance-Audit vor: LCP messen, in die vier Phasen zerlegen, den Engpass benennen und eine nach Wirkung sortierte Maßnahmenliste erstellen -- statt eines teuren Rundumschlags. Häufig verschiebt sich der Engpass nach dem ersten Eingriff, weil dann eine andere Phase dominiert; die Analyse wird deshalb wiederholt, bis alle vier Subparts im Zielkorridor liegen. Welche Leistungen dazugehören und wie ein solches Audit abläuft, zeigt unsere Übersicht der Performance-Leistungen. Wer die drei Core Web Vitals im Zusammenhang verstehen möchte, findet die Einordnung im Beitrag zu den Core Web Vitals 2026.