Largest Contentful Paint (LCP): Ladezeit optimieren

Largest Contentful Paint (LCP) ist die Core-Web-Vitals-Metrik, an der die meisten Websites scheitern. Sie misst, wie lange es dauert, bis der größte sichtbare Inhaltsblock im Sichtfeld geladen ist. Dieser Artikel erklärt, wie LCP genau funktioniert, woraus sich die Ladezeit zusammensetzt, wie Sie LCP technisch optimieren und warum die Metrik für B2B-Unternehmen im DACH-Raum direkt auf Conversion und Sichtbarkeit einzahlt.

Warum LCP für Unternehmen relevant ist

LCP ist eine der drei Core Web Vitals, mit denen Google die Nutzererfahrung einer Seite bewertet. Unter den drei Metriken ist LCP die anspruchsvollste. Laut dem HTTP Archive Web Almanac 2025 erreichen 62 Prozent der mobilen und 74 Prozent der Desktop-Seiten einen guten LCP-Wert (internationale Erhebung, CrUX-Daten Juli 2025). Zum Vergleich liegen INP bei 77 Prozent und CLS bei 81 Prozent guten Werten auf Mobilgeräten. LCP ist damit der limitierende Faktor: Genau diese Metrik entscheidet am häufigsten darüber, ob eine Seite den Core-Web-Vitals-Test besteht. Insgesamt bestehen nur 48 Prozent der mobilen und 56 Prozent der Desktop-Origins alle drei Core Web Vitals (internationale Erhebung).

Für den österreichischen Markt ist die mobile Performance besonders wichtig. Im September 2025 entfielen rund 44,4 Prozent aller Internet-Seitenaufrufe in Österreich auf mobile Endgeräte (Österreich, StatCounter-Daten ohne Tablets). Mobile Nutzer:innen erleben laut Web Almanac fast doppelt so häufig schlechte LCP-Werte wie Desktop-Nutzer:innen, nämlich 13 Prozent gegenüber 7 Prozent (internationale Erhebung). Wer in Österreich fast die Hälfte seines Traffics mobil bedient, optimiert LCP also genau dort, wo die Schwäche am größten ist.

Der Business-Case ist messbar. Eine von Google dokumentierte A/B-Studie von Vodafone zeigt, dass eine 31 Prozent bessere LCP zu 8 Prozent mehr Verkäufen, einer um 15 Prozent besseren Lead-to-Visit-Rate und einer um 11 Prozent besseren Cart-to-Visit-Rate führte (internationale Studie). Auch eine Untersuchung von Deloitte Digital und Fifty-Five für Google belegt den Hebel von Geschwindigkeit: Im Retail-Segment steigerte eine um nur 0,1 Sekunden schnellere mobile Ladezeit die Conversion-Rate um 8,4 Prozent und den durchschnittlichen Bestellwert um 9,2 Prozent (internationale Studie). Für B2B-Entscheider:innen ist LCP damit keine reine Technik-Kennzahl, sondern ein direkter Hebel auf Umsatz und Lead-Qualität. Bei knappen Ranking-Entscheidungen wirkt die Metrik zudem als Tiebreaker zwischen ansonsten gleichwertigen Ergebnissen.

Wie LCP funktioniert: Schwellenwerte und Subparts

LCP misst den Zeitpunkt, zu dem der größte sichtbare Content-Block im Viewport gerendert ist. Gemessen wird ab dem Beginn des Seitenaufrufs. Als LCP-Element kommen typischerweise Hero-Bilder, grosse Textblöcke oder Videos infrage. In der Praxis dominieren Bilder: Bei 85,3 Prozent der Desktop- und 76 Prozent der mobilen Seiten ist ein Bild das LCP-Element (internationale Erhebung). Text-basierte LCP-Elemente machen den Rest aus, auf Mobilgeräten mit 23,7 Prozent etwas häufiger als auf dem Desktop.

Google definiert drei Schwellen, gemessen am 75. Perzentil der realen Nutzerdaten:

• Gut: unter 2,5 Sekunden. Dieser Wert sollte das Ziel jeder Optimierung sein.
• Verbesserungswürdig: zwischen 2,5 und 4,0 Sekunden. Hier besteht Handlungsbedarf.
• Schlecht: über 4,0 Sekunden. In diesem Bereich leidet die Nutzererfahrung deutlich.

Das 75. Perzentil bedeutet: 75 Prozent der echten Seitenaufrufe müssen den Schwellenwert erreichen. Ein guter Laborwert auf einem schnellen Entwicklungsrechner reicht also nicht, wenn langsamere Geräte und Verbindungen das Perzentil nach oben ziehen.

Um LCP gezielt zu optimieren, muss man verstehen, woraus sich die Zeit zusammensetzt. Google teilt LCP in vier Subparts:

• Time to First Byte (TTFB): die Zeit, bis der Server das erste Byte der Antwort liefert. Sie umfasst DNS, Verbindungsaufbau und die serverseitige Verarbeitung.
• Resource Load Delay: die Zeitspanne zwischen TTFB und dem Beginn des Ladens der LCP-Ressource. Hier geht Zeit verloren, wenn der Browser das LCP-Bild erst spät entdeckt.
• Resource Load Time: die reine Ladezeit der LCP-Ressource, also wie lange das Bild oder die Schriftart zum Download braucht.
• Element Render Delay: die Zeit zwischen vollständigem Laden der Ressource und ihrem tatsächlichen Rendern, oft blockiert durch JavaScript oder CSS.

Diese Aufschlüsselung ist der Schlüssel zur Diagnose. Ein langsames LCP-Bild verlangt eine andere Massnahme als ein langsamer Server oder render-blockierendes JavaScript.

Best Practices: LCP gezielt optimieren

Die wirksamsten Optimierungen setzen an den vier Subparts an. Folgende Massnahmen haben in der Praxis den größten Hebel:

• TTFB und Server senken: Ein langsamer Server ist oft der größte Einzelposten. Serverseitiges Rendering, gut konfiguriertes Caching und ein CDN mit Edge-Standorten verkürzen die Wege. HTTP/3 (QUIC) und Brotli-Kompression beschleunigen die Übertragung zusätzlich. Für DACH- und AT-Zielgruppen lohnt ein Hosting oder CDN-Edge mit kurzen Wegen zu österreichischen Nutzer:innen, etwa ein Knoten in Wien oder Frankfurt.
• LCP-Bild richtig ausliefern: Moderne Formate wie WebP und AVIF reduzieren die Dateigröße deutlich gegenüber JPEG bei gleicher Qualität. Trotzdem ist JPEG laut Web Almanac mit rund 57 Prozent weiterhin das häufigste LCP-Bildformat, WebP folgt mit 11 Prozent und AVIF erreicht erst 0,7 Prozent (internationale Erhebung). Hier liegt also Potenzial brach. Liefere responsive Varianten über srcset und sizes aus, definiere korrekte Bilddimensionen und setze fetchpriority="high" sowie ein preload für das LCP-Bild.
• Lazy-Loading des LCP-Bildes vermeiden: Das LCP-Bild darf niemals verzögert geladen werden. Laut Web Almanac lazy-loaden rund 16 bis 17 Prozent der Seiten ihr LCP-Bild (internationale Erhebung) und verschenken damit wertvolle Zeit. loading="lazy" gehört an Bilder unterhalb des Sichtfelds, nicht an das LCP-Element.
• Render-blocking beseitigen: Kritisches CSS sollte inline ausgeliefert werden, der Rest verzögert. JavaScript lädt mit defer oder async, damit es das Rendern nicht blockiert. Web-Fonts erhalten font-display: swap und ein Preload, damit Textblöcke nicht auf die Schrift warten.

Häufige Fehler bei der LCP-Optimierung

Bei der Optimierung wiederholen sich bestimmte Muster, die Ladezeit kosten:

• Das LCP-Bild lazy-laden: Der häufigste Fehler. Ein pauschales loading="lazy" auf allen Bildern trifft auch das Hero-Bild und verzögert den Resource Load Delay unnötig.
• Nur Laborwerte optimieren: Wer ausschliesslich auf Lighthouse-Werte schaut, optimiert für einen synthetischen Testlauf, nicht für reale Nutzer:innen. Das 75. Perzentil der Felddaten kann deutlich schlechter ausfallen.
• TTFB ignorieren: Viele Teams optimieren Bilder, obwohl der Server die eigentliche Bremse ist. Ohne Blick auf die Subparts wird an der falschen Stelle gearbeitet.
• Veraltete Bildformate beibehalten: Der hohe JPEG-Anteil zeigt, dass moderne Formate selten genutzt werden. Wer bei JPEG bleibt, verschenkt einen einfachen Effizienzgewinn.
• JavaScript-Hydration unterschätzen: In modernen Frameworks kann das LCP-Element fertig geladen sein, aber durch Hydration verzögert gerendert werden. Der Element Render Delay steigt, ohne dass Bild oder Server schuld sind.

LCP in der Next.js-Architektur

Next.js bietet mehrere Mechanismen, die direkt auf LCP einzahlen. Die Komponente next/image liefert automatisch moderne Formate, korrekte Dimensionen und responsive Größen aus. Für das LCP-Bild ist das priority-Prop entscheidend: Es setzt intern fetchpriority="high" und ein Preload und verhindert zugleich das Lazy-Loading. Genau ein Bild pro Seite, nämlich das LCP-Element, sollte dieses Prop erhalten.

Der App Router mit Server Components und Streaming-SSR rendert kritische Inhalte serverseitig und sendet sie früh an den Browser. Das verkürzt Resource Load Delay und Element Render Delay, weil der LCP-Inhalt nicht erst clientseitig erzeugt wird. Wichtig ist, das LCP-Element nicht hinter clientseitige Hydration zu legen. Inhalte, die als Server Component gerendert werden, stehen sofort. Werden sie dagegen in eine Client Component mit aufwändiger Hydration verschoben, steigt die Renderverzögerung.

Metriken und Messung: Feld- gegen Labordaten

LCP wird auf zwei Arten gemessen, und beide sind nötig. Felddaten stammen von echten Nutzer:innen und bilden die Realität ab. Quellen sind der Chrome User Experience Report (CrUX), PageSpeed Insights und die Google Search Console. Diese Daten bestimmen das offizielle 75. Perzentil und damit, ob eine Seite den Test besteht. Labordaten entstehen synthetisch unter kontrollierten Bedingungen, etwa mit Lighthouse oder lokalen Tools. Sie sind reproduzierbar und eignen sich, um Änderungen vor dem Deployment zu testen und einzelne Ursachen zu isolieren.

Der entscheidende Punkt: Beide ergänzen sich. Labordaten zeigen, woran es liegt, Felddaten zeigen, ob es Nutzer:innen wirklich betrifft. Eine Optimierung gilt erst dann als erfolgreich, wenn sie sich in den Felddaten niederschlägt.

Für kontinuierliche Kontrolle empfiehlt sich Real User Monitoring (RUM). Die offizielle web-vitals-Library erfasst LCP direkt im Browser echter Nutzer:innen und meldet die Werte an ein Analyse-Tool. So lassen sich Alerts einrichten und Regressionen nach Deployments früh erkennen. Ohne dieses Monitoring fällt eine LCP-Verschlechterung oft erst auf, wenn Rankings oder Conversions bereits leiden. Ein fester Platz im Deployment-Prozess, etwa ein automatischer Lighthouse-Check plus RUM-Vergleich, schützt vor schleichenden Regressionen.

LCP, KI-Crawler und GEO: die richtige Einordnung

Schnelles serverseitiges Rendering hilft nicht nur Nutzer:innen, sondern auch Crawlern. KI-Crawler und klassische Suchmaschinen-Bots profitieren davon, wenn Inhalte serverseitig und ohne lange JavaScript-Abhängigkeiten ausgeliefert werden. Dieselbe Architektur, die LCP verbessert, also SSR, schnelle TTFB und wenig render-blockierendes JavaScript, macht Inhalte auch für AI-Crawler zuverlässig zugänglich.

Wichtig ist die Abgrenzung. LCP ist eine Performance-Metrik für die Nutzererfahrung, kein direkter GEO-Faktor. Generative Engine Optimization entscheidet sich an Inhalt, Struktur und Zitierbarkeit, nicht an der Ladezeit eines Hero-Bildes. LCP zahlt indirekt ein, indem schnelles Server-Rendering die Auslieferung an Crawler erleichtert. Es ersetzt aber keine GEO-Massnahme. Wer LCP optimiert, verbessert die Erreichbarkeit, nicht die inhaltliche Relevanz für KI-Antworten.

Weiterführendes und Fazit

LCP ist die Core-Web-Vitals-Metrik mit dem größten Optimierungspotenzial und dem direktesten Business-Bezug. Wer das Ziel von unter 2,5 Sekunden im 75. Perzentil der Felddaten erreicht, verbessert nicht nur die Nutzererfahrung, sondern auch Conversion, Bounce und die Chancen bei knappen Ranking-Entscheidungen. Der Weg dorthin führt über die vier Subparts: schneller Server, früh entdecktes und modern ausgeliefertes LCP-Bild, kein Lazy-Loading des Hero-Bildes und ein render-freier Pfad ohne blockierendes CSS oder JavaScript.

Sinnvolle nächste Schritte sind eine Messung des aktuellen LCP in PageSpeed Insights und der Search Console, die Identifikation des LCP-Elements und seiner Subparts sowie die Einrichtung von Real User Monitoring für dauerhafte Kontrolle. Im österreichischen Markt mit hohem mobilen Traffic-Anteil lohnt der Fokus besonders auf der mobilen LCP, weil genau dort die größten Defizite liegen.