LCP optimieren: Ladegeschwindigkeit des Hauptinhalts verbessern
Der Largest Contentful Paint (LCP) ist eine der drei Core Web Vitals Metriken von Google. Er misst die wahrgenommene Ladegeschwindigkeit einer Webseite. Konkret gibt der LCP an, wie viele Sekunden vergehen, bis das grösste sichtbare Inhaltselement im oberen Bereich der Seite (z. B. ein Bannerbild oder eine grosse Überschrift) vollständig auf dem Bildschirm gerrendered ist. Ein LCP von unter 2.5 Sekunden gilt als optimal.
Da der LCP ein offizieller Ranking-Faktor ist, lohnt sich die Optimierung doppelt: Sie verbessert sowohl die Nutzererfahrung als auch die Sichtbarkeit in der Google-Suche. Die folgende Tabelle zeigt die offiziellen Schwellenwerte:
| Bewertung | LCP-Wert | Bedeutung |
|---|---|---|
| Gut | ≤ 2.5 s | Kein Handlungsbedarf |
| Verbesserungsbedürftig | 2.5 s – 4.0 s | Optimierung empfohlen |
| Schlecht | > 4.0 s | Dringender Handlungsbedarf |
Die vier Hauptursachen für einen schlechten LCP
Um den LCP-Wert erfolgreich zu senken, müssen Entwickler die typischen Flaschenhälse (Bottlenecks) identifizieren:
1. Langsame Antwortzeiten des Servers (Time to First Byte - TTFB)
Wenn der Webserver lange benötigt, um das erste Byte der HTML-Datei auszuliefern (z. B. durch langsame Datenbankabfragen, fehlendes Caching oder Serverüberlastung), verzögern sich alle nachfolgenden Ladevorgänge. Eine detaillierte Anleitung zur Senkung dieser Zeit finden Sie unter TTFB optimieren.
2. Render-blockierendes JavaScript und CSS
Bevor der Browser Inhalte rendern kann, liest er den <head>-Bereich des Dokuments ein. Laden dort grosse CSS- oder JS-Dateien ohne Attribute wie async oder defer, blockieren sie das Zeichnen der Seite, selbst wenn das HTML bereits geladen ist.
3. Lange Ladezeiten für Ressourcen
Das LCP-Element selbst (oft ein grosses Hintergrundbild oder Bild im Hero-Bereich) benötigt aufgrund mangelhafter Komprimierung oder grosser Dateigrössen zu lange, um über das Netzwerk übertragen zu werden.
4. Client-Side Rendering (CSR)
Wird das HTML erst nachträglich im Browser des Nutzers über JavaScript generiert, vergeht viel Zeit, bis der LCP-Inhalt überhaupt im DOM existiert. (Astro 6 umgeht dieses Problem standardmässig durch statische Generierung (SSG) auf Serverebene).
Praktische Schritte zur LCP-Optimierung
Bild-Ressourcen optimieren
- Modernes Format: Konvertieren Sie alle Bilder in hochkomprimierte Formate wie WebP oder AVIF. Dies reduziert die Dateigrösse bei identischer Bildqualität oft um 50 % bis 80 %.
- Preloading: Laden Sie das LCP-Bild bevorzugt (Preload). Fügen Sie hierfür folgenden Tag in den
<head>ein:<link rel="preload" href="/images/hero.webp" as="image"> - Kein Lazy Loading für LCP-Bilder: Versehen Sie Bilder im sichtbaren Bereich niemals mit dem Attribut
loading="lazy". Dieses sollte ausschliesslich für Bilder verwendet werden, die sich weiter unten auf der Seite (Below the Fold) befinden.
Server-Performance steigern
- Caching aktivieren: Nutzen Sie serverseitiges Caching (z. B. Nginx FastCGI Cache), damit Seiten direkt als statische HTML-Dateien aus dem RAM ausgeliefert werden, ohne PHP- oder Datenbank-Code auszuführen.
- Brotli-Komprimierung: Aktivieren Sie Brotli zur Komprimierung der HTML-, CSS- und JS-Dateien auf Netzwerkebene.
CSS und JS optimieren
- Critical CSS inline einbinden: Extrahieren Sie das CSS, das für die Darstellung des sichtbaren Bereichs (Above the Fold) zwingend nötig ist, und binden Sie es inline direkt im HTML
<style>-Tag ein. Das restliche CSS wird asynchron geladen.
Vorher/Nachher: eine LCP-Optimierung in Zahlen
Das folgende Beispiel zeigt eine typische Optimierung einer Startseite mit grossem Hero-Bild:
| Massnahme | LCP vorher | LCP nachher |
|---|---|---|
| Ausgangszustand (unkomprimiertes JPG, kein Preload) | 4.8 s | – |
| Bild in WebP konvertiert (−70 % Dateigrösse) | – | 3.6 s |
<link rel="preload"> für das Hero-Bild | – | 2.9 s |
| Render-blockierendes CSS reduziert + CDN | – | 2.1 s |
Die grosse Wirkung entsteht durch das Zusammenspiel mehrerer kleiner Massnahmen – selten reicht eine einzelne Optimierung.
LCP-Optimierung: die Checkliste
- LCP-Element identifizieren (Lighthouse zeigt es direkt an).
- Ist es ein Bild? → Bild optimieren, WebP/AVIF, korrekte Grösse, Preload.
loading="lazy"vom LCP-Element entfernen.- TTFB prüfen und senken (Caching, CDN).
- Render-blockierendes CSS/JS minimieren.
- Webfonts mit
font-display: swapund Preconnect entschärfen. - Erneut mit Felddaten (CrUX) statt nur im Labor messen.
[!TIP] Die Optimierung des LCP-Wertes ist die wirksamste Massnahme zur Verbesserung der gefühlten Geschwindigkeit Ihrer Website. Messen Sie Ihren LCP-Wert und analysieren Sie das konkrete LCP-Element mit dem PageSpeed Check auf balou.tools.
Häufig gestellte Fragen (FAQ)
Welches Element löst typischerweise den LCP aus?
Bei fast 80 % aller Websites ist das LCP-Element entweder ein grosses Hero-Bild im oberen Bereich (Header), ein grosses Logo oder der erste H1-Textblock.
Warum verschlechtert Client-Side Rendering (CSR) den LCP?
Bei reinem CSR (z. B. mit React oder Vue) erhält der Browser zunächst eine fast leere HTML-Datei. Er muss erst alle JavaScript-Dateien laden und ausführen, um den Inhalt aufzubauen, was den LCP drastisch verzögert.
Ab welchem Wert gilt der LCP als schlecht?
Google bewertet einen LCP bis 2.5 Sekunden als «gut», zwischen 2.5 und 4.0 Sekunden als «verbesserungsbedürftig» und über 4.0 Sekunden als «schlecht». Massgeblich ist das 75. Perzentil der echten Nutzerdaten (Felddaten), nicht ein einzelner Labortest.
Was ist der Unterschied zwischen Labordaten und Felddaten beim LCP?
Labordaten stammen aus einer kontrollierten Messung (z. B. Lighthouse) und sind reproduzierbar. Felddaten (CrUX) basieren auf echten Besuchern mit unterschiedlichen Geräten und Netzen – nur diese fliessen ins Google-Ranking ein.