LCP verbessern: die 7 häufigsten Ursachen

Wenn wir bei TwoPixels ein Website-Audit durchführen, taucht der Largest Contentful Paint, kurz LCP, in fast jedem Bericht als Warnung auf. Das ist kein Zufall: Der LCP misst, wie lange es dauert, bis das größte sichtbare Element im Anzeigebereich, meist ein Hero-Bild, eine große Überschrift oder ein Video-Poster, vollständig geladen und gerendert ist. Google zählt ihn zu den drei zentralen Core Web Vitals und nutzt ihn als Rankingfaktor. Noch wichtiger als das Ranking ist aber die Wirkung auf echte Besucher, denn alles über 2,5 Sekunden fühlt sich träge an, und alles über 4 Sekunden kostet nachweislich Conversions. In diesem Ratgeber gehen wir die sieben Ursachen durch, die uns in der Praxis am häufigsten begegnen, und zeigen, wie man sie konkret behebt.

Was der LCP wirklich misst

Der LCP ist kein Wert für die gesamte Ladezeit einer Seite, sondern für den Zeitpunkt, an dem das visuell größte Element im sichtbaren Bereich fertig gerendert ist. Auf einer Produktseite ist das häufig das Produktbild, auf einer Landingpage die Headline oder ein Hero-Video-Standbild. Google unterscheidet dabei zwischen Labordaten, die zum Beispiel PageSpeed Insights oder Lighthouse unter kontrollierten Bedingungen erzeugen, und Felddaten aus dem Chrome User Experience Report, die reale Besucher mit ihren tatsächlichen Geräten und Netzwerken liefern. Beide Werte können deutlich auseinanderliegen, weil Labortests meist mit einer sauberen Verbindung und einem definierten Gerät arbeiten, während echte Nutzer oft mit langsamem Mobilfunk, älteren Smartphones und vollem Browser-Cache unterwegs sind. Für die Suchmaschinenoptimierung zählt am Ende die Feldmessung, konkret der 75. Perzentilwert aus der Search Console. Mehr Hintergrund zu allen drei Kennzahlen und ihren Schwellenwerten finden Sie in unserem Grundlagenartikel zu Core Web Vitals.

Ursache 1: Langsame Serverantwortzeit (TTFB)

Bevor überhaupt ein Byte HTML im Browser ankommt, muss der Server antworten. Diese Zeit heißt Time to First Byte, und sie ist die Grundlage, auf der jede andere Optimierung aufbaut. Läuft eine Seite auf überlastetem Shared Hosting, fehlt ein Objekt-Cache für Datenbankabfragen oder muss bei jedem Aufruf ein PHP-Template komplett neu zusammengebaut werden, verstreichen schon vor dem eigentlichen Rendering wertvolle Sekundenbruchteile. Bei WordPress-Seiten sehen wir das besonders oft: Dutzende Plugins, die bei jedem Seitenaufruf eigene Datenbankabfragen absetzen, treiben die Serverantwortzeit auf 800 Millisekunden oder mehr. Die Lösung liegt selten in einem einzelnen Trick, sondern in der Summe: schnelleres Hosting mit SSD-Speicher, ein serverseitiger Seiten-Cache, ein Content Delivery Network für statische Dateien und, wo möglich, der Verzicht auf unnötige Plugins. Als Richtwert gilt: Ein guter TTFB liegt unter 200 Millisekunden, alles über 600 Millisekunden verdient eine genauere Untersuchung.

Ursache 2: Unoptimierte Bilder als LCP-Element

In den meisten Audits, die wir sehen, ist genau das LCP-Element selbst das Problem, und zwar in Form eines viel zu großen Bildes. Ein Hero-Bild, das als unkomprimiertes JPEG mit 4.000 Pixel Breite ausgeliefert wird, obwohl es am Bildschirm nur 1.200 Pixel breit dargestellt wird, verschwendet Bandbreite und Zeit. Häufige Fehler sind fehlende moderne Formate wie WebP oder AVIF, ein fehlendes srcset für responsive Auslieferung je nach Bildschirmgröße und, besonders tückisch, ein pauschal gesetztes loading="lazy" auf genau dem Bild, das oberhalb der Bildschirmkante zuerst sichtbar sein soll. Lazy Loading ist für Bilder weiter unten auf der Seite sinnvoll, für das LCP-Element selbst bremst es die Darstellung künstlich aus. Gerade Online-Shops mit hunderten Produktbildern profitieren hier besonders von einer sauberen Bildpipeline; wenn Sie einen Shopify-Shop betreiben, lohnt sich ein Blick auf die automatische Bildoptimierung des Themes, denn Shopify liefert Originalbilder oft ungefiltert aus, wenn das Theme sie nicht explizit skaliert.

Ursache 3: Render-blockierendes CSS und JavaScript

Jede CSS-Datei und jedes synchron eingebundene Skript, das der Browser vor dem ersten Rendering laden und verarbeiten muss, verzögert die Anzeige des größten Elements. Besonders anfällig sind Seiten, auf denen im Laufe der Zeit ein Tag-Manager, ein Cookie-Consent-Banner, ein Live-Chat-Widget und mehrere Tracking-Skripte übereinandergestapelt wurden, oft von unterschiedlichen Teams zu unterschiedlichen Zeitpunkten eingebaut. Jedes dieser Skripte für sich ist meist klein, in der Summe blockieren sie aber den Hauptthread genau in dem Moment, in dem der Browser eigentlich das LCP-Element malen will. Die Lösung besteht darin, kritisches CSS für den sichtbaren Bereich inline zu setzen, alles andere asynchron nachzuladen, und Drittanbieter-Skripte konsequent mit defer oder async zu versehen, sofern sie nicht zwingend blockierend sein müssen. Wer regelmäßig neue Marketing-Tags einbaut, sollte diese Skript-Last in die eigene technische Betreuung aufnehmen; unsere SEO-Agentur prüft genau diesen Punkt standardmäßig bei jeder technischen Analyse.

Ursache 4: Kein Preload für das LCP-Element

Der Browser entdeckt Bilder, die per CSS als Hintergrundbild oder verschachtelt im DOM eingebunden sind, oft erst relativ spät im Ladeprozess, weil er zunächst das HTML parsen und dann die CSS-Regeln auswerten muss, bevor er überhaupt weiß, dass dieses Bild benötigt wird. Für das LCP-Bild ist das ein direkter Zeitverlust. Mit einem gezielten im Head der Seite und dem Attribut fetchpriority="high" auf dem img-Tag signalisieren Sie dem Browser, dass genau dieses Bild höchste Priorität hat und sofort angefordert werden soll, parallel zu anderen Ressourcen. Ergänzend hilft ein preconnect zu externen Domains, von denen das Bild oder eine Schriftart geladen wird, damit die DNS-Auflösung und der Verbindungsaufbau nicht erst beim tatsächlichen Ressourcenabruf beginnen. Diese kleinen Hinweise im HTML-Head kosten wenig Aufwand, haben aber oft einen überraschend großen Effekt auf den gemessenen LCP-Wert.

Ursache 5: Web-Fonts blockieren den Seitenaufbau

Enthält das LCP-Element Text, etwa eine große Headline in einer individuellen Schriftart, dann hängt die Darstellung dieses Textes auch vom Ladeverhalten der Schriftdatei ab. Standardmäßig verstecken viele Browser Text so lange, bis die passende Schriftart geladen ist, was als Flash of Invisible Text bekannt ist und den LCP künstlich nach hinten schiebt. Zusätzlich werden Web-Fonts häufig von externen Diensten wie Google Fonts nachgeladen, was einen weiteren DNS-Lookup und eine weitere Verbindung erfordert. Wirksame Gegenmaßnahmen sind das Selbst-Hosten der benötigten Schriftdateien, ein Preload der wichtigsten Font-Datei, die Reduktion auf wirklich benötigte Schriftschnitte statt zehn Gewichtsvarianten, und die CSS-Eigenschaft font-display: swap, damit der Browser zunächst eine Systemschrift zeigt und erst später auf die eigentliche Schriftart wechselt, statt den Text komplett zu verstecken.

Ursache 6: Zu viele Weiterleitungen

Jede Weiterleitung, etwa von http auf https, von der nackten Domain auf die www-Variante oder von einer alten URL-Struktur auf eine neue, kostet eine zusätzliche Server-Anfrage, bevor der Browser überhaupt mit dem Laden der eigentlichen Seite beginnen kann. Auf gewachsenen Websites finden wir manchmal Ketten aus drei oder vier Weiterleitungen hintereinander, oft historisch entstanden durch mehrere Relaunches oder eine unsauber konfigurierte CDN-Anbindung. Jede einzelne Weiterleitung braucht eine eigene Zeitverbindung inklusive DNS und TLS-Handshake, und diese Zeit addiert sich direkt auf den LCP. Die Lösung ist unspektakulär, aber wirksam: Redirect-Ketten auflösen, sodass jede interne Verlinkung direkt auf die finale URL zeigt, und die Serverkonfiguration einmal grundlegend aufräumen. Wer über einen technischen Neuaufbau nachdenkt, sollte das gleich mit erledigen; ein sauber konzipiertes Webdesign-Projekt bei uns startet bereits ab 1.990 Euro und vermeidet solche Altlasten von Anfang an.

Ursache 7: Clientseitiges Rendering ohne serverseitige Vorarbeit

Bei modernen JavaScript-Anwendungen, die vollständig im Browser gerendert werden, muss zunächst das komplette JavaScript-Bundle heruntergeladen, geparst und ausgeführt werden, bevor überhaupt Inhalt auf dem Bildschirm erscheint. Erst danach baut die Anwendung das eigentliche DOM auf und lädt möglicherweise noch Daten über eine API nach, bevor das größte Element sichtbar wird. Diese Kette aus Download, Ausführung und Datenabruf summiert sich schnell auf mehrere Sekunden, besonders auf mobilen Geräten mit schwächerer CPU. Frameworks, die Server-Side-Rendering oder Static-Site-Generation unterstützen, liefern dagegen bereits fertiges HTML aus, sodass der Browser das LCP-Element zeigen kann, während das JavaScript für Interaktivität erst im Hintergrund nachlädt. Wer eine bestehende Single-Page-Anwendung betreibt, sollte zumindest prüfen, ob sich die oberste Bildschirmebene serverseitig vorrendern lässt, auch wenn der Rest der Anwendung clientseitig bleibt.

LCP richtig messen, bevor Sie optimieren

Bevor Sie irgendeine der genannten Maßnahmen umsetzen, sollten Sie wissen, woran es bei Ihrer Seite konkret hakt, denn die sieben Ursachen treten selten alle gleichzeitig auf. PageSpeed Insights zeigt sowohl Labordaten als auch, sofern genügend Besucher vorhanden sind, echte Felddaten aus dem Chrome User Experience Report. In der Google Search Console finden Sie unter dem Bericht zu den Core Web Vitals, wie viele Ihrer URLs im grünen, gelben oder roten Bereich liegen, gruppiert nach ähnlichen Seitentypen. Wichtig ist der Unterschied zwischen Mobil und Desktop: Auf dem Smartphone ist die CPU meist schwächer und die Netzwerkverbindung langsamer, weshalb der LCP dort oft deutlich schlechter ausfällt als am Schreibtisch-Rechner mit Glasfaseranschluss. Ein technisches Audit, das Labordaten, Felddaten und einen Blick auf den tatsächlichen Ressourcen-Wasserfall kombiniert, liefert deutlich verlässlichere Hinweise als ein einzelner PageSpeed-Score.

In welcher Reihenfolge Sie vorgehen sollten

Aus unserer Erfahrung lohnt sich folgende Priorisierung: Zuerst die Serverantwortzeit prüfen und gegebenenfalls Hosting oder Caching verbessern, denn darauf baut alles Weitere auf. Danach das LCP-Element selbst identifizieren, meist über die Lighthouse-Analyse, und dessen Ladeverhalten optimieren, also Format, Größe, Preload und kein Lazy Loading. Erst danach macht es Sinn, sich um Render-Blocker, Fonts und Redirect-Ketten zu kümmern, weil diese Effekte kleiner sind, sich aber gut summieren, sobald die großen Baustellen erledigt sind. Clientseitiges Rendering betrifft nicht jede Website und ist meist ein größeres architektonisches Thema, das eher im Rahmen eines Relaunches als nebenbei gelöst wird. Wichtig ist außerdem, nach jeder Änderung erneut zu messen, denn Optimierungen an einer Stelle können an anderer Stelle neue Engpässe sichtbar machen, etwa wenn ein schnelleres Bild plötzlich ein langsames Skript als neuen Flaschenhals entlarvt.

Häufige Fragen

Was ist ein guter LCP-Wert?
Google stuft einen LCP unter 2,5 Sekunden als gut ein, Werte zwischen 2,5 und 4 Sekunden gelten als verbesserungswürdig, und alles darüber als schlecht. Maßgeblich ist dabei nicht ein einzelner Testlauf, sondern der 75. Perzentilwert über echte Besucher in der Google Search Console.

Warum ist mein LCP auf dem Handy schlechter als am Desktop?
Mobile Geräte haben meist eine schwächere CPU und werden oft über Mobilfunknetze statt über eine feste Internetleitung genutzt, was sowohl das Laden als auch das Verarbeiten von JavaScript verlangsamt. Deshalb sollten Sie Optimierungen immer zuerst an mobilen Messwerten ausrichten, nicht am Desktop-Ergebnis.

Reicht es, nur das Hero-Bild zu komprimieren?
Ein komprimiertes Bild hilft, löst aber selten das gesamte Problem, wenn gleichzeitig die Serverantwortzeit hoch ist oder render-blockierende Skripte vorgeschaltet sind. Nachhaltig wird die Verbesserung erst, wenn Sie mehrere der genannten Ursachen gemeinsam angehen.

Kann ein Cache-Plugin den LCP allein retten?
Ein guter Cache verbessert vor allem die Serverantwortzeit und kann dadurch spürbar helfen, behebt aber keine Probleme mit dem Bildformat, blockierenden Skripten oder fehlendem Preload. Er ist ein sinnvoller Baustein, aber kein Ersatz für die anderen sechs Maßnahmen.

Wie schnell wirkt sich eine LCP-Verbesserung auf das Google-Ranking aus?
Core Web Vitals werden über einen rollierenden Zeitraum aus echten Nutzerdaten erhoben, weshalb spürbare Effekte in der Regel erst nach einigen Wochen mit ausreichend neuem Traffic sichtbar werden. Die Wirkung auf Absprungrate und Conversions zeigt sich dagegen meist deutlich schneller.

Sollte ich Lazy Loading grundsätzlich vermeiden?
Nein, für Bilder unterhalb des sichtbaren Bereichs ist Lazy Loading sinnvoll und spart Bandbreite. Problematisch wird es ausschließlich dann, wenn es versehentlich auch auf das LCP-Element selbst angewendet wird, das ja sofort sichtbar sein soll.

Wie finde ich heraus, welches Element auf meiner Seite der LCP ist?
In den Chrome-Entwicklertools zeigt der Performance-Tab unter dem Eintrag Timings direkt an, welches DOM-Element als Largest Contentful Paint erkannt wurde. Auch PageSpeed Insights markiert das Element im Diagnosebereich unter dem Punkt zum Largest Contentful Paint.