Langsamer LCP liegt selten am Bild: Daten von 2.600 Websites

Der übliche Rat bei einem langsamen Largest Contentful Paint lautet: das Titelbild komprimieren. Das klingt schlüssig, denn das größte Element einer Seite ist meist ein Bild, und eine kleinere Datei sollte schneller erscheinen. Unsere Felddaten zeigen ein anderes Bild. Wir haben den LCP von 2.600 Websites, die auf Smartphones über der Schwelle von 2,5 Sekunden liegen, in seine vier Phasen zerlegt. Der Bild-Download war bei 21 davon die langsamste Phase. Das ist weniger als ein Prozent.

Die meiste Zeit geht verloren, bevor der Download überhaupt beginnt.

Der LCP besteht aus vier Phasen, nur eine davon ist der Download

Jeder Largest Contentful Paint mit einem Bild lässt sich in vier aufeinanderfolgende Phasen zerlegen. Chrome misst jede davon bei echten Besuchern und veröffentlicht die Werte im Chrome UX Report (CrUX):

1. Time to First Byte: Der Browser wartet, bis der Server das erste Byte des HTML schickt.
2. Ladeverzögerung: Das HTML ist da, aber der Browser hat das Bild noch nicht angefordert.
3. Ladedauer: Das Bild wird heruntergeladen. Nur diese Phase hängt direkt von der Dateigröße ab.
4. Renderverzögerung: Das Bild ist vollständig geladen, aber der Browser hat es noch nicht gezeichnet.

Ein Vergleich mit einer Online-Bestellung macht das anschaulich. Die Serverantwort ist die Bestellbestätigung des Shops. Die Ladeverzögerung ist die Zeit, in der das Paket im Lager liegt, bevor es jemand abholt. Der Download ist der Lieferwagen. Die Renderverzögerung ist das Paket, das vor der Tür liegt, bis Sie es öffnen. Wer das Bild komprimiert, macht nur den Lieferwagen schneller.

Ladeverzögerung und Serverantwort verursachen neun von zehn langsamen LCP-Werten

Für jede Website mit langsamem LCP haben wir geprüft, welche der vier Phasen im 75. Perzentil am längsten dauert:

Längste LCP-Phase	Websites	Anteil
Ladeverzögerung	1.204	46,3 %
Time to First Byte	1.099	42,3 %
Renderverzögerung	276	10,6 %
Ladedauer (Download)	21	0,8 %

Zwei Phasen dominieren. Bei fast der Hälfte der langsamen Websites beginnt das Bild schlicht zu spät zu laden. Bei weiteren vier von zehn braucht der Server zu lange, bevor überhaupt etwas passiert. Googles eigene Auswertung der CrUX-Daten kommt zum selben Ergebnis: In Häufige Missverständnisse bezüglich der LCP-Optimierung (web.dev, August 2024) hält Brendan Kenny fest, dass der Bild-Download fast nie der Engpass ist.

Späte Bilderkennung ist die häufigste LCP-Bremse

Eine lange Ladeverzögerung bedeutet, dass der Browser das LCP-Bild spät findet. Er liest das HTML von oben nach unten und fordert Bilder an, sobald er auf sie stößt. Steht das Bild nicht im HTML, muss er erst auf etwas anderes warten. Typische Ursachen:

• Das Bild ist ein CSS-Hintergrund. Der Browser entdeckt es erst, wenn er das Stylesheet geladen und ausgewertet hat.
• JavaScript fügt das Bild ein. Slider, Karussells und clientseitig gerenderte Seiten setzen das Bild erst ein, nachdem ihre Skripte geladen und ausgeführt sind.
• Das Titelbild wird verzögert geladen. loading="lazy" weist den Browser an zu warten. Für Bilder weiter unten ist das richtig, für das Erste, was Besucher sehen, falsch.
• Das Bild hat niedrige Priorität. Ohne Hinweis stuft der Browser Bilder oft als weniger dringend ein als Skripte und Stylesheets.

Die Korrekturen sind meist klein. Das LCP-Bild gehört als normales <img>-Element ins HTML, ohne loading="lazy" und mit fetchpriority="high". Muss das Bild in CSS oder JavaScript bleiben, holt ein <link rel="preload"> im Dokumentkopf es früh. Unser Ratgeber zu Preconnect und Preload erklärt, wann welcher Hinweis sinnvoll ist.

Eine langsame Serverantwort ist die zweite LCP-Bremse

Ist die Time to First Byte die längste Phase, beginnt jede folgende Phase zu spät, und keine Bildoptimierung kann das ausgleichen. Die Zeit geht in die Erzeugung der Seite auf dem Server, in Weiterleitungen vor der eigentlichen Seite oder in einen langen Netzweg zu einem entfernten Rechenzentrum. Am meisten helfen hier ein Seiten-Cache, ein Content Delivery Network und der Verzicht auf Weiterleitungsketten. Der Ratgeber zur Time to First Byte behandelt die Ursachen ausführlich, auch den Einfluss des Hosting-Anbieters.

Die Renderverzögerung bremst jede zehnte langsame Website

Eine lange Renderverzögerung bedeutet, dass das Bild bereit ist, der Browser aber mit etwas anderem beschäftigt ist. Renderblockierende Stylesheets und Skripte, Webfonts, die den Text um das Bild zurückhalten, oder lange JavaScript-Aufgaben halten ihn vom Zeichnen ab. Bei etwa jeder zehnten langsamen Website war diese Phase die längste. Der Ratgeber zu renderblockierenden Ressourcen zeigt, wie Sie die Verursacher finden.

Bildkomprimierung hilft weiterhin, beim LCP aber selten zuerst

Bildoptimierung ist damit keineswegs überflüssig. Kleinere Dateien sparen Datenvolumen, senken das Seitengewicht und beschleunigen jedes weitere Bild der Seite. Einen schlechten LCP beheben sie aber selten. Bei einem langsamen LCP lohnt sich deshalb zuerst der Blick auf die Reihenfolge der Phasen: Ein Bild, das zwei Sekunden zu spät zu laden beginnt, gewinnt kaum etwas, wenn es 30 Prozent kleiner wird.

Prüfen Sie, welche LCP-Phase Ihre Website bremst

PerfDelta zeigt die vier LCP-Phasen aus echten Smartphone-Besuchen für jede Website mit genügend Chrome-Traffic, direkt neben der Labormessung. Ein kostenloser Website Speed Test zeigt, an welcher Phase Sie zuerst ansetzen sollten. Wie Ihre Phasen im Vergleich zu Wettbewerbern abschneiden, zeigt der Core Web Vitals Benchmark.

Methode und Grenzen dieser Auswertung

• Daten: 6.135 Smartphone-Datensätze aus dem Chrome UX Report, jeder Origin einmal gezählt, von PerfDelta im Oktober 2026 abgerufen. Jeder Datensatz umfasst ein gleitendes Fenster von 28 Tagen mit echten Chrome-Besuchen.
• Auswahl: die 2.600 Websites mit einem LCP über 2,5 Sekunden im 75. Perzentil, für die CrUX die LCP-Phasen ausweist.
• Nur Bild-LCP: CrUX weist die Phasen nur für Seitenaufrufe aus, bei denen das LCP-Element ein Bild ist. Seiten mit einer Textüberschrift als LCP-Element sind nicht enthalten.
• Längste Phase: Jede Phase wird mit ihrem eigenen 75. Perzentil verglichen. Diese Werte ergeben in der Summe nicht exakt den LCP, zeigen aber verlässlich, wo die meiste Zeit verloren geht.
• Stichprobe: Die Websites stammen aus Tests und Studien von PerfDelta und sind überwiegend größere Marken. Die Ergebnisse sind nicht repräsentativ für das gesamte Web. Weitere Zahlen aus demselben Datenbestand stehen in unseren Website Speed Statistiken.