Warum LCP über den ersten Eindruck entscheidet
Der Largest Contentful Paint (LCP) misst, wann das größte sichtbare Element deiner Seite fertig gerendert ist – meist das Hero-Bild oder die Überschrift ganz oben. Er beantwortet damit nicht die technische Frage „Wann ist alles geladen?", sondern die einzige, die Nutzer wirklich interessiert: Wann sehe ich, worum es hier geht?
Genau deshalb ist LCP der Core-Web-Vitals-Wert mit dem größten Hebel. Er fließt als einziger der drei Werte direkt in die wahrgenommene Geschwindigkeit ein – und wer ihn verbessert, senkt fast immer auch die Absprungrate.
| Bewertung | LCP-Wert | Bedeutung |
|---|---|---|
| Gut | bis 2,5 Sekunden | Ziel für alle Seitentypen |
| Verbesserungswürdig | 2,5 bis 4,0 Sekunden | Handlungsbedarf, aber kein Notfall |
| Schlecht | über 4,0 Sekunden | Nutzer springen messbar ab |
Wichtig für die Einordnung: Google bewertet das 75. Perzentil aller Seitenaufrufe. Es reicht also nicht, wenn die Seite auf deinem Glasfaseranschluss schnell ist – drei von vier echten Besuchen müssen unter 2,5 Sekunden liegen, inklusive Mobilfunk und älterer Geräte.
Merksatz: LCP misst nicht, wann deine Seite fertig ist. Er misst, wann sie ihr Versprechen einlöst.
Welches Element ist überhaupt dein LCP-Element?
Bevor du optimierst, musst du wissen, was du optimierst. Als LCP-Kandidat zählt der Browser nur das, was im ersten sichtbaren Bereich (Viewport) am meisten Fläche einnimmt:
<img>-Elemente und Bilder innerhalb eines<svg><video>-Elemente mit Poster-Bild- Elemente mit einem Hintergrundbild, das über
url()geladen wird - Block-Elemente mit Text – also typischerweise deine H1 oder der Einleitungsabsatz
In der Praxis ist das LCP-Element in über 70 Prozent aller Fälle ein Bild. Welches es bei dir ist, zeigt dir der Bericht von PageSpeed Insights direkt an – oder die Chrome DevTools unter Performance → Timings → LCP. Ein Klick auf den Marker markiert das Element im Seitenaufbau.
Das lohnt sich, denn hier passiert der häufigste Denkfehler: Optimiert wird das Bild, das am wichtigsten wirkt – während das tatsächliche LCP-Element ein unscheinbares Hintergrundbild im Header ist.
Die vier Phasen: Wo deine Sekunden verloren gehen
Ein LCP-Wert ist keine einzelne Zahl, sondern die Summe aus vier Abschnitten. Wer sie kennt, optimiert gezielt statt auf Verdacht:
| Phase | Was passiert | Zielanteil am LCP |
|---|---|---|
| Time to First Byte (TTFB) | Server liefert das erste Byte HTML | ca. 40 % |
| Resource Load Delay | Zeit, bis der Browser das Bild überhaupt anfordert | unter 10 % |
| Resource Load Duration | Download des Bildes selbst | ca. 40 % |
| Element Render Delay | Zeit vom fertigen Download bis zur Anzeige | unter 10 % |
Der aufschlussreichste Wert ist fast immer das Load Delay. Ist es hoch, liegt es nicht an deinem Server und nicht an der Bildgröße – sondern daran, dass der Browser zu spät erfährt, dass er dieses Bild dringend braucht. Genau dort liegen die schnellsten Erfolge, und dafür braucht es keine neue Hosting-Umgebung.
Maßnahme 1: TTFB senken
Jede Millisekunde, die der Server zum Antworten braucht, geht direkt in den LCP ein. Der Hebel ist selten der Prozessor, sondern fast immer das Caching:
- Full-Page-Caching aktivieren, damit HTML nicht bei jedem Aufruf neu erzeugt wird
- Datenbankabfragen reduzieren – gerade Plugins, die auf jeder Seite Fremddaten abrufen
- CDN einsetzen, damit Auslieferung geografisch nah am Nutzer passiert
- Redirect-Ketten auflösen: Jede Weiterleitung kostet eine komplette Roundtrip-Zeit, bevor überhaupt HTML fließt
Ein guter TTFB liegt bei unter 800 Millisekunden. Alles darüber ist bereits ein Drittel deines LCP-Budgets, bevor der erste Pixel gezeichnet ist.
Maßnahme 2: Dem Browser das LCP-Bild früh verraten
Das ist der wirkungsvollste Einzelschritt – und meistens eine Zeile Code. Standardmäßig entdeckt der Browser Bilder erst, wenn er das HTML bis dorthin geparst und das CSS verarbeitet hat. Mit fetchpriority="high" sagst du ihm sofort, was Priorität hat:
<img src="/img/hero.webp"
width="1200" height="675"
alt="Produktübersicht"
fetchpriority="high"
decoding="async">Liegt das Bild in einem Hintergrund-Style oder wird es erst per JavaScript eingefügt, hilft ein Preload im <head>:
<link rel="preload" as="image"
href="/img/hero.webp"
fetchpriority="high">Und der wichtigste Punkt zum Schluss – der in der Praxis am häufigsten falsch gemacht wird:
Niemals loading="lazy" am LCP-Bild. Viele CMS setzen das Attribut automatisch auf alle Bilder. Genau am Hero-Bild verzögert es den Ladestart und kostet regelmäßig eine halbe bis ganze Sekunde.
Bei externen Bildquellen kommt ein <link rel="preconnect"> auf die fremde Domain dazu, damit DNS-Auflösung und TLS-Handshake nicht erst beim Bildabruf beginnen.
Maßnahme 3: Das Bild selbst kleiner machen
Ist der Ladestart optimiert, entscheidet die Dateigröße. Drei Schritte holen hier fast immer den Großteil heraus:
- Moderne Formate nutzen – WebP spart gegenüber JPEG typischerweise 25 bis 35 Prozent, AVIF noch mehr. Beide werden von allen aktuellen Browsern unterstützt.
- Wirklich passende Abmessungen ausliefern – ein 3000 Pixel breites Foto in einem 800-Pixel-Container ist reine Verschwendung. Über
srcsetundsizesbekommt jedes Gerät die passende Variante. - Qualität bewusst wählen – zwischen Qualitätsstufe 90 und 80 sieht man bei Fotos praktisch keinen Unterschied, die Datei schrumpft aber deutlich.
Als Faustregel: Ein Hero-Bild sollte unter 200 KB liegen. Alles darüber braucht auf Mobilfunk länger als dein gesamtes LCP-Budget.
Maßnahme 4: Render-blockierende Ressourcen entschärfen
Ein Bild kann noch so schnell da sein – solange der Browser auf CSS oder Skripte wartet, zeichnet er nichts. Das schlägt sich im Render Delay nieder:
- Kritisches CSS inline in den
<head>, der Rest asynchron nachgeladen - Ungenutztes CSS entfernen – große Frameworks liefern oft ein Vielfaches dessen aus, was eine Seite braucht
- JavaScript mit
deferoderasynceinbinden, damit das Parsen nicht blockiert - Drittanbieter-Skripte prüfen: Chat-Widgets, A/B-Testing-Tools und Consent-Banner blockieren häufig genau den ersten Seitenaufbau
Besonders heikel sind Consent-Management-Tools, die den Inhalt erst nach der Zustimmung rendern. Dann startet der LCP faktisch erst mit dem Klick des Nutzers.
Maßnahme 5: Web-Fonts, die den Text nicht aufhalten
Ist dein LCP-Element ein Textblock, entscheidet die Schriftart. Ohne Vorkehrung zeigt der Browser den Text erst, wenn die Font geladen ist – der LCP wartet mit.
@font-face {
font-family: "Inter";
src: url("/fonts/inter.woff2") format("woff2");
font-display: swap;
}font-display: swap zeigt den Text sofort in einer Systemschrift und tauscht ihn später aus. Damit dieser Tausch keine Layout-Sprünge auslöst, sollte die Fallback-Schrift über size-adjust an die Zielschrift angeglichen werden – sonst verbesserst du den LCP und verschlechterst den CLS. Zusätzlich gilt: Fonts selbst hosten und die wirklich benötigten Schnitte per <link rel="preload"> vorladen.
Labordaten und Felddaten auseinanderhalten
Ein LCP-Wert ohne Kontext führt in die Irre. Es gibt zwei Messarten, und sie beantworten unterschiedliche Fragen:
- Labordaten entstehen in einer simulierten Umgebung mit festen Bedingungen. Sie sind reproduzierbar und ideal, um eine Änderung zu bewerten.
- Felddaten stammen von echten Nutzern mit echten Geräten und Verbindungen. Sie sind die Grundlage für Googles Bewertung – reagieren aber erst über Wochen auf Änderungen.
Der praktische Weg: Mit Labordaten optimieren, weil sie sofort Feedback geben. Mit Felddaten kontrollieren, ob die Verbesserung bei echten Nutzern ankommt. Weichen beide stark ab, liegt es meist an Nutzern mit langsameren Geräten – oder an Regionen ohne CDN-Abdeckung.
LCP im VitoScore-Bericht lesen
Dein kostenloser VitoScore-Check zeigt den LCP als eigenen Messwert innerhalb der Performance-Kategorie – zusammen mit den anderen Core Web Vitals und einer Einordnung nach Ampelprinzip. Zwei Details lohnen dabei besonderen Blick:
- Mobil vor Desktop. Die mobilen Werte fallen fast immer schlechter aus, und sie sind die Grundlage der Bewertung. Ein grüner Desktop-Wert bei rotem Mobilwert bedeutet Handlungsbedarf.
- Vorher-Nachher messen. Führe nach jeder Maßnahme einen neuen Check durch. Nur so siehst du, welcher der fünf Schritte bei deiner Seite tatsächlich gewirkt hat – Vermutungen kosten hier am meisten Zeit.
Wer den Verlauf über Wochen verfolgen will, findet in der Verlaufsansicht die Entwicklung des Scores – hilfreich, um schleichende Verschlechterungen nach Theme- oder Plugin-Updates früh zu erkennen.
Häufige Fragen
Wie schnell wirken LCP-Verbesserungen auf das Ranking?<br> Technisch sofort – sichtbar in Googles Bewertung erst nach mehreren Wochen, weil die Felddaten über ein rollierendes 28-Tage-Fenster erhoben werden.
Reicht es, nur das Hero-Bild zu optimieren?<br> Für den ersten großen Sprung meistens ja. Bleibt der Wert danach hoch, liegt die Ursache fast immer im TTFB oder in render-blockierendem CSS.
Zählt LCP auch für Unterseiten?<br> Ja. Google bewertet Seiten einzeln, nicht die Domain als Ganzes. Gerade Produkt- und Kategorieseiten mit vielen Bildern verdienen eigene Aufmerksamkeit.
Was ist mit sehr langen Seiten?<br>
Nur der sichtbare Bereich beim Laden zählt. Alles unterhalb des Viewports beeinflusst den LCP nicht – dort ist loading="lazy" sogar ausdrücklich sinnvoll.
Fazit
LCP ist der Core-Web-Vitals-Wert, der sich am zuverlässigsten verbessern lässt – weil die Ursachen selten exotisch sind. In fast allen Fällen genügt diese Reihenfolge:
- LCP-Element identifizieren
loading="lazy"entfernen undfetchpriority="high"setzen- Bild in modernem Format und passender Größe ausliefern
- TTFB über Caching senken
- Render-blockierendes CSS und JS reduzieren
Wer diese fünf Schritte durchgeht, landet bei den meisten Seiten unter der 2,5-Sekunden-Marke. Starte mit einem kostenlosen Check deiner Seite und arbeite dich anschließend durch die anderen beiden Core Web Vitals: INP verbessern und CLS senken. Den Gesamtzusammenhang erklärt unser Core-Web-Vitals-Guide.
