Was ist LCP? Largest Contentful Paint erklärt (Daten 2026)

Largest Contentful Paint (LCP) misst, wie lange das größte sichtbare Inhaltselement – meist ein Hero-Bild oder ein Textblock – braucht, bis es auf dem Bildschirm erscheint. Googles Messlatte liegt bei 2,5 Sekunden oder weniger für 75 % der echten Seitenaufrufe. Als wir im Oktober 2026 115 Ergebnisse von Googles erster Seite getestet haben, erreichten im Labor nur 8,7 % diesen Wert.

Dieser Leitfaden erklärt, was LCP bedeutet und wie er sich von anderen Performance-Messwerten unterscheidet. Danach zeigen wir, wie die Seiten, die tatsächlich ranken, aussehen, wenn man sie misst. Die Zahlen stammen aus einem mobilen Lighthouse-Lauf, den wir am 1. Oktober 2026 selbst durchgeführt haben – und sie verändern, welche Korrekturen zuerst Ihre Zeit verdienen.

Was bedeutet LCP?

Largest Contentful Paint ist ein nutzerzentrierter Performance-Messwert, der den Moment erfasst, in dem der wichtigste Inhalt Ihrer Seite sichtbar wird. Der Name lässt sich einfach aufschlüsseln:

• Largest: Das größte im Viewport sichtbare Inhaltselement
• Contentful: Bedeutungsvoller Inhalt, der Nutzer tatsächlich interessiert
• Paint: Der Moment, in dem dieser Inhalt gerendert wird

Das LCP-Element kann sein:

• Ein Bild (einschließlich <img>-Tags, CSS-Hintergrundbildern oder Bildern in <svg>)
• Ein Textblock (Absätze, Überschriften oder andere Block-Elemente)
• Das Posterbild eines Videos

LCP berücksichtigt nur Inhalte im anfänglichen Viewport. Liegt Ihr größtes Element unterhalb des sichtbaren Bereichs, fließt es nicht in die LCP-Berechnung ein – zählt nur, was Nutzer sofort sehen.

Was ist der Unterschied zwischen LCP und FCP?

First Contentful Paint (FCP) und Largest Contentful Paint (LCP) messen unterschiedliche Momente des Ladevorgangs:

First Contentful Paint (FCP) erfasst, wann überhaupt erstmals Inhalt erscheint – den Moment, in dem Nutzer sehen, dass etwas lädt. Das kann ein Lade-Spinner, die Navigationsleiste oder ein Platzhaltertext sein.

Largest Contentful Paint (LCP) markiert, wann der Hauptinhalt sichtbar wird – den Punkt, an dem Nutzer die Seite als „geladen“ und nutzbar wahrnehmen.

Stellen Sie sich beide als zwei Meilensteine vor:

1. FCP: „Es passiert etwas!“
2. LCP: „Die Seite sieht fertig aus!“

Während FCP auf erstes Feedback zielt, misst LCP, wann Nutzer tatsächlich mit Ihrem Inhalt arbeiten können. Im Lighthouse-Performance-Score wiegt LCP auch deutlich mehr: 25 % gegenüber 10 % für FCP (Chrome for Developers).

Was ist ein guter LCP-Wert?

Google unterscheidet drei LCP-Kategorien:

• Gut: 2,5 Sekunden oder weniger – Ihr Ziel für eine optimale Nutzererfahrung
• Verbesserungswürdig: 2,5 bis 4 Sekunden – akzeptabel, aber optimierungswürdig
• Schlecht: Über 4 Sekunden – erfordert sofortige Aufmerksamkeit

Google empfiehlt, dass 75 % Ihrer Seitenaufrufe den Bereich „Gut“ erreichen. web.dev formuliert es so: „a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices“ (web.dev). So werden unterschiedliche Geräte und Netzbedingungen berücksichtigt, während die meisten Besucher eine gute Erfahrung haben.

Der Großteil des Webs liegt knapp darunter. Laut HTTP Archive Web Almanac 2025 erreichen 62 % der mobilen und 74 % der Desktop-Seiten einen guten LCP, gemessen an echten Chrome-Nutzern im Juli 2025.

Wie schnell ist der LCP auf Seiten, die tatsächlich ranken?

Langsamer, als die meisten LCP-Ratgeber nahelegen. Am 1. Oktober 2026 haben wir mobiles Lighthouse 13.5 auf 115 Ergebnisse von Googles erster Seite für 15 kommerzielle US-Keywords angewendet, von Lohnabrechnungssoftware bis Saugroboter – mit denselben Einstellungen wie unser kostenloser Website-Speed-Test. Der Median des Labor-LCP lag bei 10,0 Sekunden, und nur 8,7 % der Seiten zeigten ihren Hauptinhalt innerhalb von 2,5 Sekunden.

Zu diesen Zahlen gehören zwei Vorbehalte. Es sind Laborläufe von einem Rechner unter Lighthouses simuliertem langsamem Mobilprofil, absolute Zeiten fallen daher höher aus als auf einer schnellen Verbindung. Wir haben den Aufbau an Google geprüft: Unsere eigene Startseite kam in unserem Lauf auf einen LCP von 7,8 Sekunden, in PageSpeed Insights am selben Morgen auf 8,1 Sekunden. Und die Position hing in dieser Stichprobe nicht mit der Geschwindigkeit zusammen (Spearmans ρ = 0,04, nicht signifikant). Rankende Seiten sind keine schnellen Seiten; sie sind relevante Seiten, die oft langsam sind.

Klar gezeigt hat der Lauf, was das LCP-Element auf rankenden Seiten ist:

Das ist wichtig, weil die Korrektur vom Element abhängt. Ein Text-LCP wartet meist auf Schriften, CSS oder JavaScript. Ein Bild-LCP wartet meist auf die Bildanfrage selbst.

Warum ist LCP für SEO wichtig?

LCP wurde mit dem Page-Experience-Update, das im Juni 2021 ausgerollt wurde, Teil von Googles Ranking-Systemen. Google ist bei beiden Hälften der Geschichte klar: „Core Web Vitals are used by our ranking systems“ und „Google Search always seeks to show the most relevant content, even if the page experience is sub-par“ (Google Search Central).

Aus SEO-Sicht wirkt LCP auf zwei Wegen:

Direktes Ranking-Signal: Google bezieht die Core Web Vitals in seine Page-Experience-Systeme ein. Die Relevanz der Inhalte dominiert weiterhin, LCP kann aber zwischen ähnlichen Seiten den Ausschlag geben – was zu unseren Daten passt: Bei 115 Ergebnissen von Seite 1 sagte die Geschwindigkeit die Position nicht voraus.

Der Besucher: Ein langsamer Hauptinhalt verliert Menschen, bevor sie etwas lesen – und dort liegt das Geld. Vodafone testete in einem A/B-Test eine Landingpage, deren LCP im Feld 31 % besser war, und erzielte 8 % mehr Verkäufe (web.dev-Fallstudie).

Welche Faktoren beeinflussen den LCP-Wert?

Google teilt jeden LCP in vier Teilphasen auf, und jede verweist auf eine andere Korrektur (web.dev):

Vier Hauptfaktoren speisen diese Teilphasen:

1. Langsame Server-Antwortzeit (TTFB)

Die Time to First Byte (TTFB) misst, wie lange der Server braucht, um auf eine Browser-Anfrage zu antworten. Jede Millisekunde Serververzögerung kommt direkt zu Ihrem LCP hinzu. Typische Ursachen sind langsame Datenbankabfragen, nicht optimierter serverseitiger Code und schwache Hosting-Infrastruktur.

2. Render-blockierende Ressourcen

JavaScript- und CSS-Dateien, die das Rendern blockieren, verhindern, dass Inhalte erscheinen, bevor sie vollständig geladen und verarbeitet sind. Bei einem Text-LCP ist das meist die größte Verzögerung: Auf den Seiten mit Text-LCP in unserer Stichprobe machte der Element Render Delay im Median 42,9 % der gemessenen Zeit aus.

3. Langsame Ladezeiten von Ressourcen

Große Bilder, Videos und Webfonts brauchen Zeit zum Herunterladen. Ein nicht optimiertes Hero-Bild kann auf einer mobilen Verbindung Sekunden zu Ihrem LCP hinzufügen.

4. Client-seitiges Rendering

Single-Page-Anwendungen mit React, Vue oder Angular müssen oft JavaScript ausführen, bevor Inhalte erscheinen. Der Browser muss Skripte herunterladen, parsen und ausführen, bevor er rendert – eine deutliche Verzögerung gegenüber serverseitig gerendertem HTML.

Wie messen Sie den LCP?

Bevor Sie optimieren, brauchen Sie verlässliche Messungen. Drei Werkzeuge decken das ab:

SEOmators kostenloser Website-Speed-Test

SEOmators kostenloser Speed-Test führt für jede öffentliche URL ein Google-Lighthouse-Audit aus. Geben Sie Ihre URL ein, wählen Sie das Gerät und erhalten Sie den vollständigen Bericht, einschließlich Ihrer LCP-Zeit und des Elements, das sie verursacht. Es sind Labordaten: ein simulierter Aufruf, nicht das, was Ihre Besucher erlebt haben.

Google PageSpeed Insights

Google PageSpeed Insights kombiniert Labordaten (simulierte Tests) mit Felddaten echter Chrome-Nutzer. Die Felddaten zeigen, wie tatsächliche Besucher Ihre Website erleben. Sie erscheinen, sobald eine Seite oder Website genug Chrome-Traffic hat.

Chrome DevTools

Um das konkrete LCP-Element zu finden, öffnen Sie die Chrome DevTools (F12), wechseln zum Tab „Performance“ und zeichnen einen Seitenaufruf auf. Das Werkzeug hebt genau das Element hervor, das Ihren LCP auslöst.

8 Wege, Ihren LCP-Wert zu verbessern

Arbeiten Sie diese der Reihe nach ab. Die ersten drei entscheiden über die meisten LCPs:

1. Ihr LCP-Element identifizieren

Bevor Sie blind optimieren, finden Sie heraus, was Ihren LCP verursacht. Klicken Sie in Chrome mit der rechten Maustaste auf Ihre Seite, wählen Sie „Untersuchen“, öffnen Sie den Tab „Performance“ und klicken Sie auf „Neu laden“. Die Zeitleiste zeigt genau, welches Element Ihren LCP auslöst.

Gehen Sie nicht davon aus, dass es das Hero-Bild ist. Auf den Seite-1-Ergebnissen, die wir gemessen haben, war das LCP-Element etwas häufiger Text als ein Bild (47,0 % gegenüber 42,6 %). Wenn Sie Ihr Element kennen, treffen Sie die richtige Teilphase.

2. Das LCP-Bild zuerst laden lassen

Ist Ihr LCP-Element ein Bild, sorgen Sie dafür, dass der Browser es früh und mit Priorität lädt:

• Nie lazy laden: web.dev ist deutlich: „Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay.“ Verwenden Sie loading="lazy" nur für Bilder unterhalb des sichtbaren Bereichs.
• fetchpriority="high" ergänzen am LCP-<img>, damit es in der Download-Warteschlange nach vorne rückt.
• Ins HTML stellen: Ein Bild, das erst nach JavaScript erscheint, kann erst laden, wenn dieses Skript läuft. Geht das nicht, laden Sie es mit <link rel="preload" as="image"> vor.

3. Bilder optimieren

Machen Sie dann die Datei selbst günstiger zu laden:

• Bilder komprimieren: Squoosh oder ImageOptim reduzieren die Dateigröße deutlich ohne sichtbaren Qualitätsverlust
• Moderne Formate nutzen: WebP und AVIF sind bei gleicher Qualität meist deutlich kleiner als JPEG und PNG
• Die richtige Größe ausliefern: Nutzen Sie srcset, damit Smartphones kein Desktop-Hero-Bild laden
• Abmessungen angeben: Geben Sie immer Breite und Höhe an, um Layout-Verschiebungen zu vermeiden

4. Render-blockierende Ressourcen beseitigen

CSS und JavaScript im <head> blockieren das Rendern, bis sie geladen sind. Lösungen:

• Kritisches CSS inline einbinden: Extrahieren Sie das CSS für den sichtbaren Bereich und binden Sie es direkt ins HTML ein
• Nicht kritisches JavaScript verzögern: Ergänzen Sie defer oder async bei Skripten, die nicht sofort laufen müssen
• Ungenutztes CSS entfernen: Tools wie PurgeCSS finden und entfernen Stile, die Ihre Seite nicht nutzt

Für unsere eigene Website gilt dieselbe Liste. Als wir seomator.com am 1. Oktober 2026 durch Lighthouse geschickt haben, standen ganz oben im Bericht 253 KiB ungenutztes JavaScript und render-blockierende Anfragen mit geschätzten 150 ms Einsparung.

5. CSS, JavaScript und HTML minifizieren

Minifizierung entfernt Leerzeichen, Kommentare und unnötige Zeichen aus Ihrem Code. Die meisten Build-Tools (Webpack, Vite, Next.js) erledigen das in Produktions-Builds automatisch – prüfen Sie also zuerst, ob es aktiviert ist.

6. Server-Antwortzeit verbessern

web.dev empfiehlt: „most sites should strive to have a TTFB of 0.8 seconds or less“ (web.dev). Strategien:

• Hosting aufrüsten: Wechseln Sie von Shared Hosting zu VPS oder dedizierten Servern
• Datenbanken optimieren: Indizes ergänzen, Abfragen optimieren, Connection Pooling einsetzen
• Serverseitiges Caching nutzen: Gerendertes HTML zwischenspeichern, statt Seiten bei jeder Anfrage neu zu erzeugen
• Komprimierung aktivieren: Gzip oder Brotli verkleinern Textantworten erheblich

Ob Caching- und Komprimierungs-Header tatsächlich gesetzt sind, prüfen Sie mit unserem HTTP-Header-Checker.

7. CDN und Browser-Caching einsetzen

Ein Content Delivery Network liefert Ihre Dateien von Servern aus, die jedem Nutzer am nächsten liegen, und verkürzt so die TTFB für ein weit entferntes Publikum. Mit passenden Cache-Headern laden wiederkehrende Besucher Ihre Website fast sofort: Setzen Sie Cache-Control mit sinnvollen max-age-Werten, typischerweise ein Jahr für versionierte statische Dateien und kürzer für HTML.

8. Serverseitiges Rendering erwägen

Wenn Sie ein JavaScript-Framework nutzen, sendet serverseitiges Rendering (SSR) fertig gerendertes HTML an den Browser, statt client-seitige Skriptausführung zu verlangen. Das verbessert den LCP bei inhaltsreichen Websites erheblich. Frameworks wie Next.js, Nuxt und SvelteKit machen SSR einfach.

Häufig gestellte Fragen

Was ist ein schlechter LCP-Wert?

Ein LCP über 4 Sekunden gilt nach Googles Maßstab als „schlecht“. Auf diesem Niveau verlieren Sie wahrscheinlich Besucher, bevor sie Ihren Hauptinhalt sehen. Auch Werte zwischen 2,5 und 4 Sekunden („verbesserungswürdig“) sollten Sie vorrangig optimieren.

Wirkt sich LCP auf mobile und Desktop-Rankings unterschiedlich aus?

Google misst die Core Web Vitals für mobile und Desktop-Besuche getrennt, die Felddaten jedes Geräts werden also eigenständig bewertet. Mobil ist meist die schwierigere Seite: Verbindungen sind langsamer und Geräte schwächer – deshalb findet der Web Almanac einen guten LCP bei 62 % der mobilen gegenüber 74 % der Desktop-Seiten.

Kann ich auf Mobilgeräten und Desktop unterschiedliche LCP-Elemente haben?

Ja, und das ist häufig. Ein Desktop-Hero-Bild ist auf Mobilgeräten vielleicht ausgeblendet, sodass eine Textüberschrift zum LCP-Element wird. Testen Sie beide Viewports, um Ihre tatsächlichen LCP-Elemente je Gerät zu kennen.

Wie oft sollte ich den LCP messen?

Überwachen Sie den LCP laufend mit dem Core-Web-Vitals-Bericht der Google Search Console oder mit Real-User-Monitoring-Tools (RUM). Führen Sie Labortests nach jedem Deployment durch, das Inhalte im sichtbaren Bereich, Bilder oder das Ladeverhalten ändert.

Warum wurde mein LCP schlechter, nachdem ich mehr Inhalt ergänzt habe?

Größere Bilder, mehr JavaScript oder render-blockierende Ressourcen wirken sich direkt auf den LCP aus. Testen Sie bei neuen Inhalten immer die Auswirkung auf die Performance und optimieren Sie neue Dateien vor dem Deployment.

Soll ich das LCP-Bild vorladen oder fetchpriority verwenden?

Nutzen Sie fetchpriority="high", wenn das Bild bereits im HTML steht; es erhöht die Priorität einer Anfrage, die der Browser schon gefunden hat. Nutzen Sie <link rel="preload" as="image">, wenn das Bild spät entdeckt wird, etwa als CSS-Hintergrund oder per JavaScript eingefügt. Laden Sie es nie lazy.

Das Wichtigste in Kürze

• Zielen Sie auf einen LCP von 2,5 Sekunden oder weniger für 75 % der Seitenaufrufe, um Googles Bereich „Gut“ zu erreichen
• Die meisten rankenden Seiten verfehlen ihn im Labor: Nur 8,7 % von 115 Seite-1-Ergebnissen schafften ihn am 1. Oktober 2026
• Ermitteln Sie zuerst das Element: Auf rankenden Seiten war es ebenso oft Text (47,0 %) wie ein Bild (42,6 %)
• Bei Bild-LCPs ergänzen Sie fetchpriority="high" und laden nie lazy – 16,3 % der Bild-LCP-Seiten unserer Stichprobe taten es
• Beseitigen Sie render-blockierende Ressourcen, indem Sie kritisches CSS inline einbinden und JavaScript verzögern
• Verbessern Sie den LCP zuerst für Besucher: Google sagt, dass Relevanz vor Page Experience geht

Fazit

Largest Contentful Paint misst, wann der Hauptinhalt Ihrer Seite sichtbar wird – den Moment, in dem Nutzer Ihre Website als „geladen“ wahrnehmen. Als Core-Web-Vitals-Messwert fließt LCP in Googles Ranking-Systeme ein, doch unsere Messungen vom Oktober 2026 zeigen: Relevanz entscheidet, wer rankt; Geschwindigkeit entscheidet, wer bleibt.

Der Weg zu einem besseren LCP ist klar: Identifizieren Sie Ihr LCP-Element, optimieren Sie, wie es lädt, und entfernen Sie alles, was das Rendern verzögert. Bei einem Bild-LCP heißt das Priorität und kein Lazy Loading; bei einem Text-LCP CSS, Schriften und JavaScript.

Messen Sie Ihren aktuellen LCP zunächst mit SEOmators Speed-Test oder Google PageSpeed Insights. Wenden Sie dann die Strategien aus diesem Leitfaden an und priorisieren Sie Änderungen an Ihrem konkreten LCP-Element.

Weitere Artikel:

• Wie sich die Ladezeit auf SEO auswirkt
• Die 10 häufigsten technischen SEO-Probleme