Largest Contentful Paint verbessern: der LCP-Leitfaden

Largest Contentful Paint (LCP) markiert den Moment, in dem das größte sichtbare Element im Viewport fertig gerendert ist – meistens ein Hero-Bild, eine Produktabbildung oder eine große Überschrift. Von allen Core-Web-Vitals-Metriken kommt LCP dem am nächsten, was ein Mensch als „die Seite ist fertig geladen" empfindet: First Contentful Paint feiert oft nur ein einzelnes Pixel oder eine Ladeanimation, während das vollständige Load-Event auf Skripte wartet, die der Besucher nie zu Gesicht bekommt.

Die gute Nachricht: LCP lässt sich in vier klar abgegrenzte Phasen zerlegen, und für jede Phase gibt es spezifische Stellschrauben. Die schlechte Nachricht: Bevor eine einzige dieser Stellschrauben etwas bringt, muss feststehen, welches Element auf der jeweiligen Seite überhaupt das LCP-Element ist – sonst optimierst du am eigentlichen Problem vorbei.

Was der Largest Contentful Paint misst

LCP misst die Zeit von der Navigation bis zu dem Zeitpunkt, an dem das größte Element innerhalb des sichtbaren Bereichs vollständig gerendert ist. Als Kandidat zählt dabei nicht jedes Element auf der Seite, sondern ausschließlich das größte unter einer festen Auswahl an Elementtypen: img-Tags, das image-Element innerhalb eines SVG, das Poster-Bild eines Video-Elements, Elemente mit einem per CSS gesetzten background-image sowie blockweise Textknoten wie Absätze oder Überschriften.

Der Grund, warum diese Metrik als bester Einzel-Proxy für „gefühlt fertig geladen" gilt, liegt in ihrer Definition: Sie folgt dem größten Element, nicht dem ersten. Eine Seite, die früh nur einen leeren Rahmen oder eine Ladeanimation zeigt, hat zwar einen guten First Contentful Paint, fühlt sich für den Besucher aber trotzdem leer an. Ändert sich das größte Element während des Ladevorgangs – etwa weil ein größeres Bild ein Platzhalterbild ersetzt –, aktualisiert der Browser den LCP-Wert so lange, bis der Nutzer interagiert oder die Seite endgültig steht. Nach den gängigen Richtwerten gilt ein LCP bis 2,5 Sekunden als gut und ab 4 Sekunden als schlecht; dazwischen liegt der verbesserungswürdige Bereich.

Das eigene LCP-Element identifizieren, bevor du optimierst

Der häufigste Grund, warum LCP-Optimierungen wirkungslos bleiben, ist simpel: Es wurde das falsche Element optimiert. Ein Team komprimiert das Hero-Bild im Header, während der tatsächliche LCP-Kandidat auf Mobilgeräten eine große Zwischenüberschrift ist, weil das Bild auf schmalen Viewports kaum noch sichtbar oder kleiner als der Textblock ist. Zeit, die in ein Asset investiert wird, das gar nicht gemessen wird, verbessert nichts.

Das richtige Element lässt sich zuverlässig ermitteln: Im Performance-Panel der Chrome DevTools markiert eine LCP-Markierung auf der Zeitleiste genau das gerenderte Element und zeigt es beim Klick im Elements-Panel an. PageSpeed Insights und Lighthouse nennen das Element explizit in der Diagnose „Largest Contentful Paint element". Für echte Nutzerdaten aus der Produktion liefert die web-vitals-JavaScript-Bibliothek (Attribution-Build) das Element pro tatsächlichem Seitenaufruf, nicht nur aus einem einzelnen Labortest.

• Mobile und Desktop getrennt prüfen – das Element unterscheidet sich häufig zwischen den Breakpoints
• Karussells und Slider im Blick behalten, da ein per JavaScript nachgeladenes zweites Bild zum neuen LCP-Element werden kann
• CSS-Hintergrundbilder gesondert betrachten – Tools markieren sie nicht immer so deutlich wie ein img-Tag

Die vier Phasen des LCP im Überblick

Google zerlegt den LCP-Wert in vier aufeinanderfolgende Phasen, und jede davon reagiert auf andere Maßnahmen. Time to First Byte (TTFB) läuft vom Start der Navigation bis zum Eintreffen des ersten Bytes der HTML-Antwort. Die Resource Load Delay beschreibt die Zeit vom Ende des TTFB bis der Browser tatsächlich beginnt, das LCP-Element herunterzuladen – oft verzögert, weil der Browser die Ressource erst spät im HTML oder gar nicht direkt im Markup entdeckt. Die Resource Load Time ist die reine Downloadzeit der Ressource selbst. Und die Render Delay ist die Zeit zwischen fertigem Download und dem tatsächlichen Rendern, blockiert etwa durch Hauptthread-Arbeit oder CSS, das den Seitenaufbau noch aufhält.

Als grobe Faustregel gilt, dass keine dieser vier Phasen mehr als etwa ein Viertel der Gesamtzeit beanspruchen sollte. Für die Praxis heißt das: Wer nur am Bild schraubt, aber eine langsame Serverantwort oder blockierendes CSS ignoriert, optimiert höchstens eine von vier Stellschrauben.

• TTFB → Serverantwortzeit, Caching, Weiterleitungsketten
• Load Delay → frühe Entdeckbarkeit der Ressource, Preload, kein Lazy-Loading
• Load Time → Dateigröße, Kompression, Format, passende Auflösung
• Render Delay → render-blockierendes CSS und JavaScript, Web Fonts, Hauptthread-Auslastung

Serverantwortzeit verbessern (TTFB)

Die TTFB-Phase ist das Fundament, weil sie alle folgenden Phasen nach hinten verschiebt: Kein Bild kann früher laden, als es der Server überhaupt anbietet. Typische Bremsen sind serverseitige Verarbeitungszeit, etwa aufwendige Datenbankabfragen, die bei jedem Seitenaufruf neu berechnet werden, fehlendes oder zu kurz greifendes Caching auf Serverseite sowie die geografische Distanz zwischen Besucher und Server, wenn kein Edge- oder CDN-Knoten in der Nähe steht.

Ein oft übersehener TTFB-Killer sind Weiterleitungsketten: Jede zusätzliche 301- oder 302-Weiterleitung erzwingt einen kompletten Hin- und Rückweg zwischen Browser und Server, bevor überhaupt die erste Zeile HTML ankommt – und damit auch, bevor die drei nachfolgenden LCP-Phasen starten können. Eine einzelne unnötige Weiterleitung auf dem Pfad zur eigentlichen Seite wirkt sich damit auf jede der vier Phasen aus, nicht nur auf die erste.

• Volle Seiten oder zumindest HTML-Fragmente serverseitig oder per Edge-Cache zwischenspeichern
• Datenbankabfragen auf dem kritischen Pfad reduzieren oder vorab berechnen
• Weiterleitungsketten auf ein einziges, direktes Ziel kürzen

Das LCP-Bild vorladen – und Lazy-Loading dabei unbedingt vermeiden

Browser entdecken Ressourcen normalerweise, während der HTML-Parser von oben nach unten durch das Dokument läuft. Steckt das LCP-Bild als background-image in einem externen Stylesheet oder wird es erst nach der JavaScript-Hydration ins DOM eingefügt, weiß der Browser erst spät, dass diese Ressource überhaupt existiert – die Resource Load Delay wächst. Das direkte Gegenmittel ist ein Preload-Hinweis im head-Bereich: link rel="preload" as="image" mit dem entsprechenden href, alternativ das Attribut fetchpriority="high" direkt am img-Tag, damit der Browser den Download gegenüber weniger kritischen Ressourcen vorzieht, sobald er ihn entdeckt.

Der klassische Rückschritt, der genau diesen Gewinn wieder auffrisst, ist Lazy-Loading auf dem LCP-Element selbst. Das Attribut loading="lazy" weist den Browser an, den Download erst zu starten, wenn sich das Element dem sichtbaren Bereich nähert – korrekt für Bilder weiter unten auf der Seite, aber verheerend für ein Bild, das ohnehin schon im ersten Bildschirmbereich sichtbar ist. Diese Regression passiert selten absichtlich: Ein Plugin oder Theme setzt loading="lazy" pauschal auf jedes Bild-Tag einer Seite, inklusive Header-Banner, oder eine kopierte Komponente bringt das Attribut standardmäßig mit.

• Beim tatsächlichen LCP-Element loading="eager" setzen oder das Attribut schlicht weglassen – das ist ohnehin der Browser-Standard
• Bulk-Lazy-Loading-Skripte und Theme-Standardeinstellungen gezielt für das erste Bildschirmbild ausschließen
• Bei responsiven Bildern zusätzlich die passenden srcset-Angaben im Preload-Tag ergänzen, damit der Browser die richtige Variante vorlädt

Bildgröße und moderne Formate

Sobald der Download beginnt, entscheidet die Dateigröße über die Resource Load Time. Ein Bild, das im Markup als Master-Datei in voller Auflösung eingebunden und nur per CSS auf die Anzeigegröße heruntergerechnet wird, überträgt trotzdem die vollen Bytes. Über srcset und sizes liefert der Browser stattdessen automatisch die Variante, die zur tatsächlichen Darstellungsgröße auf dem jeweiligen Gerät passt.

Moderne Formate wie WebP und AVIF komprimieren fotografische Inhalte bei vergleichbarer visueller Qualität deutlich kompakter als klassisches JPEG oder PNG. Für ein Hero-Bild, das ohnehin meist ein Foto ist, lohnt sich der Formatwechsel besonders, weil jede eingesparte Sekunde Ladezeit hier direkt in den LCP-Wert einfließt. Wichtig ist außerdem eine sinnvolle Kompressionsstufe: Verlustfreie Kompression für ein großformatiges Hero-Foto ist in den meisten Fällen unnötig, sichtbare Qualitätsunterschiede zu einer moderaten verlustbehafteten Kompression gibt es für das menschliche Auge kaum.

• srcset und sizes nutzen, statt ein einziges übergroßes Bild per CSS herunterzuskalieren
• WebP oder AVIF als Format für fotografische LCP-Bilder prüfen
• Kompressionsstufe bewusst testen, statt pauschal verlustfrei zu exportieren

Render-Blocker abbauen: CSS und Schriftarten

Selbst ein vollständig heruntergeladenes Bild erscheint nicht sofort, wenn der Browser mit dem Rendern noch warten muss – das ist die Render Delay. Der häufigste Grund ist render-blockierendes CSS im head-Bereich: Der Browser baut den ersten Anstrich erst, nachdem das komplette Stylesheet geparst ist, unabhängig davon, wie schnell das Bild selbst geladen wurde. Kritisches CSS für den sichtbaren Bereich lässt sich inline einbetten, während der Rest asynchron oder verzögert nachgeladen wird.

Ist das LCP-Element ein Textblock statt eines Bildes, entscheidet stattdessen die Schriftart über die Render Delay. Ohne explizite font-display-Angabe blockiert der Browser standardmäßig das Rendern des Textes, bis die Web-Font-Datei eingetroffen ist oder ein Timeout greift. font-display: swap rendert den Text sofort mit einer Fallback-Schrift und tauscht sie aus, sobald die eigentliche Schrift geladen ist; font-display: optional erlaubt dem Browser sogar, die Custom-Schrift für diesen Render komplett zu überspringen, wenn sie nicht rechtzeitig verfügbar ist. Für die tatsächlich verwendete Schrift lohnt sich zusätzlich ein eigener Preload-Hinweis, genau wie beim LCP-Bild.

• Kritisches CSS inline einbetten, restliches Stylesheet asynchron laden
• font-display: swap oder optional statt des Standardverhaltens setzen
• Die tatsächlich für den LCP-Text genutzte Font-Datei gezielt vorladen
• Lange JavaScript-Aufgaben in der Nähe des LCP-Zeitpunkts aufteilen, damit der Hauptthread frei bleibt

Felddaten vs. Labordaten: welche Zahl zählt

Ein Lighthouse-Report oder ein einzelner PageSpeed-Insights-Testlauf liefert Labordaten: eine simulierte Messung unter kontrollierten, meist gedrosselten Netzwerk- und Geräte-Bedingungen, immer aus derselben Umgebung. Das ist nützlich zum Debuggen, weil das Ergebnis reproduzierbar ist und sich Änderungen direkt vergleichen lassen – aber es bleibt eine Momentaufnahme aus genau einem Szenario.

Felddaten stammen dagegen aus dem Chrome UX Report (CrUX): echten Messungen realer Besucher, über alle Geräteklassen, Netzwerke und geografischen Standorte hinweg, aggregiert über einen rollierenden Zeitraum. Für Ranking-Zwecke zieht Google diese Felddaten heran, nicht das Ergebnis eines einzelnen Labortests. Eine Seite kann in einem lokalen Lighthouse-Lauf auf einer schnellen Leitung exzellente Werte zeigen und trotzdem im Feld schlecht abschneiden, weil ein großer Teil der echten Besucher über langsamere Mobilverbindungen oder ältere Geräte zugreift. Wer den eigenen LCP ernsthaft verbessern will, sollte deshalb primär die Felddaten aus der Search Console oder PageSpeed Insights beobachten und Laborwerte nur zur Fehlersuche zwischen einzelnen Änderungen nutzen.

• Labordaten zum Debuggen einzelner Änderungen nutzen
• Felddaten aus dem Chrome UX Report als tatsächlich rankingrelevante Zahl behandeln
• Ergebnisse nach Geräteklasse trennen, da mobile Felddaten oft deutlich schlechter ausfallen als Desktop-Laborwerte