Moderne Bildformate in der Produktions-Pipeline: WebP, AVIF

1. Kompressionseffizienz im Vergleich: JPEG/PNG vs. WebP vs. AVIF

JPEG arbeitet mit blockbasierter DCT-Kompression (Diskrete Kosinustransformation) und produziert bei niedriger Qualität sichtbare Blockartefakte, weil Bilddaten in 8x8-Pixel-Blöcke zerlegt und Frequenzanteile verlustbehaftet quantisiert werden. PNG ist verlustfrei und nutzt Filterung plus Deflate-Kompression, was bei Grafiken mit flachen Farbflächen, Text oder Transparenz gut funktioniert, bei Fotos aber zu unnötig großen Dateien führt. WebP nutzt die Intra-Frame-Prädiktion aus VP8 und eine effizientere Entropiekodierung als JPEG und erreicht bei vergleichbarer wahrgenommener Qualität typischerweise 25 bis 35 Prozent kleinere Dateien. AVIF, abgeleitet aus den Intra-Frames des AV1-Codecs, geht noch weiter: Durch größere Transformationsblöcke, bessere Prädiktionsmodi und adaptive Quantisierung sind 40 bis 50 Prozent Einsparung gegenüber JPEG realistisch, besonders bei niedrigen Bitraten.

In der Praxis sieht das bei einem typischen Hero-Bild in Full-HD-Breite so aus: ein JPEG mit Qualität 82 liegt bei rund 250 KB, dieselbe Aufnahme als WebP bei etwa 160 KB und als AVIF bei rund 110 KB, bei vergleichbarem SSIM-Wert. Der Encodier-Aufwand steigt allerdings in derselben Reihenfolge deutlich an, was für die spätere Pipeline-Automatisierung relevant wird. Für Batch-Konvertierungen im Build-Prozess eignen sich die Kommandozeilen-Encoder cwebp und avifenc, die sich in jedes Shell-Skript oder jede CI-Stage einbinden lassen.

#!/usr/bin/env bash
# batch-convert-images.sh - Convert all JPEG/PNG assets to WebP and AVIF
set -euo pipefail

SOURCE_DIR="pub/media/catalog/product"
QUALITY_WEBP=80
QUALITY_AVIF=32   # AVIF uses a CRF-like scale, lower is better quality

find "$SOURCE_DIR" -type f \( -iname "*.jpg" -o -iname "*.jpeg" -o -iname "*.png" \) -print0 |
while IFS= read -r -d '' src; do
  base="${src%.*}"

  # Skip if already converted and source has not changed (mtime check)
  if [[ -f "${base}.webp" && "${base}.webp" -nt "$src" ]]; then
    continue
  fi

  cwebp -q "$QUALITY_WEBP" -m 6 "$src" -o "${base}.webp"
  avifenc --min 20 --max 40 --cq-level "$QUALITY_AVIF" --speed 6 "$src" "${base}.avif"

  echo "[OK] $src -> ${base}.webp, ${base}.avif"
done

2. Verlustbehaftet vs. verlustfrei: Modi und ihre Kompromisse

Sowohl WebP als auch AVIF unterstützen neben dem verlustbehafteten Modus einen echten verlustfreien Modus, der mit einer eigenen Algorithmik arbeitet und nicht einfach die Qualitätsstufe auf Maximum setzt. WebP-Lossless nutzt Vorhersage-Transformationen und ein LZ77-ähnliches Backward-Reference-Schema, das bei Icons, Screenshots, Illustrationen mit flachen Farbflächen und Bildern mit viel Text deutlich kleinere Dateien liefert als PNG, oft 20 bis 30 Prozent. Für Fotos mit natürlichem Rauschen ist der verlustfreie Modus dagegen fast immer die falsche Wahl, weil er keine Redundanz findet, die er ausnutzen kann, und die Datei am Ende größer wird als eine gut komprimierte verlustbehaftete Version.

Ein oft übersehener Zwischenweg ist der near-lossless-Modus von WebP, der vor der eigentlichen verlustfreien Kompression eine sehr leichte, kaum wahrnehmbare Quantisierung anwendet und dadurch nochmal spürbar kleinere Dateien erzeugt, ohne in sichtbare Artefakte zu kippen. Bei AVIF spielt zusätzlich das Chroma-Subsampling eine Rolle: 4:2:0 halbiert die Farbauflösung gegenüber der Helligkeit und ist für Fotos meist unauffällig, während Grafiken mit farbigem Text oder scharfen Farbkanten von 4:4:4 profitieren, allerdings auf Kosten der Dateigröße. Die richtige Wahl zwischen Modus, Subsampling und Zielformat hängt also immer vom Bildinhalt ab, nicht von einer pauschalen Einstellung für den gesamten Katalog.

3. Browser-Support und Fallback-Strategie mit picture

WebP wird inzwischen von praktisch allen aktuellen Browsern unterstützt, inklusive Safari seit Version 14. AVIF ist jünger: Chrome und Firefox unterstützen es seit 2020/2021 vollständig, Safari erst ab Version 16, und ältere Android-WebViews sowie einige Enterprise-Browser-Umgebungen liefern noch keine oder nur unvollständige Unterstützung. Ein hartes Umschalten auf AVIF ohne Fallback würde diese Nutzer mit gebrochenen Bildern zurücklassen. Die robuste Lösung ist das <picture>-Element mit mehreren <source>-Elementen in absteigender Präferenz: Der Browser wählt automatisch die erste Quelle, deren type-Attribut er unterstützt, und fällt andernfalls auf das <img>-Element als letzte Instanz zurück.

Eine Alternative wäre serverseitige Content-Negotiation über den Accept-Request-Header, bei dem der Server anhand der vom Browser gemeldeten unterstützten Formate die passende Datei ausliefert. In der Praxis ist das für CDN-gestützte Shops aber riskant, weil jede Antwort dann von Accept abhängt und ein Vary: Accept-Header nötig wird, der den Cache in viele kleine Fragmente pro Client-Variante aufsplittet und die Trefferquote am Edge senkt. Die statische <picture>-Variante mit fest benannten Dateien pro Format ist deutlich CDN-freundlicher, weil jede URL genau eine Antwort hat und uneingeschränkt gecacht werden kann.

<!-- picture element: browser picks the first supported source, in order -->
<picture>
  <source type="image/avif" srcset="/media/catalog/product/hero.avif">
  <source type="image/webp" srcset="/media/catalog/product/hero.webp">
  <img
      src="/media/catalog/product/hero.jpg"
      width="1200"
      height="600"
      fetchpriority="high"
      loading="eager"
      alt="Product hero image"
      class="w-full h-auto object-cover"
  >
</picture>

4. Formatkonvertierung in der Build- und Deploy-Pipeline automatisieren

Bildkonvertierung gehört in die Build-Zeit, nicht in die Request-Zeit. Wer AVIF- oder WebP-Varianten bei jedem Seitenaufruf on-the-fly erzeugt, produziert unvorhersehbare CPU-Spitzen und riskiert, dass der erste Besucher nach jedem Cache-Flush eine langsame Antwort bekommt. Stattdessen läuft die Konvertierung als eigener Pipeline-Schritt, meist mit der Sharp-Bibliothek unter Node.js, die auf libvips aufbaut und intern dieselben Encoder wie cwebp und libaom nutzt, aber deutlich weniger Prozess-Overhead pro Bild erzeugt als der wiederholte Aufruf einzelner CLI-Tools.

Entscheidend für die Praxistauglichkeit ist Idempotenz: Ein Deploy-Skript, das bei jedem Lauf alle Bilder neu encodiert, verlangsamt die Pipeline mit wachsendem Katalog immer stärker. Ein Content-Hash oder ein einfacher mtime-Vergleich zwischen Quelldatei und bereits erzeugter Zieldatei verhindert unnötige Neuberechnung und macht aus einer Vollkonvertierung einen inkrementellen Schritt, der nur geänderte oder neue Bilder anfasst. In CI-Umgebungen lässt sich dieser Schritt zusätzlich cachen, indem das Ausgabeverzeichnis zwischen Pipeline-Läufen persistiert wird.

# .gitlab-ci.yml (excerpt) - dedicated image conversion stage before deploy
stages:
  - build
  - convert-images
  - deploy

convert-images:
  stage: convert-images
  image: node:20-slim
  cache:
    key: image-variants-cache
    paths:
      - pub/media/catalog/product/**/*.webp
      - pub/media/catalog/product/**/*.avif
  before_script:
    - npm ci --omit=dev
  script:
    - node scripts/generate-image-variants.js --input pub/media/catalog/product
  artifacts:
    paths:
      - pub/media/catalog/product/**/*.webp
      - pub/media/catalog/product/**/*.avif
    expire_in: 1 day
  only:
    - main

5. Qualitätseinstellungen: Der richtige Kompromiss

Die Qualitätsskalen der drei Formate sind nicht direkt vergleichbar. Bei WebP entspricht ein Wert zwischen 75 und 82 in der Praxis meist dem Sweet Spot zwischen Dateigröße und wahrnehmbarer Qualität. AVIF nutzt intern eine CRF-ähnliche Skala über cq-level, bei der niedrigere Werte für bessere Qualität stehen, ein Bereich von 28 bis 35 liefert für die meisten Produktfotos ein sehr gutes Verhältnis. Reine Dateigröße als Entscheidungskriterium reicht aber nicht aus: Zwei Encoder-Läufe mit identischer Zielgröße können völlig unterschiedliche wahrgenommene Qualität liefern, deshalb sollten Qualitätsentscheidungen über perzeptuelle Metriken wie SSIM oder Butteraugli validiert werden, nicht allein über Kilobyte.

Sinnvoll ist eine Qualitätsstrategie pro Bildkategorie statt eines globalen Werts für den gesamten Katalog. Produktfotos mit natürlichem Rauschen vertragen aggressivere Kompression, ohne dass Kunden den Unterschied bemerken. Banner mit feiner Typografie oder Verlaufsgrafiken benötigen dagegen höhere Qualitätsstufen, weil Kompressionsartefakte an scharfen Kanten und in Schriftzügen deutlich sichtbarer werden als in Fotos. Ein automatisierter Regressionstest, der neue Bildvarianten gegen eine perzeptuelle Schwelle prüft, verhindert, dass ein zu aggressiv eingestellter Encoder unbemerkt sichtbare Qualitätseinbußen in die Produktion bringt.

6. Integration in die Magento Media-Pipeline

Magento erzeugt Produktbild-Varianten (Thumbnail, Small Image, Base Image, Swatch) über Magento\Catalog\Model\View\Asset\Image und speichert sie im pub/media/catalog/product/cache-Verzeichnis, sobald ein Frontend-Request die jeweilige Größe erstmals anfordert oder catalog:images:resize ausgeführt wird. Der sauberste Integrationspunkt für die Formatkonvertierung ist ein Observer auf das Event, das nach dem Resize ausgelöst wird, oder ein Plugin um den Resize-Befehl selbst, das nach jeder erzeugten JPEG-Variante zusätzlich WebP- und AVIF-Geschwister anlegt. Das hält die Konvertierungslogik an der gleichen Stelle wie die Größengenerierung und verhindert, dass Bildvarianten und Formatvarianten auseinanderlaufen.

Für Deploys über CI, bei denen pub/media nicht auf dem Admin-System, sondern separat synchronisiert wird, sollte der catalog:images:resize-Lauf und die anschließende Formatkonvertierung als expliziter Pipeline-Schritt nach dem Deploy erfolgen, damit ein frisch aufgesetzter Container nicht erst beim ersten echten Besucher-Request alle Bildvarianten synchron erzeugt. Im phtml-Template genügt anschließend ein einfacher Check, ob die WebP- oder AVIF-Datei neben dem Original existiert, um sie im <picture>-Markup einzubinden.

<?php
declare(strict_types=1);

namespace Mironsoft\ImagePipeline\Plugin;

use Magento\Catalog\Model\Product\Image\ParamsBuilder;
use Magento\Framework\Image\Factory as ImageFactory;

/**
 * Generates WebP and AVIF siblings whenever Magento resizes a product image.
 */
class GenerateModernFormatsPlugin
{
    /**
     * @param ImageFactory $imageFactory Factory used to instantiate encoder adapters.
     */
    public function __construct(
        private readonly ImageFactory $imageFactory,
    ) {
    }

    /**
     * Runs after the base image resize and writes WebP/AVIF variants next to the JPEG.
     *
     * @param \Magento\Catalog\Model\Product\Image $subject The resized image model.
     * @param \Magento\Catalog\Model\Product\Image $result The original return value.
     * @return \Magento\Catalog\Model\Product\Image
     */
    public function afterResize(
        \Magento\Catalog\Model\Product\Image $subject,
        \Magento\Catalog\Model\Product\Image $result,
    ): \Magento\Catalog\Model\Product\Image {
        $destination = $subject->getNewFile();

        if ($destination === '' || !str_ends_with($destination, '.jpg')) {
            return $result;
        }

        $image = $this->imageFactory->create($destination);
        $image->quality(80);
        $image->save(str_replace('.jpg', '.webp', $destination));
        $image->save(str_replace('.jpg', '.avif', $destination));

        return $result;
    }
}

7. Responsive Varianten kombiniert mit modernen Formaten

Responsive Bilder und moderne Formate lösen unterschiedliche Probleme und werden trotzdem oft verwechselt. srcset mit mehreren Breitenangaben löst das Problem unterschiedlicher Viewport-Größen, während WebP und AVIF das Problem der Kompressionseffizienz pro Bildpixel lösen. Kombiniert man beides, entsteht eine Matrix aus Breiten mal Formaten: Ein einzelnes Produktbild kann so leicht sechs oder mehr Dateien erzeugen, etwa 400w, 800w und 1200w jeweils in JPEG, WebP und AVIF. Diese Vervielfachung ist beabsichtigt und notwendig, treibt aber die Anzahl der zu verwaltenden Dateien im Media-Verzeichnis erheblich in die Höhe.

Im Markup bleibt die Struktur trotzdem übersichtlich: Jedes <source>-Element im <picture> bekommt neben dem type-Attribut ein eigenes srcset mit den Breitenvarianten des jeweiligen Formats, sodass der Browser in zwei Schritten entscheidet, zuerst das unterstützte Format, dann die passende Breite. Generiert wird diese Matrix am effizientesten in einem einzigen Sharp-Durchlauf pro Quellbild, der alle Zielbreiten und Zielformate in einer Pipeline verkettet, statt das Quellbild für jede Kombination erneut von der Festplatte zu lesen.

// generate-image-variants.js - Build a width x format matrix with sharp
const sharp = require('sharp');
const { globSync } = require('glob');
const path = require('node:path');

const WIDTHS = [400, 800, 1200];
const FORMATS = [
  { ext: 'avif', options: { quality: 55, effort: 6 } },
  { ext: 'webp', options: { quality: 80, effort: 5 } },
];

async function processImage(sourcePath) {
  const dir = path.dirname(sourcePath);
  const name = path.basename(sourcePath, path.extname(sourcePath));

  // Read the source once, then fan out into width x format variants
  const pipeline = sharp(sourcePath).rotate();

  for (const width of WIDTHS) {
    for (const format of FORMATS) {
      const outPath = path.join(dir, `${name}-${width}w.${format.ext}`);
      await pipeline
        .clone()
        .resize({ width, withoutEnlargement: true })
        [format.ext](format.options)
        .toFile(outPath);
    }
  }
}

const sources = globSync('pub/media/catalog/product/**/*.{jpg,jpeg,png}');
Promise.all(sources.map(processImage)).then(() => {
  console.log(`Generated variants for ${sources.length} source images`);
});

8. Caching und CDN-Strategie für konvertierte Assets

Konvertierte Bildvarianten sollten wie jedes andere versionierte Static Asset behandelt werden: lange Cache-Control-Header mit immutable und einer Gültigkeit von einem Jahr, weil sich der Dateiinhalt unter einer bestimmten URL nach dem Deploy nicht mehr ändert. Invalidierung erfolgt nicht über eine kurze TTL, sondern über eine neue Datei, etwa durch einen Content-Hash im Dateinamen oder eine neue Cache-Generation im Pfad, sobald ein Produktbild ausgetauscht wird. Wichtig ist, dass jede Formatvariante eine eigene, stabile URL bekommt, statt Format und Größe über Query-Parameter zu steuern, da viele CDN-Konfigurationen Query-Strings standardmäßig aus dem Cache-Key entfernen und dann versehentlich die falsche Variante ausliefern.

Nach einem Deploy mit frisch erzeugten Bildvarianten lohnt sich ein gezieltes Cache-Warming für die am häufigsten aufgerufenen Kategorie- und Produktseiten, damit nicht der erste echte Besucher die Origin-Anfrage für jede neue Bildvariante auslöst. Der Speicherbedarf steigt durch die Kombination aus mehreren Formaten und mehreren Breiten spürbar, in der Praxis auf das Zwei- bis Dreifache des reinen JPEG-Bestands, was bei der Dimensionierung von Object Storage und CDN-Origin-Kapazität von Anfang an eingeplant werden sollte.

9. Bildformate im direkten Vergleich: Entscheidungshilfe

Die folgende Übersicht fasst die wichtigsten Unterschiede zwischen den drei Formaten zusammen und zeigt, wo die Grenzen jeder Technologie liegen. Sie dient als schnelle Entscheidungshilfe für die Formatwahl in einer neuen Pipeline.

In der Praxis ist die Entscheidung selten binär. Eine belastbare Strategie liefert AVIF als bevorzugtes Format für unterstützende Browser, WebP als breit kompatible zweite Stufe und JPEG oder PNG als universellen Fallback, jeweils gesteuert über das <picture>-Element. Für Build-Pipelines mit engem Zeitbudget kann es sinnvoll sein, AVIF zunächst nur für die größten und meistgesehenen Bilder wie Hero-Banner zu erzeugen und den Rest des Katalogs schrittweise nachzuziehen, statt die gesamte Konvertierung in einem einzigen, potenziell sehr langen Deploy zu erzwingen.

10. Zusammenfassung

Moderne Bildformate lösen ein sehr konkretes Performance-Problem: Bilder machen in den meisten Shops den größten Anteil am Seitengewicht aus, und WebP sowie AVIF reduzieren diesen Anteil messbar, ohne dass Kunden einen Qualitätsverlust wahrnehmen. AVIF liefert die stärkste Kompression, verlangt dafür aber deutlich mehr Encodier-Zeit und hat noch nicht ganz die Reichweite von WebP, weshalb ein gestuftes Fallback über das <picture>-Element derzeit die robusteste Lösung ist. Automatisierte Konvertierung als eigener, idempotenter Pipeline-Schritt verhindert sowohl manuelle Handarbeit als auch unvorhersehbare CPU-Last zur Laufzeit.

Für Magento-Shops ist der entscheidende Hebel, die Formatkonvertierung an derselben Stelle wie die bestehende Bildgrößen-Pipeline zu verankern, über ein Plugin oder einen Observer auf den Resize-Prozess, statt eine separate, parallele Logik zu pflegen. Kombiniert mit einer durchdachten Cache- und CDN-Strategie für die zusätzlichen Formatvarianten lässt sich so eine spürbare Reduktion der übertragenen Bilddaten erreichen, ohne die Build-Pipeline unkontrolliert zu verlangsamen oder den Storage-Bedarf unnötig aufzublähen.

11. FAQ: Moderne Bildformate in der Produktions-Pipeline