Warum dieser Beitrag jetzt?

Die Core Web Vitals sind seit Mai 2021 ein offizielles Google-Ranking- Signal. Seither hat sich die Metriken-Familie zweimal substanziell verändert: 2022 wurde FID (First Input Delay) durch INP ersetzt, 2023 wurden die Schwellenwerte verschärft. 2026 sieht das Bild so aus: LCP unter 2,5 s, CLS unter 0,1, INP unter 200 ms. Was viele Web-Performance-Beiträge übersehen: Bilder sind in fast allen drei Metriken mitschuldig, wenn sie unsachgemäß ausgeliefert werden. Eine grundsätzliche Einordnung findet sich in unserem Core-Web-Vitals- Beitrag; hier geht es um die konkreten Bild-Pitfalls 2026.

LCP: Largest Contentful Paint

In etwa 70–80 % aller modernen Websites ist das LCP-Element ein Bild — das Hero-Bild oder ein dominantes Above-the-Fold-Asset. Das macht Bilder zum wichtigsten LCP-Hebel.

Vier kritische Bild-LCP-Hebel. Erstens: fetchpriority="high" auf dem Hero-Bild. Seit 2023 in Chrome, Firefox, Edge. Schiebt das Bild in der Browser-Prioritäts-Warteschlange nach oben. Messbare LCP-Einsparung typisch 200–500 ms auf mobilen Verbindungen.

Zweitens: Preload für CSS-Background-Bilder. Wenn dein LCP-Element ein CSS-Background ist (verbreitete Praxis bei Hero-Sections), entdeckt der Browser das Bild erst beim CSS-Parsing — also spät. Mit <link rel="preload" as="image" href="hero.webp" fetchpriority="high">startet der Download vor dem CSS-Parse.

Drittens: moderne Formate ausliefern. AVIF ist bei gleicher Qualität 25–35 % kleiner als WebP, WebP 25–35 % kleiner als JPG. Bei einem 800 KB-Hero kann das den Unterschied zwischen 2,1 s und 1,4 s LCP machen. Format-Auslieferung über<picture> mit AVIF → WebP → JPG-Fallback. Hintergrund zur Wahl in unserem Formate-Vergleich.

Viertens: nicht zu früh lazy-loaden. loading="lazy"auf dem LCP-Bild ist ein klassischer Anti-Pattern. Browser-Heuristik 2024+ verzögert lazy-Bilder bewusst, um Below-the-Fold-Inhalte zu priorisieren. Wenn dein LCP lazy ist, rutscht es in die zweite Welle.

CLS: Cumulative Layout Shift

CLS misst sichtbare Sprünge des Layouts während des Ladens. Bilder ohne reservierte Höhe sind die häufigste Ursache: das HTML rendert, der Text wird gesetzt, dann erscheint das Bild — und drückt den Text nach unten.

Die richtige Lösung ist Aspect-Ratio-Boxing. Das HTML-img- Element bekommt width und height als Attribute (nicht CSS!). Der Browser berechnet daraus selbständig die Aspect-Ratio und reserviert vor dem Bild-Download den korrekten Platz. Alternativ in CSS:aspect-ratio: 16 / 9.

<!-- Gut: explizite width/height -->
<img src="hero.webp" width="1600" height="900" alt="…">

<!-- Auch gut: CSS aspect-ratio -->
<img src="hero.webp" alt="…" style="width: 100%; aspect-ratio: 16 / 9">

Verbreiteter Fehler: Bilder in unbekannter Größe per JavaScript einfügen(z.B. nach Daten-Fetches). Dann gibt es keinen reservierten Platz, und der Layout-Shift ist unvermeidbar. Lösung: Platzhalter mit fester Höhe (LQIP, Skelett) bis das Bild fertig geladen ist.

INP: Interaction to Next Paint

INP ist die neueste Core-Web-Vitals-Metrik, seit März 2024 offiziell ranking-relevant. Sie misst die längste Verzögerung zwischen Nutzer-Interaktion (Klick, Tippen, Tastendruck) und der nächsten Bildschirm-Reaktion. Bilder beeinflussen INP weniger direkt als LCP — aber falsche Praktiken können INP massiv verschlechtern.

Klassische INP-Pitfalls bei Bildern. Erstens: synchrones Decoding großer Bilder beim Carousel-Wechsel. Wenn ein Klick auf den „Nächstes Bild"-Pfeil ein 3-MP-WebP synchron dekodiert, kann der Hauptthread 200– 500 ms blockieren. Lösung: decoding="async" auf allen Carousel-Bildern + createImageBitmap() für vorab-warming, wenn das nächste Bild absehbar ist.

Zweitens: onClick-Handler, die parallel Bilder lazy-laden. Ein „Mehr laden"-Button, der gleichzeitig 20 neue <img>-Elemente in den DOM einfügt, triggert Style-Recalc, Layout und Paint zur selben Zeit. Klassische INP-Verschlechterung. Lösung: Bilder in Chunks von 4–6 einfügen mitrequestIdleCallback oder requestAnimationFrame-Throttling.

Drittens: Click-Handler, die Foto-Filter zur Laufzeit auf Canvas anwenden. Wer Helligkeit/Kontrast-Slider im Browser ohne Web Worker betreibt, blockiert den Hauptthread mit jeder Pixel-Iteration. OffscreenCanvas in einem Web Worker ist die richtige Antwort.

Konkreter 10-Minuten-Optimierungs-Plan

  1. LCP-Element identifizieren via Chrome DevTools → Performance → LCP. Meist ein Bild oder Heading-Background.
  2. fetchpriority="high" + preload auf das LCP-Bild setzen.
  3. AVIF/WebP-Variante über <picture> ausliefern. Wer lokal komprimieren will, nutzt unseren JPG-zu-WebP-Konverter.
  4. Alle img-Tags auf width/height prüfen. Pflicht für CLS.
  5. loading="lazy" auf Below-the-Fold-Bilder, niemals auf LCP.
  6. decoding="async" universell setzen.
  7. Carousel/Slider-Interaktionen messenmit Chrome DevTools → INP Marker. Bei > 200 ms: Chunking oder Worker.
  8. Image-CDN nutzen, wenn dein Stack das hergibt. Vercel/Next.js macht es automatisch. Mehr dazu in unserem Ladezeit-Beitrag.

Messen, nicht raten

Field-Daten (echte Nutzer) und Lab-Daten (DevTools) zeigen oft Unterschiede. Field- Werte sind, was Google rankt. Daten-Quellen: Chrome User Experience Report (CrUX), PageSpeed Insights, web-vitals.js(eigene Telemetrie). Optimierungen sollten an realen Werten gemessen werden, nicht an synthetischen Lighthouse-Scores allein.

Was 2026 neu ist

Drei Entwicklungen prägen die Bild-Performance 2026: erstens Speculation Rules API (Chrome 122+) erlaubt Prerendering ganzer Seiten — Bilder werden mit-precachable. Zweitens fetchpriority auch für SSR-Streaming in Next.js 16, das Hydrations-Pfade weniger blocking macht. Drittens moderne Sandboxed Bild-Decoder (besonders nach dem libwebp-CVE 2023): Browser laden Bild-Decoder in eigene Prozesse, was die INP-Beobachtungen leicht verändert.

Quellen

web.dev — Core Web Vitals · web.dev — LCP · web.dev — CLS · web.dev — INP · web.dev — Fetch Priority · web.dev — Preload responsive images · Chrome User Experience Report · web-vitals.js · Chrome — Speculation Rules / Prerender.