Zurück zum Blog
Technologie

Bilder-Optimierung fürs Web 2026: 8 Strategien für bessere Core Web Vitals

Veröffentlicht am8 min read
Teilen

Bilder sind der Performance-Flaschenhals Nummer eins

HTTP Archive, Dezember 2025: Die durchschnittliche Desktop-Webseite hat etwa 2 312 KB Gesamtgröße, davon etwa 1 026 KB Bilder — knapp 44,4 %. Mobile Seiten liegen bei 47 %.

Bedeutet: Wenn Sie nur eine Sache optimieren können, nehmen Sie Bilder.

Besonders relevant: Bilder beeinflussen Google Core Web Vitals, insbesondere LCP (Largest Contentful Paint). Laut Googles CrUX-Report sind über 70 % der LCP-Elemente entweder Bilder oder Elemente mit Background-Image. Über 2,5 Sekunden LCP bedeutet "verbesserungswürdig", über 4 Sekunden "schlecht" — mit direktem Ranking-Effekt.

Wir gehen jede Optimierungsschicht strukturiert durch.

Ein echter Fall aus der Praxis: LCP von 1,8 s auf 6,2 s explodiert

Fazit zuerst: Letztes Jahr hatte ich einen Kundenfall, bei dem der LCP vom grünen Bereich (1,8 s) in den roten (6,2 s) geschossen ist — nur weil eine einzige Hero-Grafik auf der Startseite ausgetauscht wurde. Ehrlich gesagt dachte ich zuerst, das JS-Bundle sei explodiert, und habe drei Tage debuggt, bis ich es gefunden habe: Der neue Designer hatte ein 4,5 MB großes 1920×1080 PNG direkt auf die Startseite geworfen — unkomprimiert, ohne loading-Attribut, ohne fetchpriority, und auch nicht über ein CDN ausgeliefert. Diese eine Grafik hat den LCP im Alleingang zerlegt.

Nach drei Maßnahmen war der LCP wieder bei 1,9 s:

  1. PNG in WebP umgewandelt, auf 180 KB heruntergedrückt (96 % kleiner)
  2. fetchpriority="high" plus <link rel="preload"> gesetzt
  3. Die Grafik auf Cloudflare R2 + Transform Rules mit automatischem AVIF-Fallback umgezogen

Mal ehrlich, diese Falle ist furchtbar häufig. Die Hero-Grafik auf der Startseite ist praktisch immer der LCP-Engpass — sobald ein Glied der Kette schlampig ist, reißt es den kompletten Core-Web-Vitals-Report ins Rote. Jedes Kapitel hier unten stammt aus solchen realen Fällen, nicht aus der Dokumentation.

Lazy Loading: Off-Screen-Bilder verzögert laden

Native HTML-Variante

Einfachster Weg: loading="lazy":

<img src="foto.webp" loading="lazy" alt="Beispielbild" width="800" height="600">

Der Browser sendet den HTTP-Request erst, wenn das Bild sich dem Viewport nähert. Chromes Implementierung startet bei etwa 1 250 px (Desktop) oder 2 500 px (langsames Netz) Abstand zum Viewport.

Wichtig: First-fold-Bilder (Above the Fold) dürfen nicht mit loading="lazy" versehen werden — das verzögert LCP. Für erste sichtbare Bilder: loading="eager" (Standard) plus fetchpriority="high".

Intersection Observer für Feinsteuerung

const observer = new IntersectionObserver((entries) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      const img = entry.target;
      img.src = img.dataset.src;
      observer.unobserve(img);
    }
  });
}, { rootMargin: '200px' });

document.querySelectorAll('img[data-src]').forEach(img => observer.observe(img));

Erlaubt Custom-Trigger-Distanz, Fade-in-Effekte und LQIP (Low-Quality Image Placeholder) vor dem eigentlichen Bildladen.

Vergleich der beiden Ansätze

Kriterium Natives loading="lazy" Intersection Observer
Implementierungsaufwand Sehr niedrig (ein Attribut) Mittel (JS nötig)
Browser-Support 95 %+ (2026) 97 %+
Trigger-Distanz konfigurierbar Nein (Browser entscheidet) Ja (rootMargin)
LQIP-Support Nein Ja
SEO-freundlich Ja (native Browser-Implementation) Braucht noscript-Fallback
Fehlerpotenzial First-Fold Muss manuell ausgeschlossen werden Programmatisch ausschließbar

Empfehlung: In den meisten Fällen native Variante. Intersection Observer nur bei LQIP oder Feinsteuerung.

Responsive Images: Nur passende Größe herunterladen

Ein 3000 px breites Hero-Image auf einem Smartphone mit 750 px? Unnötig. Ohne Responsive Images laden Mobilnutzer die vierfache Dateigröße.

srcset + sizes

<img
  srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1200.webp 1200w, hero-1600.webp 1600w"
  sizes="(max-width: 600px) 100vw, (max-width: 1200px) 50vw, 800px"
  src="hero-800.webp"
  alt="Hauptbild Startseite"
>

Der Browser wählt anhand Viewport und Pixeldichte das passende Bild. sizes kommuniziert die gerenderte Breite pro Breakpoint für präzisere Auswahl.

Das <picture>-Element

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Hauptbild Startseite">
</picture>

Verschiedene Formate pro Browser-Fähigkeit, Fallback-Kette vom effizientesten zum kompatibelsten Format.

Formatwahl als Performance-Hebel

Format-Entscheidung wirkt direkt auf Datei- und Ladezeit. Vergleichsdaten bei identischer visueller Qualität (1920 × 1080):

Format Relativ zu JPEG Browser-Support Alpha Animation Einsatz
JPEG Basis 100 % 100 % Nein Nein Fotos (maximale Kompatibilität)
WebP ~70 % 97 %+ Ja Ja Fotos und Grafiken (empfohlener Standard)
AVIF ~50 % 92 %+ Ja Ja Fotos (beste Kompression)
PNG 300–500 % von JPEG 100 % Ja Nein Grafiken mit Transparenz
SVG Sehr klein (Vektor) 100 % Ja Ja Icons, Logos, Diagramme

Empfehlung: AVIF → WebP → JPEG als progressive Fallback-Kette. <picture> macht die Browser-Auswahl automatisch.

CDN und Caching

Warum ein CDN?

Server in Frankfurt → US-Besucher etwa 12 000 km Distanz → ≈ 40 ms Signallaufzeit einfach, plus TCP, TLS, HTTP-Round-Trip. TTFB kann 200 ms überschreiten.

Ein CDN verteilt Inhalte auf globale Edge-Nodes. Besucher erhält Antwort vom nächsten Node. Gutes CDN senkt TTFB von 200+ ms auf 20–50 ms.

Für DACH-Websites mit deutschsprachigem Publikum: Cloudflare, Fastly und BunnyCDN betreiben Edge-Nodes in Frankfurt, Amsterdam und Zürich. Bunny hat aus Slowenien stammend starke EU-Präsenz und transparentes Preismodell — in der deutschen Dev-Community zunehmend beliebt.

Cache-Header

Cache-Control: public, max-age=31536000, immutable

Bilder ändern sich typischerweise nicht — ein Jahr Cache plus immutable sagt dem Browser: Keine Revalidation nötig. Für Updates: neuen Dateinamen (mit Hash) verwenden, damit Cache bricht.

Image-CDN-Services

Cloudflare Images, Imgix, Cloudinary bieten zusätzlich zur CDN-Auslieferung:

  • On-the-fly Format-Konvertierung (via Accept-Header automatisch AVIF/WebP/JPEG)
  • On-the-fly Größenanpassung (URL-Parameter für Breite/Höhe)
  • Automatische Qualitätsoptimierung (je nach Bandbreite des Clients)

Die vollständige Bildpipeline

Professionelles Setup:

  1. Upload-Kompression: Sharp (Node.js) oder Pillow (Python) serverseitig
  2. Multi-Size-Generation: Pro Bild 3–5 Größen (400w, 800w, 1200w, 1600w, Original)
  3. Multi-Format-Konvertierung: AVIF, WebP, JPEG pro Größe
  4. Qualitäts-Tuning: JPEG Q 75–85, WebP Q 75–80, AVIF Q 60–70
  5. EXIF-Cleaning: Reduziert Dateigröße und schützt Privatsphäre

Beispiel: Ein 1920 × 1080 Foto. Nach voller Pipeline lädt ein Smartphone-Nutzer eventuell nur 400w-AVIF — 30 KB statt 2 MB Original. 98,5 % weniger Traffic.

Core Web Vitals und Zielwerte

LCP (Largest Contentful Paint)

LCP misst die Zeit bis zum größten sichtbaren Element. Für Bild-LCP-Seiten:

  • Gut: ≤ 2,5 Sekunden
  • Verbesserungswürdig: 2,5–4 Sekunden
  • Schlecht: > 4 Sekunden

Hero-Image-Optimierung konkret:

  1. fetchpriority="high" für First-Fold-Bild
  2. <link rel="preload"> für LCP-Bild im Head
  3. Kein Lazy Loading für First-Fold
  4. CDN-Cache-Hit-Rate hoch halten

CLS (Cumulative Layout Shift)

Bilder, die ohne reservierten Platz geladen werden, verursachen Layout-Springen. Lösung: Immer width und height im <img> angeben.

<img src="foto.webp" width="800" height="600" alt="Beispiel">

Damit berechnet der Browser das Aspect Ratio, bevor das Bild geladen ist.

Pre-Launch-Checkliste

Vor dem Live-Gang:

  • First-Fold-Bilder mit fetchpriority="high", sonst loading="lazy"
  • Alle <img> haben width und height
  • <picture> mit AVIF/WebP/JPEG-Progressive-Fallback
  • srcset plus sizes mit Multi-Size-Varianten
  • Kompression: JPEG Q 75–85, WebP Q 75–80
  • CDN aktiv, Cache-Control: max-age=31536000, immutable
  • EXIF entfernt
  • LCP-Bild preloaded
  • PageSpeed Insights: LCP ≤ 2,5 Sekunden

DACH-spezifische Performance-Überlegungen

Für deutschsprachige Websites:

  • Google Sucht-Ranking: Core Web Vitals ist inzwischen Ranking-Faktor. Unterschiede von 20–30 % bei LCP wirken messbar auf Position für deutsche Suchanfragen
  • DSGVO und CDN: Cloudflare und Amazon bieten EU-Data-Boundaries. Für Seiten mit Nutzer-Tracking ist die Datenschutzerklärung anzupassen
  • Mittelstands-Hosting: Deutsche Hoster (Hetzner, netcup, IONOS) bieten zunehmend CDN-Optionen — für Unternehmen, die Hosting in DE bevorzugen, ist das relevant
  • Barrierefreiheit (BITV 2.0, EU Accessibility Act 2025): alt-Attribute sind rechtlich verpflichtend für viele Websites. Gleichzeitig ein SEO-Signal

Image-Hosts als Shortcut

Wer die volle Pipeline nicht selbst bauen will: Professionelle Image-Hosts sind ein pragmatischer Weg.

Am Beispiel lpic.cc: Upload ohne Registrierung, CDN-Auslieferung global, Passwortschutz als Zusatz. Für Blogs und kleinere Websites spart das den Aufwand für eigene Infrastruktur. Ehrlich gesagt: lpic.cc bietet keine API-Integration und keine On-the-fly-Größentransformation. Wer programmatische Batch-Uploads oder dynamische Transformationen braucht, greift zu Cloudinary, Imgix oder Cloudflare Images.

FAQ

Beeinflusst Lazy Loading SEO?

Nein. Googlebot führt JavaScript aus und simuliert Scrolling — loading="lazy"-Bilder werden korrekt indexiert. Bei Custom-JS-Lazy-Loading sollten Sie <noscript>-Fallbacks einbauen, damit Suchmaschinen die Bild-URLs sehen.

WebP oder AVIF — was zuerst?

Kompressionsseitig gewinnt AVIF (50 % kleiner als JPEG). Aber AVIF-Encoding ist langsam, ungeeignet für Realtime. Empfehlung: <picture> beides anbieten, Browser wählt. Wenn nur eins: WebP (97 % Support vs. AVIFs 92 %).

Lohnt ein Image-CDN finanziell?

Hängt am Traffic. Unter 100 000 PV/Monat reicht Cloudflare Free. Darüber rechnen sich Imgix oder Cloudinary — automatische Optimierung spart so viel Bandbreite, dass sich die Kosten trotz Abo amortisieren. Für DACH-Mittelstand: BunnyCDN mit Image-Optimization-Add-on ist günstiger als Cloudinary und bietet EU-Hosting.

Beeinträchtigt Kompression Qualität?

Verlustbehaftete Kompression ja, aber in vernünftigen Qualitätsparametern (JPEG 75–85, WebP 75–80) kaum wahrnehmbar. Mit SSIM quantifizieren: > 0,95 ist für die meisten Nutzer nicht unterscheidbar vom Original.

Meine Seite nutzt schon CDN — reicht das?

Nein. CDN löst "Übertragungsdistanz", nicht "Übertragungsvolumen". Ein unkomprimiertes 5-MB-Bild bleibt 5 MB Traffic, auch via nächstgelegenem Node. Format-Konvertierung, Größen-Adaption und Kompression reduzieren Volumen um 80–95 %. Effektwirkung überschreitet CDN allein bei weitem.

Gibt es deutsche Alternativen zu Cloudinary?

Teilweise. imgproxy (Open Source, in der Berlin-Tech-Szene entwickelt) ist ein selbsthostbarer Image-Transformation-Server. Auf Hetzner installiert kostet er wenige Euro im Monat und macht das, was Cloudinary für viel Geld tut. Für Unternehmen, die eigene Infrastruktur pflegen wollen, eine überlegenswerte Option.

Quellen

#Web Performance#Bildoptimierung#Lazy Loading#Responsive Images#CDN#Core Web Vitals
H

Verfasst von

Harvey Zhang

Mitgründer & CTO

Backend-Ingenieur und Systemarchitekt mit fundierter technischer Analyse von Bildhosting-Infrastrukturen.