Hauptbereich
Agency
technisches-seo

Largest Contentful Paint (LCP) optimieren

Redaktion ·

Largest Contentful Paint, kurz LCP, ist eine der drei Core Web Vitals und beantwortet eine erstaunlich simple Frage: Wann sieht der Nutzer das größte sichtbare Element above the fold? Bei den meisten Seiten ist das ein Hero-Bild, eine große Überschrift oder ein Video-Poster. LCP misst nicht, wann die Seite fertig ist — es misst, wann der Hauptinhalt da ist. Das ist der Moment, an dem ein Mensch das Gefühl hat: „Okay, die Seite lädt.”

Google zieht für den Schwellenwert das 75. Perzentil der echten Seitenaufrufe heran, getrennt nach Mobile und Desktop. Die Bewertung (Stand web.dev, Juni 2026): gut bei ≤ 2,5 Sekunden, verbesserungswürdig bis 4,0 Sekunden, schlecht darüber. Entscheidend ist das „im Feld” — gemessen wird an echten Nutzern (CrUX-Felddaten), nicht an deinem Glasfaser-Anschluss im Büro.

Was als LCP-Element zählt

Nicht jedes Pixel ist ein Kandidat. LCP berücksichtigt <img>, <image> in SVGs, <video> (Poster oder erstes Frame), Elemente mit CSS-Hintergrundbild via url() und Block-Elemente mit Text. Heuristisch ausgeschlossen werden Elemente mit Opacity 0, vollflächige Hintergründe, Platzhalterbilder und sehr kontrastarme „Low-Entropy”-Bilder — Letzteres verhindert, dass ein graues Spinner-Placeholder als LCP zählt.

Welches dieser Elemente am Ende „das größte” ist, entscheidet der Browser dynamisch während des Ladens. Es kann sich verschieben: Zuerst ist die Headline das größte sichtbare Element, dann lädt das Hero-Bild nach und übernimmt. Genau deshalb ist die wichtigste Vorarbeit, überhaupt zu wissen, welches Element auf deiner Seite das LCP-Element ist — gemessen, nicht geraten. Lighthouse und die Chrome DevTools markieren es direkt.

Der häufigste Denkfehler: Es ist selten das Bild selbst

Die intuitive Reaktion auf einen schlechten LCP-Wert lautet: „Das Hero-Bild ist zu groß, ich komprimiere es.” Manchmal stimmt das. Oft nicht. LCP zerfällt in vier zeitliche Phasen, die nahtlos aufeinander folgen — und die Empfehlung von web.dev verteilt das Budget so:

  • Time to First Byte (TTFB) — ~40 %: die Zeit, bis der Server überhaupt das erste Byte HTML schickt.
  • Resource Load Delay — < 10 %: die Lücke zwischen TTFB und dem Moment, in dem der Browser anfängt, das LCP-Bild zu laden.
  • Resource Load Duration — ~40 %: der eigentliche Download des Bildes.
  • Element Render Delay — < 10 %: die Zeit vom fertigen Download bis zum Anzeigen.

Die Komprimierung des Bildes wirkt nur auf die „Resource Load Duration”. Wenn dein Problem aber ein langsamer TTFB ist oder ein hoher „Load Delay”, weil der Browser das Bild erst spät entdeckt, hilft das kleinere Bild kaum. Du optimierst die falsche Phase. Deshalb gilt: erst die Phasen-Verteilung deiner echten Messung ansehen, dann den passenden Hebel wählen.

TTFB: das Fundament, auf das alles wartet

Solange der Server das erste Byte nicht geschickt hat, kann der Browser nichts entdecken, nichts laden, nichts rendern. Ein TTFB von 1,5 Sekunden frisst über die Hälfte deines guten LCP-Budgets auf, bevor überhaupt ein Pixel gemalt wurde. Typische Ursachen: ungecachte serverseitige Renderings, langsame Datenbankabfragen, fehlendes CDN, oder Redirect-Ketten, die jeweils eine eigene Round-Trip-Zeit kosten.

Die wirksamsten Hebel hier: statisches HTML oder aggressives Server-Caching ausliefern, ein CDN vor die Origin setzen, Redirects eliminieren und keine zufälligen Query-Parameter anhängen, die das CDN-Caching aushebeln. TTFB ist kein SEO-Detail am Rand — es ist die Phase, die alle anderen Phasen nach hinten schiebt.

Render-blocking Ressourcen: der unsichtbare Stau

Selbst bei schnellem TTFB kann das LCP-Bild im Stau stehen. Synchron geladenes CSS und JavaScript im <head> blockieren das Rendering: Der Browser muss erst das CSS parsen und ausführen, bevor er irgendetwas anzeigt. Ein dickes externes Stylesheet oder ein Render-blocking-Script verzögert damit nicht nur das LCP-Element, sondern die gesamte erste Darstellung. Wie diese Mechanik im Detail funktioniert, steht im Artikel zu render-blocking Ressourcen.

Die Standard-Hebel: das kritische CSS inline in den <head> (nur das, was above the fold gebraucht wird), den Rest asynchron nachladen. Render-blocking JavaScript aus dem <head> entfernen oder mit defer/async entschärfen. Und lange JavaScript-Tasks aufbrechen, die den Main-Thread blockieren und das Rendern verzögern.

Die drei Bild-Hebel, die fast immer ziehen

Wenn das LCP-Element ein Bild ist, gibt es drei Eingriffe mit hohem Wirkungsgrad — und sie sind oft eine Sache von Minuten:

1. fetchpriority="high" auf das LCP-Bild. Standardmäßig priorisiert der Browser Bilder niedrig, weil er beim ersten HTML-Parse nicht weiß, welches Bild wichtig ist. Mit fetchpriority="high" sagst du ihm explizit: Dieses Bild zuerst. Das senkt vor allem das „Resource Load Delay”.

2. Niemals loading="lazy" auf das LCP-Bild. Lazy-Loading ist eine hervorragende Idee — für Bilder unterhalb des Folds. Auf das LCP-Element angewendet, ist es ein Eigentor: Der Browser wartet bewusst, bis das Element fast im Viewport ist, bevor er lädt. Genau das Gegenteil von dem, was du willst. Eine einzige falsche loading="lazy"-Angabe am Hero-Bild kann den LCP-Wert um Sekunden verschlechtern.

3. Moderne Bildformate und korrekte Dimensionen. AVIF oder WebP statt JPEG/PNG verkleinern den Download drastisch (das wirkt auf die „Resource Load Duration”). Responsive srcset-Größen verhindern, dass Mobile-Nutzer ein 2000-px-Desktop-Bild herunterladen.

Wenn das LCP-Bild erst spät im DOM auftaucht oder per CSS-Hintergrund geladen wird (und damit beim HTML-Parse unsichtbar ist), hilft zusätzlich ein <link rel="preload" fetchpriority="high"> im <head> — damit der Browser das Bild entdeckt, bevor er das CSS ausgewertet hat.

Lab vs. Field: warum dein Lighthouse-90 trügt

Lighthouse und PageSpeed Insights liefern zwei Arten von Daten, und sie werden ständig verwechselt. Lab-Daten sind eine simulierte Einzelmessung unter standardisierten Bedingungen — reproduzierbar, gut zum Debuggen, aber nicht das, was Google für das Ranking nutzt. Field-Daten (CrUX) sind aggregierte echte Nutzererfahrungen der letzten 28 Tage — das ist die Grundlage des 75-Perzentil-Schwellenwerts.

Ein Lighthouse-LCP von 1,8 s im Lab und ein Feld-LCP von 3,4 s sind kein Widerspruch: Deine echten Nutzer sitzen auf langsameren Geräten und Netzen als der simulierte Test. Optimiere gegen die Felddaten, debugge mit den Lab-Daten. Und gib einer Änderung 28 Tage, bis sie sich im CrUX-Fenster voll niederschlägt.

LCP ist nur eines der drei Core Web Vitals — INP (Interaktivität) und CLS (Layout-Stabilität) gehören dazu. Wie LCP sich in den größeren Bogen aus Crawlen, Rendern und Indexieren einordnet, steht im Hub-Artikel Technisches SEO.

FAQ

Was ist ein guter LCP-Wert? ≤ 2,5 Sekunden gilt als gut, gemessen am 75. Perzentil echter Seitenaufrufe, getrennt nach Mobile und Desktop (Stand web.dev, Juni 2026). Werte bis 4,0 s sind verbesserungswürdig, darüber schlecht. Wichtig ist die Feldmessung an echten Nutzern, nicht der Lab-Wert im Test.

Mein LCP-Bild ist klein, trotzdem ist der LCP schlecht — warum? Weil das Bild selbst meist nicht das Problem ist. LCP besteht zu rund 80 % aus TTFB und dem eigentlichen Download, plus zwei Verzögerungsphasen. Ein langsamer Server (TTFB) oder render-blocking CSS/JS, das das Laden des Bildes hinauszögert, drückt den Wert genauso — unabhängig von der Bildgröße. Sieh dir die Phasen-Verteilung deiner Messung an.

Was bringt fetchpriority="high"? Es sagt dem Browser explizit, dass dieses Bild Vorrang hat. Ohne den Hinweis priorisiert der Browser Bilder anfangs niedrig, weil er nicht weiß, welches wichtig ist. Auf dem LCP-Bild gesetzt, beginnt der Download früher und das „Resource Load Delay” sinkt. Ein kleiner Eingriff mit oft messbarer Wirkung.

Darf ich Lazy-Loading auf das Hero-Bild setzen? Nein. loading="lazy" ist für Bilder unterhalb des sichtbaren Bereichs gedacht. Auf dem LCP-Element verzögert es den Ladestart bewusst und verschlechtert den LCP-Wert oft um Sekunden. Lazy-Loading gehört auf alles unterhalb des Folds, niemals auf das größte sichtbare Element.

Was ist der Unterschied zwischen Lab- und Field-Daten? Lab-Daten sind eine simulierte Einzelmessung (Lighthouse) unter Standardbedingungen — gut zum Debuggen. Field-Daten (CrUX) sind aggregierte echte Nutzererfahrungen der letzten 28 Tage und die Grundlage für Googles Bewertung. Optimiere gegen die Felddaten, debugge mit den Lab-Daten, und plane 28 Tage ein, bis Änderungen voll sichtbar sind.

Themenuebersicht

Technisches SEOCore Web VitalsPageSpeed & Performance