SEOFX – SEO Agentur Nürnberg
Technisches SEO

LCP durch Bilder optimieren: Schritt-für-Schritt

6 Min. Lesezeit

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:

  1. DevTools öffnen → Performance-Tab
  2. Seite neu laden mit Recording
  3. Im Timeline-Bereich auf das LCP-Ereignis klicken
  4. 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

ProblemSymptomLösung
loading="lazy" auf LCP-BildLCP schlecht, Bild startet spätloading="eager" + fetchpriority="high"
Zu großes Bild (kein srcset)Hohes Datenvolumen auf Mobilesrcset mit 4+ Größen
JPEG statt WebP/AVIFUnnötig großes DateivolumenModerne Formate mit picture-Element
CSS background-image als LCPBild wird spät entdecktAls <img> oder Preload-Tag
Kein width/height am imgCLS (Layout Shift)Immer width und height angeben
Bild auf Server ohne CDNHohe TTFB + lange LadezeitCDN 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.

LCP und Core Web Vitals verbessern?

Wir analysieren Ihre LCP-Performance, identifizieren das LCP-Element und optimieren Bilder, Ladereihenfolge und Server-Konfiguration für messbares Ranking-Wachstum.

Technisches SEO anfragen

Weitere Artikel zu Technisches SEO