Bildoptimierung 2026: WebP, AVIF und responsive Auslieferung

Die Zahlen sprechen eine deutliche Sprache: Laut HTTP Archive beträgt die mittlere Seitengröße einer Desktop-Website im Jahr 2025 rund 2,4 MB, wobei Bilder durchschnittlich 1,2 MB ausmachen (Quelle: HTTP Archive, 2025). Auf mobilen Geräten ist das Verhältnis noch ungünstiger, da dort häufig dieselben Desktop-Bilder ausgeliefert werden, obwohl der Bildschirm nur ein Drittel der Pixel darstellt. Diese Verschwendung kostet nicht nur Ladezeit, sondern auch reales Geld: Bei mobilen Datentarifen mit Volumenbegrenzung zahlt der Nutzer buchstäblich für unnötig große Bilder.

Der Largest Contentful Paint (LCP) misst, wann das größte sichtbare Element im Viewport vollständig gerendert ist. Bei den meisten Websites ist dieses Element ein Bild – das Hero-Bild, ein Produktfoto oder ein Banner. Google definiert einen LCP unter 2,5 Sekunden als gut (Quelle: Google, 2024). Websites mit unoptimiertem LCP verlieren durchschnittlich 7 Prozent ihrer Conversions pro Sekunde zusätzlicher Ladezeit (Quelle: Portent, 2022). Das macht die Bildoptimierung zum direkten Umsatztreiber.

Doch Bildoptimierung geht weit über das bloße Komprimieren von Dateien hinaus. Ein ganzheitlicher Ansatz umfasst die Wahl des richtigen Formats, die Bereitstellung verschiedener Größen für unterschiedliche Geräte, eine durchdachte Ladestrategie und die Automatisierung des gesamten Prozesses. Wer all diese Aspekte berücksichtigt, kann die durch Bilder verursachte Datenmenge um 80 bis 95 Prozent reduzieren – ohne sichtbaren Qualitätsverlust.

WebP wurde von Google entwickelt und ist seit 2010 verfügbar. Inzwischen unterstützen 96 Prozent aller aktiven Browser das Format (Quelle: Can I Use, 2025), einschließlich Safari ab Version 14. WebP bietet sowohl verlustbehaftete als auch verlustfreie Kompression und unterstützt Transparenz (Alpha-Kanal) sowie Animationen. Im Vergleich zu JPEG erzielt WebP bei gleicher visueller Qualität durchschnittlich 25 bis 35 Prozent kleinere Dateien (Quelle: Google Developers, 2024).

Die Stärke von WebP liegt in der universellen Unterstützung. Anders als neuere Formate ist WebP in praktisch jedem modernen Browser verfügbar, was es zur sicheren Standardwahl für die Bildauslieferung macht. Die verlustbehaftete Kompression verwendet einen VP8-basierten Algorithmus, der besonders bei fotografischen Inhalten mit vielen Farbverläufen effizient arbeitet. Die verlustfreie Variante eignet sich für Grafiken, Screenshots und Bilder mit Text, bei denen jedes Detail erhalten bleiben muss.

Ein wichtiger Aspekt bei der WebP-Konvertierung ist die Qualitätseinstellung. Der Standardwert von 75 Prozent Qualität liefert für die meisten Anwendungsfälle ein gutes Verhältnis zwischen Dateigröße und visueller Qualität. Für Hero-Bilder und Produktfotos empfehlen wir eine Qualität von 80 bis 85 Prozent, für Thumbnails und Hintergrundbilder reichen 60 bis 70 Prozent. Diese Differenzierung allein spart zusätzlich 15 bis 25 Prozent Datenmenge gegenüber einem einheitlichen Qualitätswert.

AVIF (AV1 Image File Format) basiert auf dem AV1-Videocodec und repräsentiert den aktuellen Stand der Technik in der Bildkompression. Das Format wurde 2019 spezifiziert und hat in den letzten Jahren rasant an Browser-Unterstützung gewonnen: 92 Prozent aller aktiven Browser unterstützen AVIF inzwischen (Quelle: Can I Use, 2025). Chrome, Firefox, Safari ab Version 16 und Edge bieten vollständige Unterstützung. Gegenüber JPEG erreicht AVIF bei gleicher visueller Qualität 50 bis 70 Prozent kleinere Dateien, gegenüber WebP sind es noch 20 bis 35 Prozent (Quelle: Netflix Technology Blog, 2024).

Die technischen Vorteile von AVIF gehen über die reine Kompressionsrate hinaus. Das Format unterstützt HDR (High Dynamic Range), einen Farbraum von 10 und 12 Bit pro Kanal sowie Transparenz und Film-Grain-Synthese. Für Web-Anwendungen ist besonders die überlegene Kompression bei niedrigen Bitraten relevant: Dort, wo WebP bei aggressiver Kompression sichtbare Artefakte erzeugt, liefert AVIF noch ansprechende Ergebnisse. Das macht AVIF ideal für mobile Auslieferung, wo jedes eingesparte Kilobyte zählt.

Der Hauptnachteil von AVIF ist die Kodierungsgeschwindigkeit. Die Erstellung einer AVIF-Datei dauert deutlich länger als bei WebP oder JPEG – je nach Einstellung 5 bis 20 Mal so lang. Für statische Websites und Shops, bei denen Bilder einmalig beim Upload konvertiert werden, ist das kein Problem. Für Anwendungen, die Bilder in Echtzeit konvertieren müssen, kann die Kodierungszeit jedoch zum Flaschenhals werden. Die Dekodierung im Browser ist hingegen schnell und stellt keinen Engpass dar.

Die Entscheidung zwischen WebP und AVIF ist keine Entweder-oder-Frage. In der Praxis sollten beide Formate parallel eingesetzt werden, wobei der Browser das optimale Format über Content Negotiation oder das HTML-picture-Element auswählt. Die Auslieferungskette folgt dabei einer klaren Hierarchie: AVIF als bevorzugtes Format, WebP als Fallback und JPEG als universelle Absicherung für die verbleibenden 4 Prozent der Browser ohne WebP-Unterstützung.

Für fotografische Inhalte – Produktfotos, Teambilder, Hero-Bilder – ist AVIF fast immer die beste Wahl. Die überlegene Kompression bei niedrigen Bitraten macht sich besonders bei großflächigen Farbverläufen, Hauttönen und feinen Details bemerkbar. Für Grafiken mit scharfen Kanten – Screenshots, Diagramme, Logos – liefert WebP in verlustfreier Kompression oft bessere Ergebnisse als AVIF, da der AV1-Codec primär für natürliche Bilder optimiert ist.

Ein weiterer Faktor ist die Kodierungsinfrastruktur. Wenn Bilder über ein CMS oder einen Shop hochgeladen und in Echtzeit konvertiert werden müssen, kann die langsame AVIF-Kodierung zum Problem werden. In diesem Fall empfehlen wir, AVIF-Varianten asynchron im Hintergrund zu erstellen und bis zur Fertigstellung WebP auszuliefern. Bei statischen Websites, die per Build-Prozess erstellt werden, spielt die Kodierungszeit keine Rolle, da die Konvertierung einmalig beim Build erfolgt.

Die häufigste Form der Bildverschwendung ist nicht das falsche Format, sondern die falsche Größe. Wenn ein 2400 Pixel breites Bild auf einem Smartphone mit 400 Pixel Viewport-Breite angezeigt wird, werden 83 Prozent der übertragenen Pixel nie sichtbar. Das srcset-Attribut löst dieses Problem, indem es dem Browser mehrere Größenvarianten desselben Bildes anbietet und ihm die Auswahl der optimalen Variante überlässt.

Ein durchdachtes srcset-Setup umfasst typischerweise vier bis sechs Breakpoints: 400w für Smartphones, 800w für Tablets, 1200w für Desktop-Bildschirme und 2400w für Retina-Displays. Das sizes-Attribut teilt dem Browser mit, wie breit das Bild im Layout tatsächlich dargestellt wird, damit er die richtige Variante wählen kann, ohne das CSS erst parsen zu müssen. Ein Beispiel: sizes="(max-width: 640px) 100vw, (max-width: 1024px) 50vw, 33vw" teilt dem Browser mit, dass das Bild auf Smartphones die volle Breite einnimmt, auf Tablets die Hälfte und auf Desktop-Bildschirmen ein Drittel.

Die Kombination von picture, source und srcset ermöglicht die gleichzeitige Format- und Größenauswahl. Jedes source-Element definiert ein Format mit den zugehörigen Größenvarianten, und der Browser wählt sowohl das beste Format als auch die passende Größe. Diese Technik eliminiert die Bildverschwendung nahezu vollständig – das tatsächlich übertragene Bild ist immer so nah wie möglich an der tatsächlich benötigten Größe.

Selbst perfekt komprimierte und responsiv ausgelieferte Bilder belasten die initiale Ladezeit, wenn sie alle gleichzeitig geladen werden. Lazy Loading verzögert das Laden von Bildern, bis sie in den sichtbaren Bereich des Browsers scrollen oder kurz davor stehen. Das native loading="lazy"-Attribut wird von 96 Prozent der Browser unterstützt (Quelle: Can I Use, 2025) und benötigt weder JavaScript noch externe Bibliotheken.

Die korrekte Implementierung unterscheidet zwischen Above-the-Fold- und Below-the-Fold-Bildern. Das LCP-Bild und alle anderen Bilder im initialen Viewport sollten nicht lazy-loaded werden, da das die Core Web Vitals verschlechtern würde. Stattdessen erhalten sie loading="eager" und fetchpriority="high", damit der Browser sie priorisiert lädt. Alle Bilder unterhalb des sichtbaren Bereichs erhalten loading="lazy" und decoding="async". Diese Kombination reduziert die initialen HTTP-Requests und die übertragene Datenmenge erheblich.

Ein häufiger Fehler bei Lazy Loading sind fehlende width- und height-Attribute. Ohne explizite Dimensionen kann der Browser keinen Platz für das Bild reservieren, was beim Laden zu Layoutverschiebungen führt – dem Cumulative Layout Shift (CLS), einer der drei Core Web Vitals. Die Lösung ist einfach: Jedes img-Element erhält die intrinsischen Dimensionen als width und height, kombiniert mit style="aspect-ratio: auto" oder einem CSS-Aspect-Ratio-Container. So bleibt das Layout stabil, auch bevor das Bild geladen ist.

Die Wahl der richtigen Kompressionsqualität ist entscheidend für das Ergebnis. Zu aggressive Kompression erzeugt sichtbare Artefakte – Blockbildung, Farbverfälschung und Detailverlust. Zu konservative Kompression verschwendet Bandbreite ohne sichtbaren Qualitätsgewinn. Die optimale Einstellung hängt vom Bildtyp, dem Verwendungszweck und dem Format ab.

Für WebP empfehlen wir eine differenzierte Strategie: Hero-Bilder und Produktfotos mit Qualität 80-85, allgemeine Content-Bilder mit Qualität 72-78 und Thumbnails sowie Vorschaubilder mit Qualität 60-68. Für AVIF liegen die optimalen Werte niedriger, da der Codec bei gleicher Qualitätsstufe weniger Artefakte erzeugt: Hero-Bilder bei Qualität 65-72, Content-Bilder bei Qualität 55-65 und Thumbnails bei Qualität 45-55. Diese Differenzierung spart 20 bis 40 Prozent Datenmenge gegenüber einem einheitlichen Qualitätswert für alle Bilder.

Ein professioneller Qualitätsvergleich sollte immer visuell und metrisch erfolgen. Der SSIM-Index (Structural Similarity Index) quantifiziert die wahrgenommene Qualitätsdifferenz zwischen Original und komprimiertem Bild auf einer Skala von 0 bis 1. Ein SSIM von 0,95 oder höher bedeutet, dass der Unterschied für das menschliche Auge praktisch nicht erkennbar ist. Tools wie libvips und sharp können den SSIM automatisch berechnen, sodass die optimale Qualitätsstufe für jedes Bild individuell ermittelt werden kann.

Ein Image-CDN übernimmt die gesamte Bildoptimierung als externen Service: Formatkonvertierung, Größenanpassung, Qualitätsoptimierung und Auslieferung über ein globales Edge-Netzwerk. Der Vorteil liegt in der Einfachheit – statt eine eigene Pipeline aufzubauen, verweisen alle Bild-URLs auf den CDN-Service, der die Transformation on-the-fly durchführt und das Ergebnis cachet.

Die Architektur eines Image-CDN folgt einem URL-basierten Transformationsmodell. Parameter wie Format, Breite, Qualität und Crop werden direkt in der URL kodiert. Der erste Aufruf löst die Transformation aus und speichert das Ergebnis im Edge-Cache. Alle nachfolgenden Aufrufe werden direkt aus dem Cache beantwortet, ohne erneute Transformation. Diese Architektur eignet sich besonders für E-Commerce-Shops mit Tausenden von Produktbildern, die in verschiedenen Größen und Formaten benötigt werden.

Für Websites mit selbstgehosteter Infrastruktur bieten Open-Source-Lösungen eine Alternative zu kommerziellen Image-CDNs. Tools wie imgproxy oder thumbor lassen sich als Docker-Container betreiben und bieten ähnliche Transformationsmöglichkeiten. Der Aufwand für Setup und Betrieb ist höher, dafür entfallen laufende Servicekosten. Wir empfehlen selbstgehostete Lösungen für Projekte mit vorhersehbarem Bildvolumen und kommerzielles Image-CDN für Projekte mit stark variierendem oder sehr hohem Volumen.

Für statische Websites und Shop-Systeme, bei denen Bilder zum Build-Zeitpunkt bekannt sind, ist eine Build-Pipeline der effizienteste Ansatz. Die Pipeline konvertiert jedes Quellbild automatisch in alle benötigten Formate und Größen und erzeugt die zugehörigen picture-Elemente. Änderungen am Quellbild lösen automatisch eine Neugenerierung aller Varianten aus.

Eine typische Pipeline besteht aus vier Schritten: Zuerst werden die Quellbilder analysiert – Dimensionen, Farbprofil und Inhalt bestimmen die optimale Kompressionseinstellung. Dann erzeugt die Pipeline die Größenvarianten gemäß den definierten Breakpoints. Im dritten Schritt werden alle Varianten in WebP und AVIF konvertiert, wobei die Qualitätseinstellung bildtypabhängig ist. Zum Schluss werden die HTML-picture-Elemente mit allen Quellen und srcsets generiert. Der gesamte Prozess läuft automatisiert und reproduzierbar.

Die Integration in bestehende Build-Systeme wie Vite, webpack oder Gulp ist mit Bibliotheken wie sharp oder @squoosh/lib unkompliziert. Für Shopware-basierte Shops bieten Plugins die Möglichkeit, die Konvertierung beim Bild-Upload oder als Batch-Verarbeitung durchzuführen. Entscheidend ist, dass der Prozess keine manuelle Intervention erfordert – jedes hochgeladene Bild wird automatisch optimal aufbereitet, ohne dass Redakteure oder Shop-Betreiber sich um Formate und Kompression kümmern müssen.

Die größte Herausforderung der Bildoptimierung liegt nicht in der Technik, sondern im Workflow. Wenn Redakteure Bilder über ein CMS hochladen, muss die Optimierung transparent im Hintergrund erfolgen. Ein Upload von 5 MB großen Kamera-JPEGs darf nicht dazu führen, dass diese unverändert an die Besucher ausgeliefert werden. Stattdessen sollte das System automatisch Varianten erzeugen und das picture-Element generieren.

Für Shopware-basierte Shops gibt es mehrere Ansätze: Die Thumbnails-Konfiguration erzeugt Größenvarianten beim Upload, muss aber für optimale Ergebnisse korrekt konfiguriert werden. Die Standard-Breakpoints (400, 800, 1920 Pixel) decken die wichtigsten Geräteklassen ab, sollten aber um eine Retina-Variante (2x der Desktop-Breite) ergänzt werden. Für die Formatkonvertierung zu WebP und AVIF sind serverseitige Plugins oder ein vorgelagerter Bildservice erforderlich.

Ein häufig übersehener Aspekt ist die Metadaten-Bereinigung. Kamera-Bilder enthalten EXIF-Daten, ICC-Farbprofile und Thumbnail-Vorschauen, die zusammen mehrere Hundert Kilobyte umfassen können. Diese Daten sind für die Webdarstellung nicht relevant und sollten beim Upload entfernt werden. Allein das Stripping der EXIF-Daten spart bei Fotos typischerweise 50 bis 200 KB pro Bild – bei einem Shop mit 10.000 Produktbildern summiert sich das auf mehrere Gigabyte ungenutzter Daten.

Der Largest Contentful Paint ist die Core-Web-Vital-Metrik, die am stärksten von der Bildoptimierung beeinflusst wird. In 72 Prozent aller Fälle ist das LCP-Element ein Bild (Quelle: Web Almanac, 2024). Die Optimierung des LCP-Bildes erfordert einen anderen Ansatz als die allgemeine Bildoptimierung, da hier die Geschwindigkeit der Auslieferung Priorität vor der Dateigröße hat.

Die wichtigsten Maßnahmen für ein schnelles LCP-Bild sind: Preload über im HTML-Head, damit der Browser das Bild so früh wie möglich lädt. Kein Lazy Loading für das LCP-Bild – es muss mit loading="eager" ausgeliefert werden. Inline-CSS für den Bildcontainer, damit der Browser die Abmessungen kennt, bevor das CSS-Sheet geladen ist. Und DNS-Prefetch für externe Bildquellen, um die DNS-Auflösung parallel zum HTML-Parsing durchzuführen.

Ein verbreiteter Fehler ist die Auslieferung des LCP-Bildes über JavaScript oder CSS-Hintergrundbilder. Beide Varianten verzögern das Laden, da der Browser das Bild erst entdecken kann, wenn das JavaScript oder CSS vollständig geparst ist. Das LCP-Bild sollte immer als reguläres -Element oder innerhalb eines -Elements im HTML stehen, damit der Preload-Scanner des Browsers es bereits beim HTML-Parsing erkennt und priorisiert.

Die Wirksamkeit der Bildoptimierung muss kontinuierlich gemessen werden. Die wichtigsten Metriken sind der LCP als Core Web Vital, die Gesamtgröße der Bilddaten pro Seite, die Anzahl der Bild-Requests und der Anteil moderner Formate an der gesamten Bildauslieferung. Ein professionelles Performance-Monitoring erfasst diese Metriken automatisch und warnt bei Regressionen.

Besonders aufschlussreich ist die Analyse nach Gerätetyp. Mobile Nutzer mit langsamen Verbindungen sind von suboptimaler Bildoptimierung am stärksten betroffen. Die Felddaten des Chrome User Experience Report (CrUX) zeigen die tatsächliche LCP-Verteilung für verschiedene Gerätetypen und Verbindungsgeschwindigkeiten. Wenn der mobile LCP deutlich schlechter ist als der Desktop-LCP, liegt die Ursache häufig in fehlenden responsiven Bildvarianten.

Für den kontinuierlichen Optimierungsprozess empfehlen wir ein monatliches Bild-Audit: Welche Seiten haben die meisten Bilddaten? Welche Bilder werden in veralteten Formaten ausgeliefert? Welche Bilder fehlen in der srcset-Konfiguration? Diese Fragen lassen sich mit Server-seitiger Analyse und Crawler-Tools automatisiert beantworten. Das Ergebnis ist ein priorisierter Maßnahmenkatalog, der die größten Einsparpotenziale zuerst adressiert.

Bildoptimierung ist kein einmaliges Projekt, sondern ein fortlaufender Prozess, der in den Content-Workflow integriert sein muss. Die Kombination aus modernen Formaten (AVIF mit WebP-Fallback), responsiver Auslieferung (srcset/sizes), durchdachtem Lazy Loading und automatisierter Build-Pipeline bildet das Fundament für optimale Bildperformance. Wer diese Maßnahmen konsequent umsetzt, kann die durch Bilder verursachte Datenmenge um 80 bis 95 Prozent reduzieren und den LCP um 30 bis 50 Prozent verbessern.

Der Aufwand für die initiale Einrichtung einer Bildoptimierungs-Pipeline amortisiert sich schnell: Schnellere Ladezeiten führen zu besseren Core Web Vitals, die wiederum das Ranking in der organischen Suche verbessern. Gleichzeitig sinken die Hosting-Kosten durch reduzierten Traffic und die Nutzererfahrung verbessert sich messbar – besonders auf mobilen Geräten, wo die Mehrheit der Web-Nutzung heute stattfindet. Mit der richtigen Strategie und den passenden Frontend-Optimierungen wird die Bildauslieferung vom Performance-Problem zum Wettbewerbsvorteil.