Bildoptimierung für Web bezeichnet den Prozess, Bilddateien in Größe, Format und Ladeweise so anzupassen, dass Websites schnell laden, ohne visuell erkennbare Qualitätsverluste.
Rubrik: Mediendesign & Digitale Medien · Unterrubrik: Web-Grundlagen · Niveau: Einsteiger Synonyme / Auch bekannt als: Image Optimization, Bildkompression, Web-Bilder, Responsive Images
Was ist Bildoptimierung für Web?
Bilder sind verantwortlich für den Großteil des Datentransfers auf typischen Websites. Eine unoptimierte hochauflösende JPG-Datei mit 5 MB kann eine Seite massiv verlangsamen – auch wenn sie auf dem Bildschirm nur einen kleinen Bereich ausfüllt. Das betrifft sowohl die Nutzererfahrung (Ladezeiten) als auch das Suchmaschinen-Ranking: Google bewertet die Ladegeschwindigkeit direkt als Rankingfaktor.
Für Designer ist Bildoptimierung eine gemeinsame Verantwortung: Die Wahl der richtigen Formate, vernünftige Exporteinstellungen und das Bewusstsein für Dateigröße sollten bereits in der Designphase verankert sein, nicht erst in der Entwicklung.
Erklärung
Bildformate im Überblick
JPEG (JPG) Das klassische Format für Fotos. Verlustbehaftet komprimiert, gute Qualität bei kleinen Dateigrößen. Standard seit Jahrzehnten, aber nicht mehr state of the art.
PNG Verlustfrei, unterstützt Transparenz (Alpha-Kanal). Ideal für Logos, Screenshots, Grafiken mit Text. Für Fotos zu groß.
GIF 256 Farben, unterstützt kurze Animationen. Heute von anderen Formaten weitgehend abgelöst.
SVG Vektorgrafik als XML, unbegrenzt skalierbar. Ideal für Logos, Icons, einfache Illustrationen. SVG für Designer: Skalierbare Vektorgrafiken im Web erklärt SVG ausführlich.
WebP Entwickelt von Google. Verlustbehaftet und verlustfrei, unterstützt Transparenz und Animationen. 25–35 % kleiner als vergleichbares JPEG oder PNG bei gleicher Qualität. Browserunterstützung: alle modernen Browser seit 2020.
AVIF Neueres Format basierend auf dem AV1-Videocodec. Noch bessere Kompression als WebP (oft 50 % kleiner als JPEG), aber höherer Encoding-Aufwand. Browserunterstützung ist gut, aber nicht universell.
| Format | Kompression | Transparenz | Animation | Empfehlung |
|---|---|---|---|---|
| JPEG | Gut | Nein | Nein | Legacy, für ältere Projekte |
| PNG | Gering | Ja | Nein | Logos, Screenshots |
| GIF | Gering | Teilweise | Ja | Kaum noch empfohlen |
| WebP | Sehr gut | Ja | Ja | Standard-Empfehlung heute |
| AVIF | Exzellent | Ja | Nein | Modern, progressive enhancement |
| SVG | Vektorgrafik | Ja | Ja | Logos, Icons, Illustrationen |
Kompression und Qualitätsstufen
Bilder müssen nicht in maximaler Qualität ausgeliefert werden. Für Fotos ist eine Qualitätsstufe von 75–85 % (JPEG-Skala) auf den meisten Bildschirmen nicht von 100 % zu unterscheiden. WebP bei 80 % Qualität liefert bei deutlich kleinerer Dateigröße visuell gleichwertige Ergebnisse.
Tools für die Kompression:
- Squoosh (squoosh.app): Browser-basiertes Tool von Google, visuelle Qualitätsvorschau
- ImageOptim (Mac): Batch-Kompression ohne sichtbaren Qualitätsverlust
- Sharp (Node.js): Serverseitige Bildoptimierung in Workflows
Responsive Images
Ein Bild, das auf einem 4K-Monitor scharfe 3000 × 2000 px braucht, wird auf einem Smartphone mit 375 px Breite nie in dieser Auflösung dargestellt. Dennoch wird es in vollem Umfang geladen, wenn keine responsive Bildstrategie implementiert ist.
Das HTML-Attribut srcset ermöglicht, dem Browser mehrere Bildversionen anzubieten, von denen er die passende lädt:
- Kleine Version (400 px) für Smartphones
- Mittlere Version (800 px) für Tablets
- Große Version (1600 px) für Desktop
Designer sollten beim Handoff an Entwickler: Figma, Zeplin, Storybook definieren, welche Bildausschnitte für verschiedene Bildschirmgrößen relevant sind (Art Direction), damit das responsiv-optimierte Bild das richtige Motiv zeigt.
Lazy Loading
Lazy Loading bedeutet, Bilder erst dann zu laden, wenn sie in den sichtbaren Bereich des Browsers (Viewport) kommen. Bilder, die weit unten auf einer langen Seite stehen, werden nicht beim ersten Laden geladen, sondern erst wenn der Nutzer dorthin scrollt.
Das spart erhebliche Ladezeit beim ersten Seitenaufruf. HTML unterstützt Lazy Loading nativ mit dem Attribut loading="lazy".
Wichtig: Das erste, sichtbare Bild Above the Fold: Was Besucher zuerst sehen sollte nicht lazy geladen werden – es ist sofort sichtbar und sollte sofort geladen sein. Nur Bilder unterhalb des sichtbaren Bereichs sollten lazy laden.
Bildgröße vs. Bildauflösung
Zwei häufig verwechselte Konzepte:
- Bildgröße = Pixel-Abmessungen (z. B. 1920 × 1080 px)
- Bildauflösung = Punkte pro Zoll (DPI/PPI), nur für Print relevant
Im Web zählt einzig die Pixelgröße. Eine Bild-DPI-Angabe von 72 vs. 300 dpi macht im Browser keinen Unterschied. Für die Ausgabe auf hochauflösenden Displays (Retina, HiDPI) sollten Bilder doppelt so groß wie der angezeigte Bereich sein: Ein 400 px breites Bild auf der Seite braucht eine 800 px Quelldatei.
Beispiele
Titelbild einer Landing Page: Statt 3,2 MB JPEG: AVIF-Version mit 180 KB + WebP-Fallback mit 320 KB. Gleiche visuelle Qualität, 90 % kleinere Datei.
Galerie mit 20 Fotos: Lazy Loading auf alle Nicht-Sichtbaren Bilder anwenden. Beim Seitenaufruf werden nur die 3–4 sichtbaren Bilder geladen. Restliche Bilder laden beim Scrollen nach.
Logo: Als SVG ausgeliefert: 3 KB, scharf auf jedem Bildschirm, skaliert verlustfrei. Als PNG wäre es für Retina-Displays bereits 50+ KB.
In der Praxis
Export-Einstellungen aus Figma
Figma exportiert direkt in WebP, JPEG, PNG und SVG. Empfohlene Einstellungen:
- Fotos: WebP, 80–85 % Qualität, 2x für Retina
- Logos/Icons: SVG oder PNG mit transparentem Hintergrund
- Screenshots/UI: PNG (verlustfrei)
Next-Gen Formats und Fallbacks
Nicht alle Browser unterstützen AVIF. Mit dem HTML <picture> Element können Browser ihren bevorzugten Format wählen:
``html <picture> <source srcset="bild.avif" type="image/avif"> <source srcset="bild.webp" type="image/webp"> <img src="bild.jpg" alt="Beschreibung"> </picture> ``
Browser wählen das erste unterstützte Format.
Vergleich & Abgrenzung
| Strategie | Aufwand | Gewinn |
|---|---|---|
| Format wechseln (JPEG → WebP) | Gering | Hoch (25–35 % kleiner) |
| Kompression erhöhen | Minimal | Mittel |
| Responsive Images (srcset) | Mittel | Sehr hoch (mobile spart 60–80 %) |
| Lazy Loading | Gering | Hoch (schnellerer First Load) |
Häufige Fragen (FAQ)
Soll ich alle Bilder in WebP konvertieren? Für neue Projekte: ja. Für bestehende Projekte kann eine schrittweise Migration sinnvoll sein. Browser-Support ist universell auf modernen Geräten.
Brauche ich AVIF oder reicht WebP? WebP ist der sichere Standard. AVIF bietet bessere Kompression, aber erhöhten Encoding-Aufwand und noch nicht universale Browser-Unterstützung. Progressive Enhancement: AVIF zuerst anbieten, WebP als Fallback.
Was ist das Maximale, das ich beim Export aus Figma tun kann? Richtige Formate wählen, sinnvolle Skalierung (2x für Retina), SVG für Vektorgrafiken. Weitere Optimierung (Kompression, Next-Gen-Formate) übernimmt der Entwicklungsworkflow.
Verwandte Einträge
- SVG für Designer: Skalierbare Vektorgrafiken im Web – Vektorgrafiken im Web
- Page Speed und Core Web Vitals: Was Designer wissen müssen – Bilder und Core Web Vitals
- Responsive Design: Grundlagen und Breakpoints – Bilder für verschiedene Bildschirmgrößen
- Above the Fold: Was Besucher zuerst sehen – Hero-Bilder und First Load Performance
- Handoff an Entwickler: Figma, Zeplin, Storybook – Bild-Spezifikationen übergeben
Weiterführend
- Google (2024). Use modern image formats. web.dev.
- Cimarosti, F. & Steiner, T. (2021). AVIF has landed. web.dev.
- Grigorik, I. (2019). High Performance Images. O'Reilly Media.
- Cloudinary (2024). Image Optimization Guide.
- ImageOptim (2024).
