LCP verbessern: wenn der wichtigste Inhalt zu spät erscheint
Kurz gesagt: Der Largest Contentful Paint (LCP) misst, wann der größte sichtbare Inhalt einer Seite erscheint – meist ein Titelbild oder eine große Überschrift. Laut web.dev gilt ein Wert von höchstens 2,5 Sekunden bei mindestens 75 Prozent der Seitenaufrufe als gut. Wer den Wert verbessern will, sollte ihn in vier Teilphasen zerlegen: Serverantwort, Verzögerung bis zum Laden der Ressource, Ladedauer und Verzögerung beim Rendern. Erst dann wird klar, wo die Zeit tatsächlich verloren geht.
Ein schlechter LCP-Wert ist frustrierend, weil er so viele Ursachen haben kann. Oft wird reflexartig das Titelbild stärker komprimiert – und der Wert ändert sich kaum. web.dev beschreibt in seinem Leitfaden „Largest Contentful Paint optimieren“ (abgerufen November 2026), warum: Selten verbessert die schnelle Korrektur eines einzelnen Teils den LCP erheblich. Man muss sich den gesamten Ladevorgang ansehen. Dieser Artikel folgt dem Aufbau des Leitfadens und übersetzt ihn in einen praktischen Ablauf.
Schritt 1: Messen und das LCP-Element finden
Felddaten zuerst
Entscheidend ist, wie die Seite bei echten Besucherinnen und Besuchern lädt, nicht nur auf Ihrem schnellen Bürorechner. PageSpeed Insights liefert neben Felddaten eine Lighthouse-Analyse, die das LCP-Element aufschlüsselt; laut web.dev lassen sich Felddaten auch ins Leistungs-Panel der Chrome-Entwicklertools einbinden, um zu prüfen, ob echte Nutzer betroffen sind. Laut web.dev sind LCP-Ressourcentypen und -Teilphasen auch in den Chrome-UX-Report-Daten (CrUX) verfügbar.
Das LCP-Element identifizieren
Welches Element ist auf Ihrer Seite das größte? Das ist nicht immer offensichtlich: Auf dem Smartphone kann es die Überschrift sein, auf dem Desktop das Titelbild. Das Leistungs-Panel der Chrome-Entwicklertools zeigt laut web.dev lokale und Feld-LCP-Werte und in den Insights eines Traces die Aufschlüsselung in Teilphasen.
Hilfreiche Begleitwerte
web.dev empfiehlt, zusätzlich Time to First Byte (TTFB) und First Contentful Paint (FCP) zu betrachten. Eine große Lücke zwischen TTFB und FCP deutet auf viele renderblockierende Ressourcen oder starkes clientseitiges Rendering hin. Eine große Lücke zwischen FCP und LCP zeigt, dass die LCP-Ressource dem Browser nicht früh genug bekannt ist oder er vorher anderes erledigt.
Schritt 2: Die vier Teilphasen des LCP verstehen
web.dev teilt die LCP-Zeit in vier Teile, die sich ohne Lücken und Überschneidungen zur Gesamtzeit addieren:
- Time to First Byte (TTFB): vom Start des Seitenaufrufs bis zum ersten Byte des HTML-Dokuments.
- Verzögerung beim Laden der Ressource: von der TTFB bis zum Moment, in dem der Browser beginnt, die LCP-Ressource zu laden.
- Dauer des Ressourcenladevorgangs: die Zeit, die das Laden der LCP-Ressource selbst braucht.
- Verzögerung beim Rendern des Elements: vom Ende des Ladens bis zum vollständigen Rendern des LCP-Elements.
Ist das LCP-Element ein Text in einer Systemschrift, sind die Phasen zwei und drei laut web.dev null. Als grobe Richtlinie nennt der Leitfaden etwa 40 Prozent für TTFB, weniger als 10 Prozent für die Ladeverzögerung, etwa 40 Prozent für die Ladedauer und weniger als 10 Prozent für die Renderverzögerung – ausdrücklich als Orientierung, nicht als feste Vorgabe. Wer viel Zeit in einer der beiden Verzögerungsphasen verliert, wird das Ziel von 2,5 Sekunden kaum konstant erreichen.
Ein wichtiger Hinweis aus dem Leitfaden: Optimiert man nur eine Phase, verschiebt sich die gesparte Zeit unter Umständen einfach in eine andere. Ein stärker komprimiertes Bild bringt nichts, wenn das LCP-Element ohnehin per JavaScript ausgeblendet bleibt, bis ein Skript geladen ist.
Schritt 3: Maßnahmen je Phase
Phase 1: Serverantwort beschleunigen
Eine hohe TTFB macht laut web.dev einen LCP von 2,5 Sekunden schwierig oder unmöglich. Häufige Ursachen sind mehrere Weiterleitungen, etwa über Anzeigen oder gekürzte Links, eine große Entfernung zum Server und Inhalte, die ein CDN nicht aus dem Zwischenspeicher ausliefern kann, sodass alle Anfragen beim Ursprungsserver landen. Maßnahmen: Weiterleitungsketten kürzen, Seiten wo möglich zwischenspeichern, ein CDN einsetzen und prüfen, ob Parameter in URLs das Caching verhindern.
Phase 2: Die LCP-Ressource früh entdecken lassen
Die Faustregel von web.dev: Die LCP-Ressource sollte gleichzeitig mit der ersten Ressource der Seite zu laden beginnen. Dafür muss sie im HTML-Quelltext auffindbar sein. Problematisch sind Bilder, die erst per JavaScript eingefügt werden, CSS-Hintergrundbilder und Webfonts, die nur in externen Dateien referenziert sind. Ist das nicht vermeidbar, empfiehlt der Leitfaden, die Ressource per <link rel="preload"> mit hoher Abrufpriorität vorzuladen.
Zwei weitere Punkte: Das LCP-Bild sollte niemals mit loading="lazy" versehen werden, denn das verzögert das Laden immer. Und weil Bilder auch ohne Lazy Loading nicht mit höchster Priorität geladen werden, lässt sich mit dem Attribut fetchpriority="high" signalisieren, welches Bild am wichtigsten ist. Liegt die Ressource auf einem anderen Ursprung, muss der Browser zuerst eine Verbindung aufbauen; wichtige Ressourcen auf derselben Domain wie das HTML zu hosten, spart diese Zeit.
Phase 3: Ladedauer verkürzen
web.dev nennt vier Wege: die Ressource verkleinern, den Weg zum Nutzer verkürzen, die Konkurrenz um Bandbreite reduzieren und das Netzwerk ganz vermeiden. Konkret: passende Bildgrößen und moderne Formate wie AVIF oder WebP, ein CDN beziehungsweise Bild-CDN, weniger gleichzeitig geladene Ressourcen und eine effiziente Cache-Control-Richtlinie, damit wiederkehrende Besucher das Bild aus dem Cache erhalten. Der Leitfaden weist darauf hin, dass die Ladedauer bei den meisten Websites kein wesentlicher Engpass ist – ein weiterer Grund, zuerst zu messen.
Phase 4: Renderverzögerung beseitigen
Ist die Ressource geladen, kann das Rendern trotzdem blockiert sein. web.dev nennt vier typische Ursachen: Stylesheets oder synchrone Skripte im <head>, die noch laden; ein LCP-Element, das erst per JavaScript ins DOM kommt; ein Element, das von anderem Code ausgeblendet wird, etwa einer A/B-Test-Bibliothek; und lange Aufgaben, die den Hauptthread blockieren. Maßnahmen sind unter anderem, renderblockierende Ressourcen zu reduzieren oder kleine Stylesheets direkt ins HTML zu übernehmen, serverseitiges Rendering zu nutzen, damit das LCP-Element bereits im ausgelieferten HTML steht, und lange Aufgaben im JavaScript aufzuteilen.
Häufige Fragen
Warum hat das Komprimieren meines Titelbildes nichts gebracht?
Vermutlich lag der Engpass in einer anderen Phase, zum Beispiel einer späten Entdeckung des Bildes oder einer Renderverzögerung durch Skripte. Prüfen Sie die Aufschlüsselung in Teilphasen, bevor Sie weiter optimieren.
Sollte ich jedes Bild mit hoher Priorität laden?
Nein. Die hohe Priorität ist für die LCP-Ressource gedacht. Wer alles priorisiert, priorisiert am Ende nichts.
Mein LCP ist auf dem Handy viel schlechter als am Computer – warum?
Mobil sind Verbindungen oft langsamer, Geräte leistungsschwächer, und das LCP-Element kann ein anderes sein. Messen Sie beide Ansichten getrennt.
Wie oft sollte ich den LCP prüfen?
Nach jeder größeren Änderung an Vorlage, Titelbild, Plugins oder Tracking-Skripten – und regelmäßig anhand der Felddaten.
Wenn Ihre Seiten zu langsam laden und Sie wissen möchten, in welcher Phase die Zeit verloren geht, analysiere ich das gern mit Ihnen – melden Sie sich einfach.