Image-CDN-Architektur für automatische Optimierung

1. Warum statische Bildvarianten an ihre Grenzen stoßen

Der klassische Ansatz für Bildoptimierung in Magento-Shops erzeugt bei jedem Build oder Import feste Bildgrößen: Thumbnail, Small, Medium, Large. Das funktioniert, solange die Menge der benötigten Varianten überschaubar bleibt. Sobald aber neue Breakpoints, neue Endgeräte-Pixeldichten oder neue Bildformate wie AVIF hinzukommen, wächst die Zahl der vorab zu generierenden Dateien exponentiell. Ein Katalog mit 50.000 Produkten und zehn Zielgrößen pro Bild erzeugt schnell eine halbe Million Dateien, von denen die meisten nie abgerufen werden.

Eine Image-CDN-Architektur kehrt dieses Modell um: Statt Varianten vorab zu erzeugen, wird jede Transformation on-the-fly bei der ersten Anfrage ausgeführt und danach als Edge-Cache-Eintrag vorgehalten. Das Origin-System speichert nur ein einziges hochauflösendes Quellbild pro Produkt. Alle Zielgrößen, Formate und Qualitätsstufen entstehen bedarfsgesteuert. Das reduziert Speicherverbrauch am Origin drastisch und macht neue Ausgabeformate zu einer reinen Konfigurationsänderung statt zu einem kompletten Re-Encoding-Lauf über den gesamten Katalog.

Der Denkfehler, der viele Teams zurückhält: On-the-fly-Transformation klingt nach Laufzeit-Overhead bei jedem Seitenaufruf. Tatsächlich trifft die Transformation nur den ersten Request pro Variante, denn danach übernimmt der Cache. In der Praxis liegt die Cache-Hit-Rate bei stabilen Produktbildern nach der Anlaufphase regelmäßig über 98 Prozent, wodurch der Rechenaufwand der Transformation für die überwiegende Mehrheit der Requests komplett entfällt.

2. URL-Parameter-basierte Transformation: Architekturprinzip

Das zentrale Architekturmuster kodiert die gewünschte Transformation direkt in der Bild-URL. Ein Request wie /img/w:800/h:600/q:80/f:webp/catalog/product/sample.jpg beschreibt vollständig, welche Breite, Höhe, Qualität und welches Zielformat erwartet werden. Der Transformationsdienst parst diese Parameter, lädt das Quellbild vom Origin oder aus dem eigenen Cache, führt die Transformation aus und liefert das Ergebnis mit passenden Cache-Headern aus. Diese URL ist gleichzeitig der Cache-Key: identische Parameter erzeugen deterministisch dieselbe URL und damit denselben Cache-Eintrag.

Wichtig ist eine bewusste Trennung zwischen Pfad-basierten Parametern und Query-String-Parametern. Pfad-Parameter werden von den meisten CDN- und Reverse-Proxy-Caches zuverlässiger als Cache-Key behandelt, weil Query-Strings historisch oft ignoriert oder inkonsistent normalisiert wurden. Tools wie imgproxy und Thumbor setzen deshalb auf verschlüsselte oder signierte Pfad-Segmente statt auf offene Query-Parameter, was zusätzlich das Manipulationsrisiko reduziert, weil beliebige Parameterkombinationen nicht mehr frei erraten werden können.

Die Parameter-Grammatik sollte klein und stabil bleiben: Breite, Höhe, Crop-Modus, Qualität, Format und gegebenenfalls ein Blur- oder Sharpen-Wert reichen für die meisten E-Commerce-Anwendungsfälle aus. Jeder zusätzliche Parameter vervielfacht potenziell die Anzahl unterschiedlicher Cache-Varianten und damit den Speicherbedarf am Edge, weshalb Teams die Parameter-Kombinationen aktiv begrenzen sollten, statt jede denkbare Option freizugeben.

# nginx: URL-Pfad-Parameter an imgproxy weiterleiten, Origin-Bucket als Quelle
location ~ ^/img/(?<params>.+)/(?<source_path>.+)$ {
    # imgproxy erwartet base64-kodierten oder signierten Pfad
    proxy_pass http://imgproxy:8080/insecure/$params/plain/local:///$source_path;

    # Edge-Cache: 1 Jahr fuer transformierte Varianten, da Cache-Key deterministisch ist
    proxy_cache image_cache;
    proxy_cache_valid 200 365d;
    proxy_cache_key "$scheme$request_uri";
    proxy_cache_use_stale error timeout updating http_500 http_502 http_503;

    add_header X-Cache-Status $upstream_cache_status always;
    add_header Cache-Control "public, max-age=31536000, immutable" always;
}

# Beispiel-Request:
# GET /img/w:800/h:600/q:80/f:webp/catalog/product/s/a/sample.jpg

3. Image CDN vs. Self-hosted Pipeline: die Abwägung

Ein gehosteter Image CDN-Dienst wie Cloudflare Images, Cloudinary oder imgix übernimmt Transformation, Caching und globale Auslieferung als vollständig verwalteten Service. Der Vorteil liegt in der Betriebssicherheit: kein eigener Server, keine Skalierungssorgen bei Traffic-Spitzen, kein Patch-Management für die Bildverarbeitungsbibliothek. Der Preis dafür ist eine laufende, meist traffic- oder request-basierte Abrechnung, die bei sehr großen Bildkatalogen mit hohem Traffic signifikant werden kann, sowie eine gewisse Abhängigkeit vom Funktionsumfang und der Roadmap des Anbieters.

Eine selbstgehostete Pipeline mit imgproxy oder Thumbor hinter einem eigenen CDN wie Cloudflare oder Fastly gibt volle Kontrolle über Parameter-Grammatik, Caching-Verhalten und Kostenstruktur zurück. Die Grenzkosten pro zusätzlicher Transformation sind nahe null, sobald die Infrastruktur steht, weil nur noch Rechenzeit und Bandbreite anfallen, keine Lizenzgebühren pro Bild. Der Preis dafür ist operative Verantwortung: Skalierung des Transformationsdienstes bei Lastspitzen, Monitoring, Sicherheitsupdates und die Notwendigkeit, ein eigenes CDN oder einen Reverse-Proxy-Cache davor zu betreiben, damit die Transformation nicht bei jedem Request neu läuft.

Die praxistaugliche Faustregel: Für Shops mit überschaubarem Katalog und begrenztem Entwicklungsteam ist ein verwalteter Image CDN die schnellere und risikoärmere Wahl. Für Agenturen und größere Betreiber mit mehreren Mandanten auf gemeinsamer Infrastruktur amortisiert sich eine selbstgehostete Lösung oft innerhalb weniger Monate, weil die Fixkosten der Infrastruktur über viele Shops verteilt werden, während die Kosten eines verwalteten Dienstes linear mit jedem zusätzlichen Mandanten mitwachsen.

4. Caching-Strategie für transformierte Varianten

Der Cache für transformierte Bildvarianten braucht eine klare Schichtung. Die erste Schicht ist der Browser-Cache über einen langen max-age-Wert mit immutable, da eine einmal erzeugte URL für dieselben Parameter niemals ihren Inhalt ändert. Die zweite Schicht ist ein Edge- oder CDN-Cache, der Transformationsergebnisse geografisch nah am Nutzer vorhält und die Origin-Last massiv reduziert. Die dritte, oft übersehene Schicht ist ein lokaler Ergebnis-Cache direkt am Transformationsdienst, der wiederholte Transformationen für dieselbe Parameterkombination vermeidet, selbst wenn der Edge-Cache-Eintrag zwischenzeitlich verdrängt wurde.

Die Invalidierung ist der kritische Teil dieser Architektur, weil Bild-URLs als Cache-Key fungieren. Wird ein Produktbild in Magento ausgetauscht, ändert sich der Dateiname am Origin in der Regel nicht automatisch, wodurch alte, bereits gecachte Varianten stehen bleiben können. Die robuste Lösung ist, den Dateinamen oder einen Content-Hash-Suffix bei jedem Bildaustausch zu ändern, sodass eine neue URL entsteht und alte Cache-Einträge einfach auslaufen, statt aktiv invalidiert werden zu müssen. Aktive Invalidierung per API-Call an den CDN-Anbieter ist die Fallback-Option für Fälle, in denen sich der Dateiname nicht ändern lässt.

Für die Storage-Seite des Ergebnis-Caches lohnt sich ein Least-Recently-Used-Verdrängungsmodell mit einem Objekt-Storage-Backend wie S3-kompatiblem Storage, statt lokalem Festplattenspeicher auf dem Transformationsserver. Das entkoppelt die Cache-Kapazität von der Server-Instanz und erlaubt horizontale Skalierung mehrerer Transformationsserver, die sich denselben Ergebnis-Cache teilen, ohne dass jede Instanz ihre eigene, inkonsistente Kopie vorhält.

{
  "cache_layers": [
    {
      "layer": "browser",
      "header": "Cache-Control",
      "value": "public, max-age=31536000, immutable",
      "note": "URL aendert sich nie fuer identische Parameter"
    },
    {
      "layer": "edge_cdn",
      "ttl_seconds": 31536000,
      "purge_strategy": "content-hash-in-filename",
      "note": "Neuer Dateiname bei Bildaustausch statt aktiver Purge"
    },
    {
      "layer": "transform_service_cache",
      "backend": "s3-compatible-object-storage",
      "eviction": "lru",
      "max_size_gb": 200,
      "note": "Entkoppelt von einzelner Server-Instanz, horizontal skalierbar"
    }
  ]
}

5. Format-Negotiation: WebP und AVIF automatisch ausliefern

Moderne Bildformate wie WebP und AVIF reduzieren die Dateigröße gegenüber JPEG um 25 bis 50 Prozent bei vergleichbarer wahrgenommener Qualität, werden aber nicht von jedem Client unterstützt. Zwei Mechanismen lösen dieses Problem zuverlässig: Der Accept-Header, den der Browser bei jedem Bild-Request mitsendet und der die unterstützten Formate in Präferenzreihenfolge auflistet, sowie ein expliziter Format-Parameter in der URL, der clientseitig über das <picture>-Element mit mehreren <source>-Kandidaten gesteuert wird.

Die Accept-Header-Variante ist eleganter, weil sie keine Änderung im HTML erfordert und automatisch mit dem Client mitwächst: Der Transformationsdienst inspiziert Accept: image/avif,image/webp,image/*,*/* und wählt selbstständig das beste unterstützte Format. Der Nachteil ist, dass der Edge-Cache dann pro Accept-Header-Variante einen eigenen Cache-Eintrag benötigt, gesteuert über einen Vary: Accept-Response-Header. Ohne diesen Header liefert der Cache im schlimmsten Fall ein AVIF-Bild an einen Client aus, der es nicht anzeigen kann, weil die erste Antwort für eine URL für alle nachfolgenden Requests zwischengespeichert wurde.

Die robustere Variante für produktive Magento-Shops kombiniert beides: das <picture>-Element mit explizitem type-Attribut pro <source> gibt dem Browser die Entscheidung, welches Format er lädt, während die URL selbst das Zielformat explizit im Pfad trägt. Das vermeidet die Vary-Header-Komplexität vollständig und macht jede Format-Variante zu einer eigenen, eindeutig cachbaren URL, ohne auf Content-Negotiation im HTTP-Layer angewiesen zu sein.

<!-- Hyvä phtml: explizite Format-Varianten statt Accept-Header-Vary -->
<picture>
    <source
        type="image/avif"
        srcset="{{$block->getImageCdnUrl($image, ['w' => 800, 'f' => 'avif'])}} 1x,
                {{$block->getImageCdnUrl($image, ['w' => 1600, 'f' => 'avif'])}} 2x">
    <source
        type="image/webp"
        srcset="{{$block->getImageCdnUrl($image, ['w' => 800, 'f' => 'webp'])}} 1x,
                {{$block->getImageCdnUrl($image, ['w' => 1600, 'f' => 'webp'])}} 2x">
    <img
        src="{{$block->getImageCdnUrl($image, ['w' => 800, 'f' => 'jpg'])}}"
        width="800"
        height="600"
        loading="lazy"
        decoding="async"
        alt="{{$block->escapeHtmlAttr($image->getLabel())}}"
        class="w-full h-auto object-cover">
</picture>

6. Responsive Images und srcset-Generierung

Ein einzelnes Quellbild reicht nicht aus, sobald Viewports von 320 bis 3840 Pixel Breite bedient werden müssen. Das srcset-Attribut mit Breiten-Deskriptoren erlaubt dem Browser, unter mehreren angebotenen Größen die für das aktuelle Viewport und die Pixeldichte passende auszuwählen, statt immer die größte Variante zu laden. Für eine Image-CDN-Architektur bedeutet das, eine begrenzte, aber ausreichend granulare Breiten-Stufenliste zu definieren, etwa 320, 480, 768, 1024, 1440 und 1920 Pixel, statt für jede beliebige Pixelbreite eine eigene Variante zu erzeugen.

Diese Stufenliste ist ein bewusster Kompromiss zwischen Cache-Effizienz und Bild-Präzision. Zu wenige Stufen bedeuten, dass kleine Viewports größere Bilder als nötig laden. Zu viele Stufen vervielfachen die Zahl der Cache-Einträge, ohne spürbaren Qualitätsgewinn, weil der Unterschied zwischen 780 und 800 Pixel Breite visuell nicht wahrnehmbar ist. Ein ViewModel, das die srcset-Liste zentral aus einer Konfigurationsklasse erzeugt, verhindert, dass unterschiedliche Templates unterschiedliche, inkonsistente Breiten-Stufen verwenden.

Für das sizes-Attribut gilt dieselbe Sorgfaltspflicht: Es muss dem tatsächlichen Rendering-Verhalten des Layouts entsprechen, sonst wählt der Browser eine falsch dimensionierte Variante aus dem srcset. Ein Produktbild, das in der Grid-Ansicht ein Drittel der Viewport-Breite einnimmt, aber in der Detailansicht die volle Breite, braucht unterschiedliche sizes-Werte pro Template, nicht einen global gültigen Wert.

<?php

declare(strict_types=1);

namespace Mironsoft\ImageCdn\ViewModel;

use Magento\Framework\View\Element\Block\ArgumentInterface;

/**
 * ViewModel zur Erzeugung von Image-CDN-Transformations-URLs fuer die Media Gallery.
 */
final class ImageCdnUrlBuilder implements ArgumentInterface
{
    /** @var int[] Feste Breiten-Stufenliste fuer srcset-Generierung */
    private const WIDTH_STEPS = [320, 480, 768, 1024, 1440, 1920];

    /**
     * @param string $cdnBaseUrl Basis-URL des Image-CDN-Dienstes
     */
    public function __construct(
        private readonly string $cdnBaseUrl
    ) {
    }

    /**
     * Baut eine srcset-Zeichenkette mit allen konfigurierten Breiten-Stufen.
     *
     * @param string $relativeImagePath Relativer Pfad im Media-Storage
     * @param string $format Zielformat, z. B. webp oder avif
     * @param int $quality Zielqualitaet zwischen 1 und 100
     * @return string Vollstaendiger srcset-Wert fuer das img/source-Element
     */
    public function buildSrcset(string $relativeImagePath, string $format, int $quality = 80): string
    {
        $entries = [];
        foreach (self::WIDTH_STEPS as $width) {
            $url = $this->buildUrl($relativeImagePath, $width, $format, $quality);
            $entries[] = sprintf('%s %dw', $url, $width);
        }

        return implode(', ', $entries);
    }

    /**
     * Baut eine einzelne Transformations-URL fuer ein Bild.
     *
     * @param string $relativeImagePath Relativer Pfad im Media-Storage
     * @param int $width Zielbreite in Pixel
     * @param string $format Zielformat
     * @param int $quality Zielqualitaet zwischen 1 und 100
     * @return string Vollstaendige Transformations-URL
     */
    public function buildUrl(string $relativeImagePath, int $width, string $format, int $quality = 80): string
    {
        $path = ltrim($relativeImagePath, '/');

        return sprintf(
            '%s/w:%d/q:%d/f:%s/%s',
            rtrim($this->cdnBaseUrl, '/'),
            $width,
            $quality,
            $format,
            $path
        );
    }
}

7. Integration mit Magentos Media Gallery

Magentos Media Gallery speichert Produktbilder unter pub/media/catalog/product mit einer zusätzlichen Hash-basierten Verzeichnisstruktur zur Kollisionsvermeidung. Für eine Image-CDN-Anbindung gibt es zwei grundsätzliche Integrationswege: Entweder zeigt das CDN direkt auf diesen Origin-Pfad und übernimmt die Transformation live, oder ein Sync-Prozess spiegelt die Bilder in einen separaten Object-Storage-Bucket, den das CDN als Quelle verwendet. Der direkte Weg ist einfacher aufzusetzen, koppelt aber die Verfügbarkeit des Bildservice an die Verfügbarkeit des Magento-Webservers.

In der Praxis hat sich ein ViewModel-basierter Ansatz bewährt, der die Standard-Magento-Bild-Helper wie Magento\Catalog\Helper\Image nicht ersetzt, sondern um eine CDN-URL-Generierung ergänzt. Statt $imageHelper->getUrl() direkt im Template aufzurufen, liefert das ViewModel eine CDN-Variante derselben relativen Bildpfad-Information. Das hält die Migration reversibel: Fällt der Image-CDN-Dienst aus, kann ein Feature-Flag im ViewModel zurück auf die klassischen, von Magento vorab generierten Cache-Bilder unter pub/media/catalog/product/cache umschalten, ohne Template-Änderungen.

Für CMS-Blöcke und den Page Builder ist die Herausforderung größer, weil Redakteure Bilder frei über den WYSIWYG-Editor einfügen und die generierte URL nicht zwangsläufig durch das ViewModel läuft. Hier lohnt sich ein Nachbearbeitungsschritt im Rendering-Pipeline, der <img>-Tags im gerenderten HTML per regulärem Ausdruck oder DOM-Parser erkennt und deren src-Attribut nachträglich auf die CDN-Transformations-URL umschreibt, bevor die Seite an den Full-Page-Cache übergeben wird.

<!-- di.xml: ViewModel fuer Image-CDN-URLs im Produktbild-Block registrieren -->
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:framework:ObjectManager/etc/config.xsd">
    <type name="Mironsoft\ImageCdn\ViewModel\ImageCdnUrlBuilder">
        <arguments>
            <!-- CDN-Basis-URL aus system.xml, umschaltbar ohne Deploy -->
            <argument name="cdnBaseUrl" xsi:type="string">https://img.mironsoft.de</argument>
        </arguments>
    </type>
</config>

<!-- layout xml: ViewModel dem Produktbild-Block zuweisen -->
<referenceBlock name="product.image">
    <arguments>
        <argument name="viewModelImageCdn" xsi:type="object">
            Mironsoft\ImageCdn\ViewModel\ImageCdnUrlBuilder
        </argument>
    </arguments>
</referenceBlock>

8. Origin-Schutz, Signed URLs und Kosten-Performance-Abwägung

Eine offene, unbeschränkte URL-Parameter-Grammatik ist ein Einfallstor für Missbrauch: Ein Angreifer kann tausende beliebige Größen- und Qualitätskombinationen anfragen und damit gezielt Cache-Misses erzwingen, die den Transformationsdienst und die Origin-Bandbreite überlasten, ein Muster, das als Image-Scraping-Denial-of-Service bekannt ist. Zwei Schutzmechanismen greifen ineinander: Parameter-Allowlisting begrenzt zulässige Werte auf eine feste Liste von Breiten, Formaten und Qualitätsstufen, und signierte URLs mit einem HMAC-Hash über die Parameter verhindern, dass beliebige Kombinationen ohne gültige Signatur überhaupt verarbeitet werden.

Die Signatur wird serverseitig beim Erzeugen der URL berechnet, typischerweise mit einem geheimen Schlüssel, der nur dem Magento-Backend und dem Transformationsdienst bekannt ist. Requests ohne gültige oder mit manipulierter Signatur werden mit einem 403-Status abgewiesen, bevor überhaupt eine Transformation ausgeführt wird. Das verhindert nicht nur Denial-of-Service-Versuche, sondern auch Hotlinking von Drittseiten, die versuchen, den eigenen Image-CDN-Traffic für fremde Inhalte zu missbrauchen.

Bei der Kosten-Performance-Abwägung zählt neben der reinen Rechenzeit auch die Bandbreite: Ein zu aggressiv gewähltes Qualitätsniveau spart Rechenzeit, erhöht aber die ausgelieferte Datenmenge und damit CDN-Traffic-Kosten. Umgekehrt kostet eine sehr niedrige Qualitätsstufe mehr Rechenzeit für aggressivere Kompression, senkt aber laufende Bandbreitenkosten. Die praxistaugliche Grundeinstellung liegt bei Qualität 75 bis 82 für JPEG/WebP und 50 bis 60 für AVIF, da AVIF bei niedrigeren Qualitätswerten bereits vergleichbare visuelle Ergebnisse wie JPEG bei deutlich höheren Werten liefert.

<?php

declare(strict_types=1);

namespace Mironsoft\ImageCdn\Service;

/**
 * Erzeugt HMAC-signierte Image-CDN-URLs, um Parameter-Manipulation
 * und unkontrollierte Transformationslast am Origin zu verhindern.
 */
final class SignedUrlGenerator
{
    /**
     * @param string $signingSecret Geheimer Schluessel, nur Backend und CDN bekannt
     * @param string $cdnBaseUrl Basis-URL des Image-CDN-Dienstes
     */
    public function __construct(
        private readonly string $signingSecret,
        private readonly string $cdnBaseUrl
    ) {
    }

    /**
     * Erstellt eine signierte Transformations-URL fuer ein Bild.
     *
     * @param string $path Relativer Bildpfad im Origin-Storage
     * @param array<string, int|string> $params Erlaubte Transformationsparameter
     * @return string Vollstaendige, signierte CDN-URL
     */
    public function generate(string $path, array $params): string
    {
        $paramString = $this->buildParamString($params);
        $signature = hash_hmac('sha256', $paramString . $path, $this->signingSecret);

        return sprintf(
            '%s/%s/%s/%s',
            rtrim($this->cdnBaseUrl, '/'),
            substr($signature, 0, 16),
            $paramString,
            ltrim($path, '/')
        );
    }

    /**
     * Wandelt ein Allowlist-gefiltertes Parameter-Array in einen Pfad-Fragment-String um.
     *
     * @param array<string, int|string> $params Zu kodierende Parameter
     * @return string URL-Pfad-Fragment, z. B. w:800/q:80/f:webp
     */
    private function buildParamString(array $params): string
    {
        $allowedKeys = ['w', 'h', 'q', 'f'];
        $fragments = [];

        foreach ($allowedKeys as $key) {
            if (isset($params[$key])) {
                $fragments[] = sprintf('%s:%s', $key, $params[$key]);
            }
        }

        return implode('/', $fragments);
    }
}

9. Monitoring und Rollout-Strategie

Ein Image-CDN-Rollout sollte niemals als harter Cutover für den gesamten Katalog erfolgen. Der robuste Weg ist ein schrittweiser Rollout über einen Feature-Flag pro Seitentyp: zuerst Kategorieseiten mit geringem Risiko, dann Produktdetailseiten, zuletzt CMS-Inhalte mit Redakteurs-generierten Bildern. Jede Stufe läuft parallel mit der bestehenden Lösung, sodass ein Rollback per Konfigurationsänderung möglich ist, ohne Deploy und ohne Template-Änderung.

Für das laufende Monitoring sind drei Kennzahlen entscheidend: die Cache-Hit-Rate am Edge, die p95-Latenz der Transformation bei Cache-Miss und die Fehlerrate des Transformationsdienstes. Eine sinkende Cache-Hit-Rate deutet häufig auf eine zu granulare Parameter-Grammatik oder auf Crawler-Traffic mit ungewöhnlichen Breiten-Anfragen hin. Eine steigende p95-Latenz bei Cache-Miss signalisiert, dass der Transformationsdienst unterdimensioniert ist oder dass besonders große Quellbilder ohne vorherige Downscale-Stufe verarbeitet werden.

Zusätzlich lohnt sich ein synthetischer Alert, der stichprobenartig prüft, ob transformierte Bilder tatsächlich kleiner als das Original sind und ob das ausgelieferte Format dem angeforderten entspricht. Ein stiller Konfigurationsfehler, der etwa AVIF-Requests unbemerkt auf unkomprimiertes PNG zurückfallen lässt, bleibt sonst oft wochenlang unentdeckt, weil die Seite optisch korrekt aussieht, nur eben deutlich schwerer als beabsichtigt ist.

Beide Modelle lassen sich auch hybrid kombinieren: ein verwalteter Image CDN als schnelle Einstiegslösung, mit späterer Migration zu einer self-hosted Pipeline, sobald Traffic-Volumen und Mandantenzahl die Fixkosten der eigenen Infrastruktur rechtfertigen. Die URL-Parameter-Grammatik aus Abschnitt 2 bleibt dabei idealerweise identisch, sodass die Migration ausschließlich im Backend stattfindet und Templates unverändert bleiben.

10. Zusammenfassung

Eine Image-CDN-Architektur für automatische Optimierung ersetzt vorab generierte Bildvarianten durch On-the-fly-Transformation per URL-Parameter, gefolgt von mehrschichtigem Caching. Der Cache-Key entsteht deterministisch aus Breite, Qualität und Format, wodurch identische Anfragen zuverlässig denselben, wiederverwendbaren Eintrag treffen. Format-Negotiation über explizite <picture>-Source-Elemente vermeidet Vary-Header-Komplexität, während signierte URLs mit Parameter-Allowlisting den Origin vor unkontrollierter Transformationslast schützen.

Die Wahl zwischen verwaltetem Image CDN und self-hosted Pipeline ist keine einmalige Entscheidung, sondern hängt von Traffic-Volumen, Mandantenzahl und verfügbarer DevOps-Kapazität ab, und lässt sich bei gleichbleibender URL-Grammatik später migrieren. Ein ViewModel-basierter Integrationsansatz hält die Magento-Templates unabhängig vom konkreten CDN-Anbieter und ermöglicht einen schrittweisen, jederzeit reversiblen Rollout über Feature-Flags pro Seitentyp.

11. FAQ: Image-CDN-Architektur für automatische Optimierung