
Was LCP genau misst
Der LCP ist der Zeitpunkt, zu dem das größte Inhaltselement im sichtbaren Bereich des Bildschirms vollständig dargestellt wird. Als Elemente zählen:
- Bilder (
<img>, auch innerhalb von<picture>) - Vorschaubilder von Videos (
poster) - Hintergrundbilder, die per CSS mit
url()geladen werden - Blockelemente mit Text, etwa große Überschriften oder Absätze
Welches Element das größte ist, hängt vom Bildschirm ab. Auf dem Smartphone ist es oft ein Foto oder die Hauptüberschrift, auf dem Desktop möglicherweise ein großes Titelbild. Die Entwicklertools von Chrome zeigen im Performance-Bereich, welches Element als LCP gemessen wurde.
Die vier Bestandteile der LCP-Zeit
Google zerlegt die LCP-Zeit in vier Phasen. Diese Zerlegung ist der Schlüssel zur Optimierung, weil jede Phase andere Ursachen hat.
| Phase | Beschreibung | Typischer Anteil bei guten Seiten |
|---|---|---|
| Time to First Byte (TTFB) | Zeit bis zur ersten Antwort des Servers | etwa 40 % |
| Ladeverzögerung der Ressource | Zeit zwischen TTFB und dem Beginn des Ladens des LCP-Elements | möglichst gering, unter 10 % |
| Ladedauer der Ressource | Zeit, die das LCP-Bild zum Laden braucht | etwa 40 % |
| Renderverzögerung | Zeit zwischen dem fertigen Laden und der Darstellung | möglichst gering, unter 10 % |
PageSpeed Insights und die Chrome DevTools zeigen diese Aufteilung an. Wer weiß, welche Phase am längsten dauert, weiß auch, wo er ansetzen muss.
Phase 1: Die Serverantwort beschleunigen
Wenn der Server lange braucht, um überhaupt zu antworten, kann nichts anderes schnell sein. Ein TTFB von über 800 Millisekunden ist ein deutliches Warnsignal.
- Seiten-Caching: Fertig erzeugte HTML-Seiten zwischenspeichern, statt sie bei jedem Aufruf neu aus der Datenbank zusammenzusetzen. Für WordPress bieten Caching-Plugins oder serverseitige Lösungen das an.
- Aktuelle Software: Neuere PHP-Versionen sind deutlich schneller als ältere.
- Ausreichende Serverressourcen: Günstige Shared-Hosting-Tarife teilen sich Prozessor und Speicher mit vielen anderen Websites.
- Datenbank optimieren: Langsame Abfragen, fehlende Indizes, aufgeblähte Tabellen.
- CDN: Ein Content Delivery Network liefert Inhalte von Servern in der Nähe des Nutzers aus und kann auch HTML zwischenspeichern.
- Weiterleitungen vermeiden: Jede Weiterleitung vor der eigentlichen Seite kostet Zeit.
Mehr dazu im Beitrag Hosting und SEO.
Phase 2: Die Ressource früh entdecken
Ein Bild kann erst geladen werden, wenn der Browser es kennt. Steht es direkt im HTML als <img> mit src, entdeckt der Browser es sofort. Wird es erst per JavaScript eingefügt, per CSS als Hintergrundbild definiert oder mit Lazy Loading versehen, entsteht eine Verzögerung.
Maßnahmen:
- Hauptbild direkt im HTML einbinden, nicht per JavaScript
- Kein Lazy Loading für das LCP-Bild:
loading="lazy"gehört nur zu Bildern unterhalb des sichtbaren Bereichs - Priorisieren mit fetchpriority:
<img src="titelbild.webp" fetchpriority="high" width="1200" height="600" alt="…">
- Vorladen bei Hintergrundbildern oder spät entdeckten Ressourcen:
<link rel="preload" as="image" href="titelbild.webp" fetchpriority="high">
Phase 3: Die Ressource schneller laden
Ist das Bild entdeckt, bestimmt seine Größe die Ladedauer.
- Moderne Formate: WebP oder AVIF statt JPEG oder PNG sparen oft 30 bis 50 Prozent Datenmenge. Mehr im Beitrag Bildformate WebP und AVIF.
- Passende Größe: Mit
srcsetundsizeserhält jedes Gerät eine passende Version. - Komprimierung: Qualitätseinstellungen von 70 bis 85 sind für Fotos meist ausreichend.
- CDN für Bilder: kürzere Wege, oft mit automatischer Formatwahl.
- Wenige konkurrierende Anfragen: Viele gleichzeitig geladene Dateien teilen sich die Bandbreite.
Phase 4: Die Darstellung nicht blockieren
Auch wenn das Bild geladen ist, kann der Browser es erst anzeigen, wenn blockierende Ressourcen verarbeitet sind.
- Render-blockierendes CSS reduzieren: Kritisches CSS für den sichtbaren Bereich direkt ins HTML, den Rest nachladen.
- JavaScript verzögern: Skripte mit
deferoderasyncladen, damit sie die Darstellung nicht aufhalten. - Schriften: Mit
font-display: swapwird Text sofort in einer Ersatzschrift angezeigt. Ist der LCP ein Textblock, verhindert das lange Wartezeiten. - Keine Einblendeffekte: Animationen, die das Hauptbild erst nach einer Verzögerung sichtbar machen, verschlechtern den LCP.
- A/B-Test-Skripte: Werkzeuge, die die Seite verbergen, bis die Testvariante geladen ist, verzögern die Darstellung deutlich.
Häufige Ursachen im Überblick
| Symptom | Wahrscheinliche Ursache | Lösung |
|---|---|---|
| Hoher TTFB | Server, fehlendes Caching | Caching, Hosting, CDN |
| Große Ladeverzögerung | Hauptbild per JavaScript oder Lazy Loading | direkt im HTML, fetchpriority |
| Lange Ladedauer | großes, unkomprimiertes Bild | moderne Formate, srcset |
| Große Renderverzögerung | blockierendes CSS/JS, Schriften, Animationen | kritisches CSS, defer, font-display |
| LCP-Element ist ein Slider | mehrere große Bilder gleichzeitig | einzelnes Bild statt Slider |
| Schlechter LCP nur auf Mobilgeräten | große Bilder für kleine Bildschirme | responsive Bilder |
- LCP-Element identifizieren (PageSpeed Insights oder DevTools)
- Zerlegung der LCP-Zeit ansehen: Welche Phase ist die längste?
- TTFB unter 800 ms bringen: Caching, Hosting
- Hauptbild direkt im HTML, ohne Lazy Loading
fetchpriority="high"für das Hauptbild- Bild in WebP oder AVIF, passende Größe
- Kritisches CSS inline, Rest verzögert
- JavaScript mit defer laden
- Schriften lokal mit font-display: swap
- Nach 28 Tagen Felddaten prüfen
Kurz beantwortet
Was ist ein guter LCP-Wert?
Bis 2,5 Sekunden gilt als gut, bezogen auf den 75. Perzentilwert der Felddaten.
Warum ist mein LCP auf dem Smartphone schlechter als auf dem Desktop?
Mobilgeräte haben meist schwächere Prozessoren und langsamere Verbindungen. Außerdem ist das LCP-Element auf kleinen Bildschirmen oft ein anderes. Deshalb sollte immer die mobile Ansicht separat optimiert werden.
Hilft ein CDN immer?
Meist, besonders für Bilder und statische Dateien und bei Besuchern aus verschiedenen Regionen. Bei einer überwiegend lokalen Zielgruppe und einem Server in der Nähe fällt der Effekt kleiner aus.