Ratgeber · Web-Performance 2026
Largest Contentful Paint: was misst LCP wirklich?
Welches Element ist eigentlich der LCP-Kandidat, warum Hero-Bilder fast immer der Engpass sind und wie man Preload + fetchpriority kombiniert.
Von Mateusz Viola
Betreiber & redaktionelle Verantwortung pagespeed-test.de
Veröffentlicht
Aktualisiert:
Was wird beim LCP gemessen?
Largest Contentful Paint misst die Zeit, bis das größte sichtbare Inhaltselement im Viewport gerendert ist. Das kann ein Bild, ein Video-Poster, ein Hintergrundbild oder ein Textblock sein - aber nur Elemente, die ohne Scrollen sichtbar werden. Elemente unter dem Fold zählen nicht.
Der LCP-Kandidat wechselt während des Ladens mehrfach: erst ist der H1 das größte Element, dann lädt ein Hero-Bild und übernimmt. Gemessen wird der Zeitpunkt, an dem das finale größte Element fertig ist.
Die fünf häufigsten LCP-Killer
| # | Problem | Typischer Fix |
|---|---|---|
| 1 | Hero-Bild lädt zu spät (kein Preload, kein fetchpriority) | <link rel="preload" as="image" fetchpriority="high"> |
| 2 | Hohe TTFB (langsamer Server) | CDN + Edge-Caching + statisches Pre-Rendering |
| 3 | Render-blocking CSS-Bundle | Critical CSS inline, Rest async laden |
| 4 | Webfont blockiert Text-Rendering | font-display: swap + Self-Hosting + Preload |
| 5 | JavaScript blockiert Hauptthread vor LCP | defer + Code-Splitting + Third-Party-Scripts asynchron |
Bilder-Preload mit fetchpriority
Die wichtigste einzelne LCP-Optimierung für die meisten Seiten ist das Preloaden des Hero-Bildes mit hoher Priorität:
<link rel="preload" as="image"
href="/hero.avif"
type="image/avif"
fetchpriority="high">Damit beginnt der Browser das Bild parallel zum HTML zu laden und stuft es als kritisch ein. Wichtig: nur das tatsächliche LCP-Bild preloaden, sonst wird die Bandbreite für unwichtige Assets verschwendet.
TTFB ist die Untergrenze
LCP kann nie schneller sein als TTFB. Wenn der Server 1,5 s für die HTML-Response braucht, ist LCP unter 2 s unmöglich. Hier hilft kein Frontend-Trick mehr - die richtige Schicht ist Hosting oder Caching. Statische Seiten auf Netlify, Vercel oder Cloudflare Pages liegen bei TTFB typisch unter 100 ms (gegen 500-1500 ms bei klassischem Shared-Hosting).
Critical CSS inline
Wenn dein CSS-Bundle 200 KB groß ist, blockiert es das Rendering bis es geladen und geparst ist. Das verzögert LCP. Die Lösung: das CSS, das für den initial sichtbaren Bereich nötig ist (Critical Path CSS), inline im <head> einbetten - der Rest wird per <link rel="preload"> nachgeladen. Tools wie Critters oder PurgeCSS extrahieren den kritischen Pfad automatisch.
Messen statt raten
Bevor optimiert wird, sollte der LCP-Kandidat identifiziert sein. In den Chrome DevTools unter Performance → Reload zeigt der LCP-Marker das genaue Element. Oft ist es nicht das vermutete - ein langes H1 schlägt manchmal das kleine Hero-Bild.