Der Largest Contentful Paint (LCP) misst, wie lange es dauert, bis das größte sichtbare Bild, Video oder der größte Textblock im Viewport gerendert ist, gerechnet ab dem Beginn des Seitenaufrufs. Er gehört zu den Core Web Vitals und beschreibt die wahrgenommene Ladegeschwindigkeit.
Auf einen Blick
- Misst
- Renderzeit des größten Bildes, Textblocks oder Videos im Viewport, ab Beginn des Seitenaufrufs
- Grenze „gut“
- 2,5 Sekunden oder weniger
- Bewertung
- 75. Perzentil der Seitenaufrufe, Mobil und Desktop getrennt
- Datenquelle
- Feld (CrUX, PageSpeed Insights, Search Console) und Labor (Lighthouse, Chrome DevTools)
- Core Web Vital
- Ja, eine der drei Core Web Vitals
Stand:
Was zählt als LCP-Element?
Laut web.dev kommen folgende Elemente infrage:
<img>-Elemente<image>-Elemente innerhalb von<svg><video>-Elemente- Elemente mit einem CSS-Hintergrundbild über
url() - Block-Elemente mit Text
Welches Element das größte ist, kann sich während des Ladens ändern. Der Browser meldet jeweils den aktuellen Kandidaten, bis zur ersten Interaktion der Nutzer mit der Seite (Tippen, Scrollen oder Tastendruck).
Grenzwerte
Bewertet wird das 75. Perzentil der Seitenaufrufe, Mobil und Desktop getrennt. Quelle: web.dev: Largest Contentful Paint (LCP). Stand: .
Maßgeblich ist das 75. Perzentil aller Seitenaufrufe, getrennt nach Mobilgeräten und Desktop. Drei von vier Besuchen sollten also höchstens 2,5 Sekunden brauchen. Feldwerte liefern etwa der Chrome User Experience Report, PageSpeed Insights und die Search Console. Labortools wie Lighthouse oder die Chrome DevTools simulieren den Ladevorgang.
| Messwert | Misst | Core Web Vital? | Feld oder Labor | „Gut“ laut web.dev |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) (dieser Begriff) | Renderzeit des größten sichtbaren Bilds, Textblocks oder Videos im Viewport, ab Beginn der Navigation | ja (Laden) | Feld und Labor | bis 2,5 s |
| INP (Interaction to Next Paint) | Latenz der Interaktionen während des gesamten Besuchs bis zur nächsten Darstellung; ein Wert, unter dem (fast) alle Interaktionen liegen | ja (Interaktivität), seit 12.03.2024 | Feld; im Labor nur mit simulierten Interaktionen, Lighthouse misst INP nicht | bis 200 ms |
| CLS (Cumulative Layout Shift) | größte Folge unerwarteter Layoutverschiebungen während der gesamten Lebensdauer der Seite | ja (visuelle Stabilität) | Feld und Labor | bis 0,1 |
| TTFB (Time to First Byte) | Zeit vom Beginn der Navigation bis zum ersten Byte der Antwort | nein (hilft bei der Diagnose von LCP) | Feld und Labor | bis 0,8 s |
| FCP (First Contentful Paint) | Zeit vom Beginn der Navigation, bis irgendein Inhalt der Seite dargestellt wird | nein (hilft bei der Diagnose von LCP) | Feld und Labor | bis 1,8 s |
| TBT (Total Blocking Time) | Summe der Zeit nach dem FCP, in der der Hauptthread so lange blockiert war, dass Eingaben nicht reagieren konnten | nein (Labor-Stellvertreter für INP) | Labor; Feldmessung empfiehlt web.dev nicht | unter 200 ms auf durchschnittlicher mobiler Hardware |
| Speed Index | wie schnell Inhalte beim Laden sichtbar aufgebaut werden (aus einem Video des Ladevorgangs) | nein | Labor (Lighthouse) | Schwelle laut Lighthouse: mobil bis 3,4 s „schnell“ (web.dev nennt keinen Wert) |
| FID (First Input Delay), historisch | Zeit von der ersten Interaktion bis der Browser mit der Verarbeitung der Event-Handler beginnen kann | bis 12.03.2024, ersetzt durch INP | nur Feld | bis 100 ms |
Bewertet wird laut web.dev das 75. Perzentil der Seitenaufrufe, Mobil und Desktop getrennt. Eine Seite besteht die Core Web Vitals, wenn LCP, INP und CLS am 75. Perzentil im Bereich „gut“ liegen. Chrome-Tools unterstützen FID seit dem 9. September 2024 nicht mehr. Quellen: web.dev: Web Vitals; web.dev: Largest Contentful Paint (LCP); web.dev: Interaction to Next Paint (INP); web.dev: Cumulative Layout Shift (CLS); web.dev: Time to First Byte (TTFB); web.dev: First Contentful Paint (FCP); web.dev: Total Blocking Time (TBT); web.dev: First Input Delay (FID); web.dev Blog: Interaction to Next Paint is officially a Core Web Vital (2024-03-12); Chrome for Developers: Lighthouse – Speed Index. Stand: .
Woraus sich der LCP zusammensetzt
web.dev teilt den LCP in vier Abschnitte auf:
- Time to First Byte (TTFB), grob 40 % der Zeit
- Ladeverzögerung der LCP-Ressource, unter 10 %
- Ladedauer der Ressource, grob 40 %
- Render-Verzögerung bis zur Darstellung, unter 10 %
Diese Anteile sind Richtwerte. Die Aufteilung zeigt, ob eher der Server, der späte Fund der Ressource oder die Dateigröße bremst.
Beispiel
Ein Hero-Bild steht im HTML mit loading="lazy". Der Browser lädt es erst, nachdem das Layout feststeht. web.dev rät ausdrücklich davon ab, LCP-Bilder verzögert zu laden. Mit fetchpriority="high" lässt sich ein Bild stattdessen früh und mit hoher Priorität abrufen.
<img src="/hero.avif" width="1200" height="600"
fetchpriority="high" alt="Produktfoto">
Häufige Fehler
- LCP-Bild mit
loading="lazy". web.dev schreibt, das LCP-Bild nie verzögert zu laden, da dies immer zu unnötiger Ladeverzögerung führt. - Ressource erst per JavaScript im HTML. Bilder, die per Skript eingefügt werden, ein
data-srcstattsrctragen oder nur als CSS-Hintergrund vorliegen, findet der Browser spät. - Keine Priorität für das LCP-Bild. Bilder haben standardmäßig keine hohe Priorität.
fetchpriority="high"hilft bei wahrscheinlichen LCP-Elementen, verliert aber an Wirkung, wenn es überall steht. - Render-blockierende Dateien. Große Stylesheets oder synchrone Skripte können die Darstellung verzögern, auch wenn die Ressource schon geladen ist.
Häufige Fragen
Was ist ein guter LCP-Wert? Bis 2,5 Sekunden, gemessen am 75. Perzentil.
Worin unterscheidet sich LCP von FCP? Der First Contentful Paint misst den ersten gerenderten Inhalt, der LCP den größten sichtbaren. Der LCP liegt daher meist später.
Quellen
Stand: