Core Web Vitals: LCP unter 2,5 Sekunden senken
Ein LCP über 2,5 Sekunden senkt Ihre Conversion-Rate. Wie Sie die echten Ursachen erkennen und Ihre Seite 2026 mit umsetzbaren technischen Schritten beschleunigen.
Wenn sich Ihre Seite mobil langsamer als 2,5 Sekunden lädt, verlieren Sie einen erheblichen Teil der Nutzer bereits beim ersten Kontakt. In diesem Beitrag zeige ich, wie Sie den LCP (Largest Contentful Paint) mit echten Daten messen, die bremsenden Ursachen voneinander trennen und ihn mit technischen Maßnahmen, die 2026 weiterhin gelten, unter 2,5 Sekunden bringen.
1. Was ist der LCP – und warum die Schwelle von 2,5 Sekunden?
Der LCP misst, wann das größte sichtbare Element im Viewport (meist das Hero-Bild, eine große Überschrift oder ein Video-Poster) nach Beginn des Seitenladens gezeichnet wird. Bei den Core Web Vitals gilt ein Wert bis 2,5 Sekunden als gut, 2,5–4,0 Sekunden als verbesserungswürdig und über 4,0 Sekunden als schlecht.
Der LCP setzt sich aus drei Komponenten zusammen: TTFB (Server-Antwortzeit), Ressourcen-Ladezeit (Download von Bildern/Fonts) und Render-Verzögerung (Zeichnen des Elements durch den Browser). Eine Optimierung ohne separate Messung dieser drei Größen investiert meist am falschen Ende.
2. Erst richtig messen: Labor oder Feld?
Ein Lighthouse-Score ist eine Laborschätzung und spiegelt die echte Nutzererfahrung nicht wider. Treffen Sie Entscheidungen auf Basis von Felddaten (CrUX / Core-Web-Vitals-Bericht in der Search Console / RUM). Die Abweichung ist oft groß: Ein Nutzer im mobilen Netz sieht 4,8 Sekunden LCP, während Lighthouse im Büro auf dem Desktop 1,9 Sekunden anzeigt. Beachten Sie dabei auch die DSGVO: RUM- und Analysetools müssen datenschutzkonform und möglichst ohne personenbezogene Datenübertragung in Drittländer eingesetzt werden.
Die drei Teile des LCP und ihre Zielwerte
| Komponente | Formel / Messung | Ziel |
|---|---|---|
| TTFB | Server-Antwortzeit (ms) | < 800 ms |
| Ressourcen-Laden | Downloadzeit für Bild/Font | < 700 ms |
| Render-Verzögerung | Warten auf JS/CSS vor dem Paint | < 1000 ms |
In Summe < 2500 ms. Sobald Sie diese Tabelle gefüllt haben, wissen Sie, an welchem Hebel Sie ansetzen müssen.
3. Die 6 häufigsten LCP-Verursacher und ihre Lösungen
- Hero-Bild per Lazy-Loading: Laden Sie das LCP-Element niemals lazy. Nutzen Sie
loading="eager"undfetchpriority="high". - Falsches Format und falsche Größe: Wechseln Sie zu WebP/AVIF und liefern Sie mobile mit responsive
srcsetdie 1x-Größe aus. Ein JPEG mit 2 MB verursacht mobil im Schnitt 900 ms–1,5 s Mehrlast gegenüber einem WebP mit 120 KB. - Font-Blocking: Verwenden Sie
font-display: swapund laden Sie die kritische Schrift perpreloadvorab. - Render-blockierendes CSS/JS: Binden Sie kritisches CSS inline ein und schieben Sie den Rest nach hinten. Teilen Sie das große JS-Bundle pro Route auf.
- Langsamer TTFB: Reduzieren Sie ihn durch Server-/CDN-Caching, Edge-Cache und optimierte Datenbankabfragen. Eine Senkung des TTFB von 1,2 s auf 0,5 s wirkt sich direkt auf den LCP aus.
- Third-Party-Skripte: Verzögern Sie Chat-, A/B-Testing- und Tag-Manager-Skripte mit
defer. Jeder unnötige Tag erhöht die Render-Verzögerung um 100–300 ms.
4. Schritt-für-Schritt-Aktionsplan für 30 Tage
Etablieren Sie den Kreislauf aus Messen → Ziel setzen → Umsetzen → Überprüfen.
- Tag 1–3: Erheben Sie per RUM die LCP-Verteilung nach Seitentyp (Startseite, Kategorie, Produkt, Blog). Notieren Sie den P75-Wert.
- Tag 4–7: Identifizieren Sie das LCP-Element (Markierung „LCP“ im Performance-Panel der DevTools). Messen Sie TTFB, Ressource und Render getrennt.
- Tag 8–20: Setzen Sie die zwei bis drei wirkungsstärksten der oben genannten sechs Punkte um. Typischerweise liefern Bildoptimierung und kritisches CSS die schnellsten Ergebnisse.
- Tag 21–30: Messen Sie den P75-LCP auf denselben Seiten erneut. Ziel: ≥ 75 % der Nutzer unter 2,5 Sekunden.
Beispielrechnung
LCP der Startseite = 4,1 s. Analyse: TTFB 1,4 s + Bildladen 1,9 s + Render 0,8 s. Ihre Maßnahmen: TTFB per CDN-Edge-Cache von 1,4 auf 0,6 s; Bild per WebP und korrekter Größe von 1,9 auf 0,5 s. Neuer LCP ≈ 0,6 + 0,5 + 0,8 = 1,9 s. Damit liegt er unter der Schwelle.
Einen solchen Kreislauf aus Messung und Umsetzung etablieren Sie am besten mit einem Webdesign & -entwicklung-Team, das Inhalte und Technik gemeinsam verantwortet, oder mit einem audit-orientierten SEO-Prozess. Da Geschwindigkeitsverbesserungen auch die Conversion-Rate auf der Anzeigenseite direkt beeinflussen, sollten sie im selben Fahrplan wie das Anzeigenmanagement geplant werden.
5. Überprüfung und Kontinuität
Der LCP ist keine einmalige Aufgabe. Produktbilder, neue Skripte und Theme-Änderungen treiben ihn wieder nach oben. Deshalb:
- Lassen Sie im RUM monatlich automatisch einen P75-Bericht erstellen.
- Definieren Sie ein LCP-Budget, bevor ein neuer Seitentyp live geht (z. B. < 2,2 s).
- Messen Sie die Performance-Auswirkung jedes neuen Third-Party-Skripts und entfernen Sie unnötige.
Wenn Sie das unternehmerisch verankern möchten, lassen sich Messung und Umsetzung mit einem 360° Digitales Marketing-Ansatz unter einem Dach steuern. Schnellere Seiten erhöhen zugleich den Ertrag Ihres bezahlten Traffics – denn eine schnellere Seite bedeutet günstigere Conversions.
Lassen Sie uns gemeinsam Ihre aktuelle Core-Web-Vitals-Bilanz erstellen. Für ein kostenloses Erstgespräch erreichen Sie uns über die Seite Kontakt.