Warum ein Bild wichtiger ist als der Rest

Google misst die gefühlte Ladegeschwindigkeit unter anderem am Largest Contentful Paint (LCP): dem Zeitpunkt, zu dem das größte sofort sichtbare Element fertig geladen ist. Auf den meisten Seiten ist das ein Bild — das Hero-Motiv, ein großes Banner, das Produktfoto. Lädt dieses eine Bild schnell, fühlt sich die ganze Seite schnell an. Lädt es spät, hilft alle andere Optimierung wenig. Deshalb lohnt es sich, dieses eine Element gezielt zu beschleunigen.

Schritt 1: das LCP-Element finden

Bevor du optimierst, musst du wissen, welches Bild es ist. Öffne die Seite in den Chrome DevTools → Reiter „Performance" → Aufzeichnung des Seitenaufbaus; der LCP-Marker zeigt dir das Element. Alternativ zeigt der Lighthouse-Bericht unter „Largest Contentful Paint element" direkt an, welches Bild gemeint ist. Meist ist es erwartbar — das große Bild ganz oben.

Schritt 2 (das Wichtigste): NICHT lazy laden

Der häufigste Fehler zuerst: Das LCP-Bild darf niemals loading="lazy" haben. Lazy Loading verzögert bewusst — genau das Falsche für das Bild, das früh da sein soll. Prüfe also erst, ob auf dem LCP-Bild versehentlich ein pauschales Lazy-Attribut sitzt (siehe Lazy Loading für Bilder).

Schritt 3: preloaden

Ein preload-Link im <head> sagt dem Browser: Lade dieses Bild sofort und bevorzugt, ohne zu warten, bis du es beim Rendern entdeckst.

<link rel="preload" as="image" href="hero-1200.jpg">

Bei responsiven Bildern lässt sich der Preload sogar an srcset/sizes koppeln, damit der Browser gleich die richtige Variante vorlädt:

<link rel="preload" as="image"
      href="hero-1200.jpg"
      imagesrcset="hero-800.jpg 800w, hero-1200.jpg 1200w, hero-1600.jpg 1600w"
      imagesizes="100vw">

Schritt 4: fetchpriority setzen

Noch einfacher als ein preload-Link ist bei einem <img>-Element das Attribut fetchpriority="high" — es hebt die Ladepriorität direkt am Bild an:

<img src="hero-1200.jpg" alt="..." width="1200" height="600" fetchpriority="high">

Für die meisten Fälle reicht das schon. Preload-Link und fetchpriority lassen sich kombinieren, sind aber oft einzeln ausreichend.

Die drei Fehler, die den Effekt zunichtemachen

  • Zu viel preloaden. Preload ist für genau ein Element. Mehrere Preloads konkurrieren und bremsen sich gegenseitig aus.
  • Das falsche Element preloaden. Wenn du nicht das echte LCP-Bild beschleunigst, bringt es nichts — erst messen, dann handeln.
  • Ein unoptimiertes Bild preloaden. Ein früh geladenes 4-MB-Bild bleibt langsam. Erst auf sinnvolle Maße bringen (Skalieren) und komprimieren (WebP), dann priorisieren.

Preload und fetchpriority sind der letzte Feinschliff — die Grundlage bleibt ein klein gehaltenes, richtig dimensioniertes Bild. Das Gesamtbild der Core Web Vitals steht im Beitrag Core Web Vitals verbessern.

Häufige Fragen

Was ist das LCP-Element?

Largest Contentful Paint misst, wann das größte sofort sichtbare Element geladen ist — meist ein Hero-Bild, ein großes Banner oder eine prominente Überschrift. Google wertet die LCP-Zeit als zentralen Core-Web-Vitals-Wert; ein schnelles LCP fühlt sich für Nutzer wie eine schnelle Seite an.

Was bewirkt das Preloaden eines Bildes?

Ein preload-Link im head weist den Browser an, dieses Bild früh und mit hoher Priorität zu laden, statt es erst beim Rendern zu entdecken. Für das LCP-Bild kann das die gemessene Ladezeit spürbar verkürzen — es erscheint sichtbar früher.

Soll ich alle Bilder preloaden?

Auf keinen Fall. Preload zieht Bandbreite auf ein einzelnes Element vor. Preloadet man zu viele, konkurrieren sie und alles wird langsamer. Preload ist ein Skalpell für genau ein Element: das LCP-Bild.

Was macht fetchpriority="high"?

Es signalisiert dem Browser, ein Bild bevorzugt zu laden, ohne einen separaten preload-Link. Für ein img-LCP-Element ist fetchpriority="high" oft der einfachste Weg, es zu priorisieren — und lazy loading gehört bei diesem Bild explizit entfernt.

Quellen

web.dev — Largest Contentful Paint · MDN — rel=preload · web.dev — fetchpriority.