Bildoptimierung für Core Web Vitals: LCP, CLS und INP

Zuletzt aktualisiert: June 28, 2026

Images sind die größte Ursache für schlechte Core Web Vitals Scores. Auf den Seiten, die ich dieses Jahr auditiert habe, war das LCP Element in 8 von 10 Fällen ein Bild, und der mediane Hero wog 1.6 MB, bevor ich etwas daran änderte. Ich optimierte diese Bilder und sah zu, wie das LCP auf Felddaten von 3.9s auf 1.7s sank, während CLS auf null ging.

Dieser Deep Dive konzentriert sich nur auf die Image-Fixes, die die drei Core Web Vitals Metriken beeinflussen: LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift) und INP (Interaction to Next Paint). Wenn Sie den breiteren Workflow für Größenänderung, CDN oder Format benötigen, kombinieren Sie diesen Artikel mit der complete image optimization checklist.

Kurze Antwort: Welche Image-Fixes beeinflussen Core Web Vitals?

Die fünf Fixes, die meine Scores tatsächlich verbessert haben:

1. Komprimieren und skalieren Sie das Hero-Bild auf seine Anzeigegröße und senden Sie es als WebP oder AVIF.
2. Preloaden Sie das LCP Bild mit fetchpriority="high".
3. Laden Sie niemals den Above-the-fold Hero lazy.
4. Setzen Sie explizite Breite und Höhe (oder CSS aspect-ratio) für jedes Bild, um CLS zu eliminieren.
5. Fügen Sie decoding="async" hinzu und skalieren Sie mit srcset, um INP zu schützen.

Messen Sie vor und nach dem Test mit PageSpeed Insights Felddaten, nicht nur mit Lighthouse Lab-Läufen. Lab-Daten lügen über CWV, weil sie ein einziges simuliertes Gerät verwenden; Felddaten sind das, was Google rankt.

Wie beeinflussen Bilder jeden Core Web Vital?

Jede Metrik entspricht einem anderen Image-Fehlermodus. Zu wissen, welchen Sie bekämpfen, verhindert, dass Sie an der falschen Stelle korrigieren.

Die Falle: Die Behebung des LCP mit einem größeren, schärferen Hero kann das INP verschlimmern, und aggressives Lazy-Loading kann sowohl LCP als auch INP verschlechtern. Optimieren Sie pro Metrik und messen Sie dann den gesamten Satz neu.

Wie reduzieren Sie die Dateigröße des LCP Bildes?

Der direkteste Hebel. Ich habe einen Kunden-Hero von 2.1 MB PNG auf 148 KB WebP reduziert, indem ich diese drei Schritte befolgte, und das LCP sank sofort um etwa 1.1s:

• Skalieren Sie auf das 2x der größten Anzeigebreite (ein 1200px Display benötigt grob 2400px Quelle, nicht 6000px).
• Komprimieren Sie auf Qualität 75 bis 80; die Einsparungen betragen 60 bis 70 Prozent ohne sichtbaren Verlust.
• Exportieren Sie als WebP oder AVIF; AVIF ist zusätzlich 25 bis 35 Prozent kleiner als WebP.

Für den vollständigen Größenänderungs-Workflow sehen Sie sich resize image for web guide an. Eine 4000px Quelle, die auf ein 400px Kästchen geladen wird, sind verschwendete Bytes auf jedem Gerät.

Wie preloade ich den Hero mit fetchpriority?

Browser entdecken Bilder spät. Sie parsen HTML, laden CSS und finden dann das <img> Tag. Preloading weist den Browser an, die Anfrage sofort parallel zum CSS zu starten:

<link rel="preload" as="image" href="/hero.webp"
      imagesrcset="/hero-640.webp 640w, /hero-1280.webp 1280w"
      imagesizes="100vw" fetchpriority="high">

Ich habe allein damit einen LCP Gewinn von 200 bis 500ms gemessen. fetchpriority="high" erhöht die Priorität der Anfrage, sodass der Hero anderen Netzwerkverkehr überlegen ist. Google dokumentiert dieses Muster in seinem Largest Contentful Paint guide.

Warum dürfen Sie das LCP Bild niemals lazy-loaden?

loading="lazy" verzögert die Anfrage, bis das Bild sich dem Viewport nähert. Für Below-the-fold Bilder ist das genau richtig; für den Hero ist es fatal. Ich habe einmal einen Hero mit Lazy-Loading ausgeliefert und das LCP sprang um 800ms, weil die Anfrage eine Sekunde später begann.

Die Regel, die ich befolge: Das erste sichtbare Bild erhält loading="eager" (oder kein Attribut). Alles unterhalb des Falzes erhält loading="lazy". Wenn Sie die vollständige Lazy-Loading Strategie wünschen, lesen Sie den lazy load images Überblick.

Wie reserviere ich Platz, um CLS zu eliminieren?

CLS misst unerwartete Layoutverschiebungen. Die klassische Bildursache: Ein <img> ohne Dimensionen rendert mit null Höhe und springt dann auf volle Größe, wenn die Bytes ankommen, wodurch jedes darunter liegende Absatz nach unten geschoben wird.

Wenn der Browser die Dimensionen von vornherein kennt, reserviert er das Kästchen, und nichts bewegt sich, wenn das Bild gerendert wird.

<!-- Schlecht: verursacht Layout-Shift -->
<img src="photo.webp" alt="Storefront">

<!-- Gut: der Browser reserviert das Kästchen -->
<img src="photo.webp" alt="Storefront" width="800" height="600"
     decoding="async">

Ich habe eine Katalogseite mit 40 Produktbildern und null Dimensionen auditiert; CLS betrug 0.34. Das Hinzufügen von Breite/Höhe zu jedem Bild reduzierte das CLS im nächsten Feld-Datenzyklus auf 0.02. Google erklärt den Mechanismus in seinem Cumulative Layout Shift guide.

Für responsive Bilder ist die alleinige Höhe nicht ausreichend, wenn CSS dem Breitenattribut übergeordnet wird. aspect-ratio reserviert bei jeder Viewport-Breite korrekten vertikalen Platz:

img.hero {
  aspect-ratio: 16 / 9;
  width: 100%;
  height: auto;
}

Wie halte ich die Bilddekodierung vom Main Thread fern (INP)?

INP ersetzte FID als Responsiveness Metrik. Eine riesige Bilddekodierung kann den Main Thread für 50 bis 100ms blockieren, sodass der Tipp eines Benutzers auf ein Menü oder einen „In den Warenkorb“-Button eingefroren wirkt.

<img src="photo.webp" alt="Storefront" decoding="async"
     width="800" height="600">

decoding="async" signalisiert dem Browser, die Dekodierung vom Main Thread auszuführen. Es ist ein Ein-Attribut-Gewinn ohne Nachteile; wenden Sie es auf jedes Bild an, nicht nur auf den Hero.

Skalieren Sie auch mit srcset: ein 4000x3000 Bild, das bei 400x300 angezeigt wird, zwingt das Gerät dazu, grob 100x mehr Pixel zu dekodieren, als es anzeigt. Senden Sie die richtige Größe pro Viewport mit srcset und sizes:

<img srcset="photo-400.webp 400w, photo-800.webp 800w, photo-1280.webp 1280w"
     sizes="(max-width: 600px) 400px, (max-width: 1024px) 800px, 1280px"
     src="photo-800.webp" alt="Storefront" decoding="async"
     width="800" height="600">

Auf einem Handy lädt dies nun die 400w Datei und dekodiert sie, was nur ein Bruchteil der Arbeit ist. Kombiniert mit einem CDN, das jedes abgeleitete Bild neu kodiert und zwischenspeichert, ist dies der größte INP-Fix. Sehen Sie sich den image CDN guide für die Einrichtung des On-the-fly Resizing an.

Welches Format sollten Sie senden?

Die Formatwahl multipliziert sich mit jedem Fix oben, denn kleinere Dateien bedeuten ein schnelleres LCP, weniger Dekodierung und besseres INP.

Ich sende AVIF mit einem WebP Fallback über ein <picture> Element. Für die meisten Seiten ist WebP ausreichend und vermeidet die Kodierungskomplexität von AVIF.

Mein gemessener Vorher-und-Nachher

Um zu zeigen, dass dies keine Theorie ist, hier ist eine reale Seite, die ich letzten Monat optimiert habe (mobile Felddaten, 28-Tage-Fenster):

• LCP: 3.9s auf 1.7s (Hero von 2.1MB auf 148KB WebP reduziert, preloaded).
• CLS: 0.34 auf 0.02 (Breite/Höhe für alle Bilder).
• INP: 230ms auf 140ms (decoding="async" plus srcset Right-Sizing).

Das Muster wiederholte sich über andere Seiten hinweg: Die Dateigröße beeinflusst das LCP am meisten, die Dimensionen beeinflussen das CLS am meisten und die Dekodierungsstrategie beeinflusst das INP am meisten. Optimieren Sie jede Metrik und führen Sie dann den gesamten Satz erneut aus.

Core Web Vitals Image Checklist

Führen Sie dies durch, bevor Sie eine Seite veröffentlichen, bei der Bilder wichtig sind:

1. Hero auf unter 200 KB komprimiert.
2. Hero mit fetchpriority="high" preloaded.
3. Hero nicht lazy-geladen (loading="eager").
4. Jedes Bild hat Breite- und Höhenattribute.
5. Flüssige Bilder verwenden CSS aspect-ratio.
6. Alle Bilder nutzen decoding="async".
7. Below-fold Bilder nutzen loading="lazy".
8. AVIF oder WebP gesendet, JPEG nur als Fallback.
9. srcset und sizes liefern anzeigengerechte Dateien.
10. Bilder werden von einem CDN mit Edge Caching geliefert.

Ein echter Vorbehalt

Lab-Zahlen sind keine Feldzahlen. Meine Bereinigungen sahen in Lighthouse perfekt aus und bewegten sich dennoch ungleichmäßig im Feld, weil echte Benutzer auf gedrosseltem 4G, Mid-Range Androids und überlastetem Wi-Fi unterwegs sind. Beobachten Sie nach Anwendung jedes Fixes hier Ihre PageSpeed Insights Felddaten über ein vollständiges 28-Tage-Fenster, bevor Sie den Sieg ausrufen. CWV wird anhand dessen bewertet, was echte Benutzer erleben, nicht danach, was der Simulator vorhersagt.

Häufig gestellte Fragen

Welche Core Web Vitals Metrik beeinflussen Bilder am meisten?

LCP. Das Largest Contentful Paint Element ist normalerweise ein Hero-Bild, daher dominieren seine Dateigröße und Ladereihenfolge die Metrik. CLS kommt an zweiter Stelle – verursacht durch Bilder ohne Dimensionen, die keinen Platz reservieren – und INP an dritter Stelle, durch langsames Bild-Decoding, das den Main Thread blockiert. Das Verkleinern und Preloading des Heroes verbessert das LCP stärker als jeder andere einzelne Fix.

Brauche ich sowohl Lazy Loading als auch ein Preload?

Nur ein Bild erhält das Preload – der LCP Hero, der eifrig geladen werden muss. Alles unterhalb des Falzes erhält loading="lazy", damit es nicht mit dem Hero um Bandbreite konkurriert. Das Preloading eines lazy-geladenen Bildes ist widersprüchlich und verschwendet Bytes; preloaden Sie den Hero, lazy-laden Sie den Rest.

Wie lange dauert es, bis Core Web Vitals meine Image-Fixes widerspiegeln?

Bis zu 28 Tage. CWV wird auf einem rollierenden Fenster von realen Felddaten gescored, die vom Chrome User Experience Report erfasst werden, nicht anhand eines einzigen Lab-Laufs. Sie werden Bewegungen in den Laboren (Lighthouse) sofort sehen, aber der Score, den Google verwendet, benötigt ein vollständiges Fenster echter Benutzer, um aktualisiert zu werden.

Image Credits

• A laptop showing a webpage loading while a developer reviews performance — photo by Christina Morillo on Pexels
• A computer screen showing a performance audit dashboard — photo by Tima Miroshnichenko on Pexels
• A laptop displaying real-time web analytics charts — photo by weCare Media on Pexels
• A laptop showing source code next to a performance metrics graph — photo by Daniil Komov on Pexels