Stand: Juli 2026
Produktbilder machen 80–90 % des Datenvolumens einer Shopseite aus. Google fordert „Bilder in modernen Formaten“ nicht erst seit gestern: Das Lighthouse-/PageSpeed-Audit „Serve images in next-gen formats“ existiert seit Mitte 2018 (WebP), AVIF ist seit 2021 Teil des Audits — und das Ergebnis fließt sichtbar in jede PageSpeed-Bewertung ein. AVIF liefert dieselbe sichtbare Qualität bei rund 20 % der JPEG-Größe, WebP bei etwa 30 %.
Und jetzt der Realitäts-Check, der in vielen Shops die Modernisierung blockiert: Die Bilder kommen aus der Warenwirtschaft — und die kann oft nur JPEG. Jahre, nachdem Google moderne Formate zum Kriterium gemacht hat, liefern etablierte Systeme munter weiter ausschließlich das Format der 90er. Wer auf das Release des Herstellers wartet, wartet mit seinen Rankings.
Warum „einfach alle Bilder konvertieren“ nicht die Antwort ist
Der naheliegende Plan — alle Bilder vorab umwandeln — scheitert an der Praxis: Ein gewachsener Shop hat schnell sechsstellige Bildbestände; die Konvertierung müsste bei jedem Import neu laufen, und zwar pro Zielformat. Dazu kommt: Nicht jeder Browser kann AVIF, manche können nicht einmal WebP — man bräuchte ohnehin mehrere Varianten pro Bild plus die Logik, jedem Browser die richtige zu geben. Und das Shopsystem selbst hilft nur begrenzt: Shopware erzeugt Thumbnails klassisch als JPEG/PNG (WebP je nach Version/Konfiguration), AVIF bleibt außen vor.
Die Lösung: Content Negotiation im CDN
Jeder Browser schickt bei jedem Bildabruf mit, welche Formate er versteht — im Accept-Header (Content Negotiation). Ein CDN kann darauf reagieren und unter derselben URL unterschiedliche Inhalte ausliefern:
Gleiche URL: /media/produkt/angelrute.jpg
Chrome/Firefox/Safari 16+ → AVIF (~20 % der JPEG-Größe)
älterer Safari → WebP (~30 %)
Uralt-Browser → JPEG (Original)Die Konvertierung passiert in der Auslieferungsschicht — beim ersten Abruf einer Variante wird konvertiert, danach liegt sie im Cache. Architektonisch heißt das: Die konvertierten Varianten landen in einem Objektspeicher (S3), und der wird zum Bild-Origin der CloudFront-Distribution — der Shop-Server ist aus der Bild-Auslieferung damit komplett raus. Kein Vorab-Batch über den ganzen Bestand, keine Änderung an Bild-URLs, und vor allem: kein Eingriff ins Altsystem. Die Warenwirtschaft liefert weiter ihre JPEGs und muss von alledem nichts wissen.
Bemerkenswert an der Praxis-Chronologie: Das Setup, aus dem diese Seite ihre Zahlen hat, ist evolutionär gewachsen — zuerst lief dort das Standard-CDN im Pull-Betrieb vor dem Shop, ganz ohne S3. Das Bildformat-Projekt kam später obendrauf: S3 + Konvertierungs-Pipeline als neuer Bild-Origin in derselben Distribution — ohne dass sich an Shop-Config, URLs oder DNS irgendetwas geändert hätte. Das ist die eigentliche Stärke der Architektur: Man startet klein und rüstet am CDN nach, nie am Shop.
Das ist das Muster, das man sich merken sollte, denn es trägt weit über Bilder hinaus: Wenn eine Komponente in der Mitte des Stacks die Modernisierung blockiert, modernisiert man an der Schicht, die man selbst besitzt — der Auslieferung. Kein Warten auf Hersteller-Releases, kein riskanter Systemtausch; das Altsystem wird nicht repariert, sondern irrelevant für das Problem.
Worauf es in der Umsetzung ankommt
- Der
Accept-Header muss in den Cache-Schlüssel (bei CloudFront über die Cache-/Origin-Request-Policy) — sonst bekommt der IE-Nutzer das AVIF des Chrome-Nutzers. Dieselbe Varianten-Logik wie überall beim Caching (Cache-Quote). - Qualitätsparameter je Format prüfen (AVIF verträgt aggressivere Kompression als WebP bei gleicher Anmutung) — einmal einstellen, Stichproben ansehen.
- Fallback sauber halten: Wer den
Accept-Header nicht auswerten kann, bekommt das Original — es darf nie einen Browser geben, der gar kein Bild sieht. - Dasselbe Prinzip eine Schicht tiefer — Kompressions- statt Bildformate — zeigt Use Case 2: Assets mit Brotli Level 11.