Der Largest Contentful Paint (LCP) ist in den meisten Fällen ein Bild. Über 70 % aller Webseiten haben ein Bild als LCP-Element – nicht Text, nicht ein Video-Thumbnail. Das bedeutet: Wer LCP verbessern will, optimiert primär Bilder. Dieser Artikel erklärt Schritt-für-Schritt die Identifikation des LCP-Elements bis zur fertigen Optimierung.
Das LCP-Element identifizieren
Bevor Sie optimieren, müssen Sie wissen welches Element Google als LCP misst.
PageSpeed Insights: Führen Sie einen Test durch → Scrollen Sie zu „Diagnose” → „Largest Contentful Paint-Element” zeigt exakt welches Element gemessen wird. Meist ein Hero-Bild, Logo oder Banner.
Chrome DevTools:
- DevTools öffnen → Performance-Tab
- Seite neu laden mit Recording
- Im Timeline-Bereich auf das LCP-Ereignis klicken
- Das hervorgehobene Element ist das LCP-Element
WebPageTest: Waterfall-Ansicht zeigt welche Ressource das LCP ausgelöst hat und wie lange sie gebraucht hat.
Wichtig: Das LCP-Element kann sich unterscheiden zwischen Mobile und Desktop, zwischen Erstbesuch und Wiederholungsbesuch (Cache), und zwischen verschiedenen Viewport-Größen.
In einer Analyse von 11 Millionen URLs war das LCP-Element in 71 % der Fälle ein Bild (img, CSS background-image oder image-Element). In 29 % der Fälle war es Text – meist ein großes H1 oder ein Hero-Textblock.
fetchpriority=“high”: Das wichtigste Attribut
Das fetchpriority-Attribut ist die wirkungsvollste Einzelmaßnahme für LCP-Bilder. Es teilt dem Browser mit, dass dieses Bild höchste Ladepriorität hat.
<!-- LCP-Bild: höchste Priorität -->
<img
src="hero.webp"
alt="Hero Beschreibung"
width="1200"
height="600"
fetchpriority="high"
loading="eager"
>
Was fetchpriority bewirkt: Der Browser lädt Bilder standardmäßig mit niedrigerer Priorität als HTML, CSS und kritisches JavaScript. fetchpriority="high" hebt das Bild auf dieselbe Prioritätsstufe wie kritische Ressourcen. Das kann LCP um 200–500ms verbessern.
Nicht übertreiben: Nur das LCP-Bild sollte fetchpriority="high" bekommen. Bei mehreren high-Priorität-Ressourcen wird die Priorisierung wirkungslos.
Kompatibilität: Chrome, Edge, Safari 17+, Firefox (teilweise). Für ältere Browser ignoriert – kein Fallback nötig.
Lazy Loading beim LCP-Bild vermeiden
Ein häufiger Fehler: Das LCP-Bild hat loading="lazy". Das ist kontraproduktiv.
<!-- Falsch: LCP-Bild mit Lazy Loading -->
<img src="hero.webp" loading="lazy" alt="Hero">
<!-- Richtig: LCP-Bild immer eager laden -->
<img src="hero.webp" loading="eager" fetchpriority="high" alt="Hero">
loading="eager" ist der Standard – Sie müssen es nicht explizit setzen, aber es schadet nicht als Klarheitssignal. Alle anderen Bilder below-the-fold bekommen loading="lazy".
Responsive Images: srcset und sizes
Ein optimales LCP-Bild liefert die richtige Größe für jedes Gerät. Ein 2400px breites Bild auf einem 390px Smartphone zu laden ist eine massive LCP-Bremse.
<img
src="hero-800.webp"
srcset="
hero-400.webp 400w,
hero-800.webp 800w,
hero-1200.webp 1200w,
hero-1600.webp 1600w,
hero-2400.webp 2400w
"
sizes="
(max-width: 640px) 100vw,
(max-width: 1024px) 100vw,
1200px
"
alt="Hero Bild"
width="1200"
height="600"
fetchpriority="high"
loading="eager"
>
Was srcset macht: Der Browser wählt selbst das passende Bild basierend auf Viewport-Breite und Gerätepixelverhältnis (DPR). Ein iPhone mit 3x DPR lädt das 3x größere Bild.
Was sizes macht: Erklärt dem Browser wie groß das Bild im Layout ist bevor es geladen wird. Ohne sizes geht der Browser von 100vw aus – was zu unnötig großen Bildern auf Desktop führt.
Praxistipp: Generieren Sie für LCP-Bilder mindestens 4 Größen: ~400px (Smartphone), ~800px (Tablet Portrait), ~1200px (Desktop), ~1600px (Large Desktop). Mehr Größen = bessere Optimierung, aber auch mehr Build-Aufwand. Die Größen sollten Ihren tatsächlichen Breakpoints entsprechen.
WebP und AVIF: Moderne Bildformate
Moderne Formate sind deutlich kleiner als JPEG bei vergleichbarer Qualität:
- WebP: 25–35 % kleiner als JPEG
- AVIF: 40–55 % kleiner als JPEG (bessere Kompression, langsameres Encoding)
<!-- picture-Element für Format-Fallback -->
<picture>
<source
srcset="hero-400.avif 400w, hero-800.avif 800w, hero-1200.avif 1200w"
sizes="(max-width: 640px) 100vw, 1200px"
type="image/avif"
>
<source
srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1200.webp 1200w"
sizes="(max-width: 640px) 100vw, 1200px"
type="image/webp"
>
<img
src="hero-800.jpg"
alt="Hero Bild"
width="1200"
height="600"
fetchpriority="high"
loading="eager"
>
</picture>
Browser wählen das erste unterstützte Format. AVIF wird von Chrome und Firefox unterstützt, WebP von allen modernen Browsern. Das JPEG-Fallback fängt alte Browser auf.
Preload für LCP-Bilder
Wenn das LCP-Bild spät im HTML steht oder über CSS geladen wird, hilft ein <link rel="preload"> im <head>:
<!-- Im <head>, vor anderen Ressourcen -->
<link
rel="preload"
as="image"
href="hero-800.webp"
imagesrcset="hero-400.webp 400w, hero-800.webp 800w, hero-1200.webp 1200w"
imagesizes="(max-width: 640px) 100vw, 1200px"
fetchpriority="high"
>
Wann Preload sinnvoll ist:
- LCP-Bild ist ein CSS
background-image(wird erst nach CSS-Parsing entdeckt) - LCP-Bild steht tief im HTML (z.B. nach Slider-JavaScript)
- LCP-Bild wird durch JavaScript injiziert
Wann Preload nicht nötig ist: Wenn das <img>-Tag früh im HTML steht und bereits fetchpriority="high" hat.
Der kombinierte Einsatz von fetchpriority=“high”, Loading=“eager”, WebP-Format und responsivem srcset verbessert LCP auf mobilen Geräten durchschnittlich um 42 % – von oft 4–5 Sekunden auf unter 2,5 Sekunden.
CSS-Hintergrundbilder als LCP: Das Problem
Wenn Ihr LCP-Element ein CSS-Hintergrundbild ist (background-image: url(...)) statt ein <img>-Tag, ist das ein LCP-Problem. CSS-Hintergrundbilder werden erst nach dem CSS-Parsing entdeckt – was bedeutet, der Download startet viel später.
Lösung 1: Das Bild als <img> einbinden statt als CSS-Hintergrund (bevorzugt).
Lösung 2: Wenn CSS-Hintergrund notwendig ist, Preload-Tag im Head einsetzen:
<link rel="preload" as="image" href="hero-bg.webp" fetchpriority="high">
.hero {
background-image: url('hero-bg.webp');
}
Bildgröße und Kompression
Selbst das beste Format nützt nichts wenn die Bilder zu groß sind. Faustregel:
- LCP-Bild auf Mobile: max. 100–150 KB
- LCP-Bild auf Desktop: max. 200–300 KB
Kompression-Tools:
- Squoosh (browser-basiert, kostenlos): Visueller Qualitäts-Vergleich, gut für manuelle Optimierung
- ImageOptim (macOS): Batch-Kompression ohne sichtbaren Qualitätsverlust
- Sharp (Node.js): Automatisierte Bildkompression im Build-Prozess
WordPress: Plugins wie ShortPixel oder Imagify komprimieren automatisch beim Upload und konvertieren zu WebP.
Häufige LCP-Bild-Fehler zusammengefasst
| Problem | Symptom | Lösung |
|---|---|---|
loading="lazy" auf LCP-Bild | LCP schlecht, Bild startet spät | loading="eager" + fetchpriority="high" |
| Zu großes Bild (kein srcset) | Hohes Datenvolumen auf Mobile | srcset mit 4+ Größen |
| JPEG statt WebP/AVIF | Unnötig großes Dateivolumen | Moderne Formate mit picture-Element |
| CSS background-image als LCP | Bild wird spät entdeckt | Als <img> oder Preload-Tag |
| Kein width/height am img | CLS (Layout Shift) | Immer width und height angeben |
| Bild auf Server ohne CDN | Hohe TTFB + lange Ladezeit | CDN oder Cloudflare einsetzen |
LCP und Server-Performance: Auch perfekt optimierte Bilder können nicht einen langsamen Server kompensieren. Wenn TTFB (Time to First Byte) über 600ms liegt, beginnt der Bild-Download so spät dass LCP fast zwangsläufig schlecht wird. Gutes Hosting und Caching sind die Grundlage – Bildoptimierung der nächste Schritt.