Responsive Images: Immer die perfekte Pixel-Größe servieren

Ein Bild sagt mehr als tausend Worte. Aber im Web sagt ein Bild oft auch: "Ich bin 4 MB groß und verbrauche dein gesamtes monatliches Datenvolumen."

Das Problem: Geräte sind extrem divers. Der iPhone-Nutzer hat ein "Retina"-Display mit 3-facher Pixeldichte. Er braucht knackscharfe Bilder. Der Nutzer mit dem alten Android im 3G-Netz braucht ein kleines, stark komprimiertes Bild, das schnell lädt. Wenn Sie beiden dasselbe Bild ("Desktop-Größe") servieren, machen Sie einen von beiden unglücklich.

Die Lösung heißt Responsive Images. Es ist eines der mächtigsten, aber am häufigsten missverstandenen Features in HTML.

Featured Snippet: Responsive Images ermöglichen dem Browser, je nach Bildschirmgröße und Pixeldichte (DPI) automatisch die passende Bilddatei auszuwählen. Mit den Attributen srcSet (Liste verfügbarer Auflösungen) und sizes (Anzeigebreite) lädt das Gerät nur die Pixel, die es wirklich braucht. Das spart Bandbreite und beschleunigt das Laden massiv.

---

The Cost of Inaction: Pixel-Verschwendung

Wenn Sie ein 1920px breites Bild auf ein Handy laden, das physisch nur 375px breit ist (aber 2x Pixeldichte hat, also 750px braucht):

1. Over-Download: Sie laden 1200 Pixel zu viel Breite. Die Datei ist 4x größer als nötig.
2. CPU-Last: Das Handy muss das riesige Bild im Speicher dekodieren und runterskalieren. Das frisst Akku und macht das Scrollen ruckelig.

Eine Studie von HTTP Archive zeigt: Bilder machen 60% des Web-Traffics aus. Wer hier optimiert, hat den größten Performance-Hebel.

---

Das Werkzeug: Syntax im Detail

Resolution Switching (Dasselbe Bild, verschiedene Größen)

Das Standard-Problem: "Lade klein auf Mobile, groß auf Desktop."

<img src="small.jpg"
     srcset="small.jpg 500w, medium.jpg 1000w, large.jpg 2000w"
     sizes="(max-width: 600px) 100vw, 50vw"
     alt="Ein tolles Bild">

Was passiert hier?

• srcset: Wir sagen dem Browser: "Hier sind 3 Versionen des Bildes (500, 1000, 2000 Pixel breit). Nimm dir, was du brauchst."
• sizes: Wir sagen: "Auf kleinen Screens ist das Bild bildschirmfüllend (100vw), auf großen Screens ist es nur halb so breit (50vw)."
• Resultat: Der Browser rechnet: Screenbreite x Pixeldichte = Benötigte Pixel. Und lädt NUR diese Datei.

Art Direction (Anderer Bildausschnitt)

Das Problem: Ein Querformat-Bild ("Landschaft") sieht auf dem Desktop toll aus. Auf dem Handy ist es so klein, dass man nichts erkennt. Hier wollen wir auf Mobile ein Hochkant-Bild ("Portrait") oder einen Zoom ("Crop") laden.

Dafür nutzen wir das <picture> Element.

<picture>
  <source media="(max-width: 799px)" srcset="portrait-crop.jpg">
  <source media="(min-width: 800px)" srcset="landscape-wide.jpg">
  <img src="landscape-wide.jpg" alt="Landschaft">
</picture>

Hier zwingen wir den Browser, bei kleinen Screens das Portrait-Bild zu nehmen. Das ist ein Design-Tool, kein reines Performance-Tool.

---

Automatisierung: Niemand macht das von Hand

"Muss ich jetzt jedes Bild in 5 Größen speichern?" Gott bewahre, nein. Das erledigt Ihr Build-System oder ein Image CDN.

1. Next.js Image Component: <Image src="/bild.jpg" />. Next.js generiert beim Build automatisch alle Größen und Formate (WebP/AVIF). Sie müssen nichts tun.
2. Cloudinary / Imgix: Sie laden ein Master-Bild hoch. Die URL image.com/my-pic?w=500 generiert die 500px Version in Echtzeit.

Workflow 2026: Entwickler definieren nur die Logik ("Wie breit wird das Bild angezeigt?"), Maschinen generieren die Pixel.

---

Myth-Busting: "Retina braucht doppelte Auflösung"

Designer sagen oft: "Exportier alles in @2x." Das stimmt, aber es ist gefährlich. Wenn Sie alles in @2x ausliefern, leiden Nutzer mit schlechten Bildschirmen (alte Laptops). Responsive Images lösen das elegant: Ein Retina-Screen nimmt sich das 2000w Bild, ein Standard-Screen das 1000w Bild. Niemand bekommt zu viel, niemand zu wenig.

---

Unasked Question: "Was ist mit Lazy Loading?"

Bilder, die "Below the Fold" (also erst nach dem Scrollen sichtbar) liegen, sollten nicht sofort laden. Früher brauchte man JavaScript-Libraries. Heute ist es nativ in HTML: loading="lazy".

<img src="..." loading="lazy">

Der Browser lädt das Bild erst, wenn der Nutzer in die Nähe scrollt. Das spart initial massiv Daten. Achtung: Niemals loading="lazy" auf das Hero-Image (das oberste Bild) packen! Das verzögert den LCP (Largest Contentful Paint) und schadet SEO. Das oberste Bild immer eager laden.

---

FAQ: Image Best Practices