Ein schlechter LCP-Wert hat laut Google fast immer eine von vier Ursachen: eine zu langsame Serverantwort (TTFB, rund 40 Prozent der Gesamtzeit), eine Verzögerung, bevor der Browser mit dem Laden des größten Elements überhaupt beginnt, die eigentliche Ladedauer dieses Elements selbst (ebenfalls rund 40 Prozent und bei Betriebs-Websites fast immer ein zu großes Foto), oder eine Verzögerung beim tatsächlichen Rendern. Wer diese vier Bausteine kennt, findet die eigene Ursache meist in wenigen Minuten und kann den Largest Contentful Paint gezielt verbessern, statt wahllos an der Website herumzuschrauben.
Die vier Bausteine der LCP-Zeit
Laut Googles eigener Dokumentation lässt sich jeder LCP-Wert lückenlos in vier Abschnitte zerlegen, für die Google sogar grobe Zielwerte als Orientierung nennt:
| LCP-Baustein | Bedeutung | Zielanteil |
|---|---|---|
| Time to First Byte (TTFB) | Zeit bis zur ersten Serverantwort | ~ 40 % |
| Resource Load Delay | Verzögerung vor dem Laden des LCP-Elements | < 10 % |
| Resource Load Duration | Tatsächliche Ladedauer des Elements | ~ 40 % |
| Element Render Delay | Verzögerung beim Rendern nach dem Laden | < 10 % |
Wichtig dabei: Diese Prozentsätze sind laut Google Richtwerte, keine starren Regeln – liegt der Gesamtwert bereits unter 2,5 Sekunden, spielt die genaue Verteilung keine Rolle mehr.
Ursache 1: Ein zu großes, unkomprimiertes Foto (Resource Load Duration)
Mit rund 40 Prozent der Gesamtzeit ist die tatsächliche Ladedauer des größten Elements der stärkste Hebel – und bei den meisten Betriebs-Websites ist dieses Element ein Foto. Unsere eigene Stichprobe realer Handwerksbetrieb-Websites zeigte Werte zwischen 5,4 und 12,6 Sekunden LCP, in allen Fällen maßgeblich verursacht durch unkomprimierte, zu große Fotos. Wie viele Fotos eine Website braucht und wie sie richtig komprimiert werden, zeigt unser Ratgeber zur richtigen Foto-Anzahl. Ein Beispiel zur Einordnung: Ein 4-MB-Foto direkt von der Kamera, ohne jede Kompression als Hintergrundbild der Startseite eingebunden, kann allein für diesen einen Baustein mehrere Sekunden benötigen – ein auf 150 KB komprimiertes WebP-Bild lädt dagegen in einem Bruchteil dieser Zeit. Wie genau Format, Größe und Lazy Loading dafür zusammenspielen, erklärt unser Ratgeber zur Bildoptimierung.
Ursache 2: Eine langsame Serverantwort (TTFB)
Die Zeit bis zur ersten Serverantwort soll laut Google rund 40 Prozent der LCP-Zeit ausmachen – wird dieser Wert bereits einzeln überschritten, ist ein guter Gesamtwert kaum noch erreichbar. Häufigste Ursachen sind ein überlasteter oder geografisch weit entfernter Server sowie mehrfache Weiterleitungen, etwa über Anzeigen-Tracking-Links, die laut Google-Dokumentation selbst bei einer ansonsten schnellen Website zu einer schlechten TTFB führen können. Ein Beispiel zur Einordnung: Ein Betrieb bucht den günstigsten Shared-Hosting-Tarif, auf dem gleichzeitig hunderte fremde Websites laufen – bei hoher Auslastung des gemeinsamen Servers steigt die Antwortzeit für alle Websites auf diesem Server gleichzeitig an, unabhängig vom eigenen Code.
Ursache 3: Verzögerung vor dem Laden des Elements
Selbst wenn Serverantwort und Ladedauer für sich genommen gut sind, kann eine Lücke dazwischen entstehen – etwa weil der Browser das größte Element erst entdeckt, nachdem CSS-Dateien oder JavaScript vollständig verarbeitet wurden. Für genau diesen Fall empfiehlt Google einen sogenannten Preload-Hinweis: <link rel="preload"> im HTML-Code weist den Browser an, eine bestimmte Ressource sofort und mit hoher Priorität zu laden, statt erst nach dem restlichen Seitenaufbau. Besonders relevant ist das laut Google-Dokumentation für Hintergrundbilder, die per CSS eingebunden sind, oder für Web-Schriftarten, die für die größte Textzeile benötigt werden – beides lässt sich vom Browser sonst erst spät im Ladevorgang entdecken. Ein Beispiel zur Einordnung: Ein Hero-Bild wird nicht direkt als <img>-Tag, sondern als CSS-Hintergrundbild eines Abschnitts eingebunden – der Browser entdeckt dieses Bild dadurch erst, nachdem er das komplette CSS heruntergeladen und ausgewertet hat, was gerade auf langsameren mobilen Verbindungen mehrere hundert Millisekunden zusätzliche Verzögerung bedeuten kann.
Ursache 4: Verzögertes Rendern nach dem Laden
Der letzte Baustein betrifft die Zeit zwischen fertig geladener Ressource und tatsächlich sichtbarem Element – meist verursacht durch render-blockierendes CSS oder JavaScript, das der Browser erst vollständig verarbeiten muss, bevor er überhaupt etwas anzeigen darf. Bei WordPress-Websites mit umfangreichen Seiten-Baukasten-Plugins ist das ein besonders häufiges Muster: Jedes zusätzliche Plugin kann eigenes CSS und JavaScript nachladen, das die Seite blockiert, noch bevor das eigentliche Foto überhaupt sichtbar wird – ein Zusammenhang, den unser Ratgeber zu Baukasten oder individueller Website anhand realer Messwerte einordnet. In der dortigen Stichprobe kamen zwei WordPress-Websites mit umfangreichem Seiten-Baukasten-Plugin auf 7,8 beziehungsweise 12,6 Sekunden LCP, während eine schlanke, individuell entwickelte Website auf denselben Inhalt in 2,5 Sekunden kam – ein Unterschied, der sich zu einem erheblichen Teil auf genau diesen letzten Baustein zurückführen lässt.
Interaktiv: Ihr LCP-Ursachen-Check
Prüfen Sie, welche der vier Ursachen bei Ihrer Website bereits ausgeschlossen sind:
Fazit: Meist reicht die Behebung einer einzigen Ursache
Ein schlechter LCP-Wert lässt sich fast immer auf einen der vier Bausteine zurückführen – bei Betriebs-Websites am häufigsten auf ein zu großes Foto, gefolgt von einer zu langsamen Serverantwort. Wie sich der eigene Wert im PageSpeed-Insights-Bericht überhaupt findet und richtig einordnet, zeigt unser Ratgeber zu PageSpeed Insights. Was LCP im Zusammenspiel mit INP und CLS insgesamt bedeutet, erklärt unser Ratgeber zu Core Web Vitals. Warum ein guter Labor-Wert trotzdem nichts über die echte Nutzererfahrung aussagen muss, erklärt unser Ratgeber zu Labor- und Felddaten.