Begriff
LCP — Glossar
Direkte Antwort
LCP: Der Largest Contentful Paint gibt an, wie viele Sekunden vergehen, bis der größte sichtbare Inhalt im ersten Bildschirm fertig gezeichnet ist — meist ein Hero-Bild oder eine große Überschrift. Bis 2,5 Sekunden ist der Wert gut, über 4,0 Sekunden schlecht. Du senkst ihn mit schneller Serverantwort, richtig dimensionierten Bildern und weniger blockierendem Code.
Wichtigste Punkte
- LCP bewertet die gefühlte Ladegeschwindigkeit: Wann sieht der Besucher den Hauptinhalt?
- Grenzwerte: gut ≤ 2,5 s, schlecht > 4,0 s — gemessen am 75. Perzentil echter Besuche.
- Vier Phasen entscheiden: Serverantwort, Entdecken, Herunterladen und Rendern des Elements.
- Teil der Core Web Vitals neben INP und CLS.
— Steve Baka
Aktualisiert: · Autor: Steve Baka
Was ist der Largest Contentful Paint?
LCP ist eine Messgröße aus den Core Web Vitals von Google. Sie erfasst den Zeitpunkt, zu dem das größte Element im sichtbaren Bereich der Seite gerendert wurde. Als Kandidaten zählen Bilder, das Vorschaubild eines Videos, Hintergrundbilder, die per CSS geladen werden, und Textblöcke auf Blockebene. Während die Seite lädt, kann sich der Kandidat ändern: Erst erscheint eine Überschrift, dann ein größeres Bild. Der endgültige Wert ist der letzte gemeldete Kandidat vor der ersten Nutzereingabe.
Anders als technische Kennzahlen wie die Serverzeit beantwortet LCP eine Nutzerfrage: „Ist da, was ich sehen wollte?“ Deshalb steht die Metrik für Wahrnehmung, nicht für Rechenzeit. Wichtig ist außerdem, dass Google nach dem 75. Perzentil bewertet. Wenn drei von vier Besuchen schnell sind, der vierte aber nicht, zählt der langsamere Wert — mobile Verbindungen im Funkloch eingeschlossen.
Aus welchen Phasen besteht der LCP?
Die Optimierungsanleitung von web.dev teilt die Zeit in vier Abschnitte, die sich addieren:
- Time to First Byte: Wie lange braucht der Server für das HTML? Hier wirken Hosting, Caching und CDN.
- Ladeverzögerung der Ressource: Wann erfährt der Browser überhaupt vom Hero-Bild? Steht es nur im CSS oder wird es per Skript nachgeladen, entsteht eine Lücke.
- Ladedauer der Ressource: Wie groß ist die Datei? Ein 2-MB-JPEG kostet Sekunden, ein passend skaliertes AVIF Millisekunden.
- Render-Verzögerung: Blockieren Stylesheets, Skripte oder Webfonts das Zeichnen, obwohl die Datei längst da ist?
Wer nur „die Seite komprimiert“, trifft oft die falsche Phase. Messe zuerst, wo die Zeit steckt, und beseitige dann den größten Anteil.
Welche Maßnahmen senken den LCP?
- Bild priorisieren: Das LCP-Bild nicht lazy laden, sondern im HTML früh referenzieren und mit
fetchpriority="high"markieren. - Formate und Größen: Moderne Formate, passende
srcset-Breiten, keine Desktop-Grafik auf dem Handy. - Server und Caching: Fertig gerendertes HTML per SSG oder SSR am Edge ausliefern.
- Blocker entfernen: Kritisches CSS inline, Skripte mit
defer, Webfonts mitfont-displayund Preload. - DOM verschlanken: Tief verschachtelte Pagebuilder-Strukturen verzögern das Rendern, weil der Browser mehr Knoten verarbeiten muss.
LCP bei Modern Stack: Wie wir ihn senken
Bei Modernisierungen messen wir LCP vor und nach dem Umbau mit Labor- und Felddaten. Typische Ausgangslage ist ein WordPress-Auftritt mit Pagebuilder und Slider, dessen LCP deutlich über 2,5 Sekunden liegt. Auf Next.js mit Vercel liefern wir schlankes, vorgerendertes HTML, definieren das Hero-Bild gezielt als priorisierte Ressource und verzichten auf Slider-Skripte. Der gleiche Aufbau hilft Crawlern und KI-Systemen, weil der Inhalt ohne Skriptausführung im Dokument steht. Mehr zum Vorgehen: Core Web Vitals & Modernisierung.
Welche Fehler treten häufig auf?
Ein Slider als erstes Element, dessen erstes Bild erst per JavaScript nachgeladen wird. Ein Hero-Video, das als größtes Element ein riesiges Poster lädt. Lazy Loading ausgerechnet auf dem wichtigsten Bild. Und die Annahme, ein CDN allein löse das Problem — es beschleunigt Auslieferung, nicht aufgeblähtes Markup.
Verwandte Themen
Quellen
- web.dev — Largest Contentful Paint (LCP) — Google web.dev
Offizielle Definition, Grenzwerte und Messmethode.
- web.dev — Optimize Largest Contentful Paint — Google web.dev
Zerlegt LCP in vier Teilphasen mit konkreten Optimierungen.
- Core Web Vitals & Modernisierung — Modern Stack
Praxis, wie wir Performance bei Modernisierungen messen und verbessern.
Häufige Fragen
Welcher LCP-Wert ist gut?
Bis 2,5 Sekunden gilt als gut, zwischen 2,5 und 4,0 Sekunden als verbesserungswürdig, darüber als schlecht. Bewertet wird das 75. Perzentil echter Besuche, getrennt nach Mobil und Desktop.
Welches Element zählt als LCP?
Das größte sichtbare Bild, Video-Vorschaubild, Hintergrundbild per CSS oder der größte Textblock im ersten Bildschirm. Welches das ist, zeigen Chrome DevTools und PageSpeed Insights.
Ist ein guter LCP eine Ranking-Garantie?
Nein. Die Core Web Vitals sind ein Signal unter vielen. Ein schlechter LCP kostet aber Besucher, bevor Inhalte überhaupt gelesen werden, und verschlechtert damit Anfragen.
Weiterlesen
- Core Web Vitals
Core Web Vitals sind Googles drei Nutzererlebnis-Kennzahlen: LCP (Ladezeit des größten Elements), INP (Reaktionszeit auf Eingaben) und CLS (visuelle Stabilität). Sie fließen in die Suche ein und zeigen Timeout- und Abbruchrisiken auch für KI-Crawler.
- Core Web Vitals & Modernisierung
Warum LCP, INP und CLS zur Webseite-Modernisierung gehören — und warum CDN-Caching allein selten reicht, wenn WordPress oder Pagebuilder das Markup aufblasen.
- INP
INP (Interaction to Next Paint) ist ein Core Web Vital, der misst, wie schnell eine Webseite nach Klick, Tipp oder Tastendruck sichtbar reagiert. Gut sind 200 Millisekunden oder weniger; schweres JavaScript und aufgeblähte Pagebuilder verschlechtern den Wert.
- CDN
Ein CDN (Content Delivery Network) ist ein verteiltes Netz aus Cache-Servern (PoPs), das statische und oft auch gerenderte Dateien geografisch nah am Nutzer ausliefert — statt alles vom Origin-Server zu ziehen.
- CLS
CLS (Cumulative Layout Shift) ist eine Core-Web-Vitals-Kennzahl für visuelle Stabilität: Sie summiert unerwartete Layout-Sprünge beim Laden. Gut ist ein Wert bis 0,1. Ursachen sind fehlende Bildmaße, späte Fonts und Cookie-Banner ohne Platzreserve.
- SSR
SSR (Server-Side Rendering) erzeugt das HTML einer Seite auf dem Server pro Anfrage, statt es dem Browser per JavaScript zusammenbauen zu lassen. Crawler, Assistenten und Nutzer erhalten den Inhalt sofort im ersten Response.