CDN-Caching-Grundlagen für schnellere Auslieferung

1. Warum CDN-Caching für Magento-Shops den Unterschied macht

Die Physik einer Netzwerkverbindung lässt sich nicht wegoptimieren: Ein Request von Sydney zu einem Origin-Server in Frankfurt braucht allein durch die Lichtlaufzeit im Glasfaserkabel rund 140 Millisekunden pro Weg, also etwa 280 Millisekunden Round-Trip-Time, bevor der Server überhaupt mit der Verarbeitung beginnt. Ein CDN (Content Delivery Network) platziert Kopien der Inhalte auf Servern in geografischer Nähe zum Besucher, den sogenannten Points of Presence (PoPs). Derselbe Request landet dann bei einem PoP in Sydney selbst und braucht statt 280 Millisekunden oft nur 10 bis 20 Millisekunden Round-Trip-Time.

Für einen Magento-Shop mit internationaler Kundschaft ist das kein Nice-to-have, sondern der größte einzelne Hebel für Time to First Byte (TTFB) bei entfernten Besuchern. Ein gut konfiguriertes CDN erreicht für statische Assets typischerweise eine Cache-Hit-Rate von 90 % oder mehr, wodurch der überwiegende Teil aller Requests den Origin-Server nie erreicht. Das reduziert nicht nur Latenz, sondern auch die tatsächliche Serverlast und damit die Anzahl der Application-Server-Instanzen, die für dieselbe Besucherzahl nötig sind.

2. Wie Edge-Caching funktioniert: PoPs, Cache Hit und Miss

Ein CDN besteht aus einem weltweit verteilten Netzwerk von PoPs, die über Anycast-DNS erreicht werden: Dieselbe IP-Adresse wird von vielen Standorten gleichzeitig announced, und das Netzwerk-Routing liefert jeden Request automatisch an den topologisch nächsten PoP aus, ganz ohne GeoDNS-Logik auf Applikationsebene. Trifft ein Request an einem PoP ein, prüft dieser zuerst seinen lokalen Cache-Speicher, meist eine Kombination aus RAM für heiße Objekte und SSD für den restlichen Working Set.

Findet der PoP eine gültige, nicht abgelaufene Kopie, liefert er sie direkt aus dem Edge-Speicher aus: das ist ein Cache Hit. Fehlt die Kopie oder ist sie abgelaufen, spricht man von einem Cache Miss: Der PoP muss die Antwort erst vom Origin-Server (oder einem vorgeschalteten Origin Shield) holen, im Edge-Speicher ablegen und dann ausliefern. Response-Header wie X-Cache: HIT oder Age machen dieses Verhalten pro Request nachvollziehbar und sind der erste Debugging-Schritt bei jeder CDN-Analyse.

# Cache-Verhalten eines CDN-Edge-Servers per Header pruefen
curl -sI https://www.example-shop.de/media/catalog/product/hero.webp

# Typische Antwort bei einem Cache Hit am Edge:
# HTTP/2 200
# cache-control: public, max-age=31536000, immutable
# x-cache: HIT
# x-cache-hits: 42
# age: 18734
# via: 1.1 varnish, 1.1 fastly-edge

# Bei einem Cache Miss (erster Request nach TTL-Ablauf):
# x-cache: MISS
# age: 0

3. Origin Shield: den Ursprungsserver vor Lastspitzen schützen

Ein Problem tritt auf, sobald ein populäres Objekt gleichzeitig an hunderten PoPs abläuft: Ohne Schutzmechanismus schickt jeder PoP unabhängig voneinander eine Anfrage an den Origin-Server, ein Effekt bekannt als Cache Stampede oder Thundering Herd. Bei einem CDN mit 100 oder mehr weltweiten PoPs kann das kurzzeitig hundert gleichzeitige Origin-Requests für dieselbe Ressource bedeuten, obwohl eine einzige Antwort genügt hätte.

Ein Origin Shield löst dieses Problem, indem ein einzelner, meist origin-naher PoP als verpflichtende Zwischenstation für alle Cache Misses fungiert. Statt dass jeder Edge-PoP direkt zum Origin verbindet, laufen alle Anfragen zuerst durch den Shield-PoP, der selbst einen Cache führt und Request Collapsing betreibt: Mehrere gleichzeitig eintreffende identische Anfragen werden zu einer einzigen Origin-Anfrage zusammengeführt, deren Antwort dann an alle wartenden Clients verteilt wird. In der Praxis reduziert ein korrekt konfigurierter Origin Shield die tatsächliche Origin-Last um 90 % oder mehr gegenüber einem Setup ohne Shield.

4. Cache-Key-Konfiguration: Query-Strings, Header und Cookies

Der Cache-Key ist die eindeutige Kennung, unter der ein CDN eine Antwort im Edge-Speicher ablegt und wiederfindet. Standardmäßig besteht er aus Host und URL-Pfad, doch Query-Strings, bestimmte Request-Header und Cookies können ihn erweitern oder verfälschen. Werden Marketing-Parameter wie utm_source oder gclid ungefiltert in den Cache-Key übernommen, entsteht für dieselbe Produktseite eine eigene Cache-Kopie pro Kampagnen-Link, was die effektive Cache-Hit-Rate drastisch senkt, weil praktisch jede URL-Variante als eigenes Objekt behandelt wird.

Noch kritischer ist die Behandlung von Cookies: Landet das Magento-Session-Cookie oder ein Formkey-Cookie im Cache-Key, erzeugt jede Sitzung faktisch eine eigene, nie wiederverwendbare Cache-Kopie, und die Hit-Rate fällt gegen null. Der Vary-Header steuert zusätzlich, welche Request-Header den Cache-Key beeinflussen; Vary: Accept-Encoding ist meist sinnvoll, ein unbedachtes Vary: User-Agent mit tausenden Browser-Varianten zerschlägt den Cache dagegen in unzählige Fragmente. Die Regel lautet: Query-Strings whitelisten statt blacklisten, und Cookies grundsätzlich aus dem Cache-Key statischer und halbstatischer Inhalte ausschließen.

{
  "cache_key_config": {
    "include_query_params": ["color", "size", "p"],
    "strip_query_params": ["utm_source", "utm_medium", "utm_campaign", "gclid", "fbclid"],
    "vary_headers": ["Accept-Encoding", "Accept"],
    "exclude_cookies_from_key": true,
    "normalize_url": {
      "lowercase_path": true,
      "sort_query_params": true,
      "remove_trailing_slash": true
    }
  }
}

5. Instant Purge und API-basierte Invalidierung

Ändert sich in Magento ein Preis, der Lagerbestand oder der Inhalt einer CMS-Seite, muss die veraltete Kopie am Edge entfernt werden, bevor die TTL natürlich abläuft. Moderne CDNs lösen das über Cache-Tags beziehungsweise Surrogate Keys: Jede Antwort wird beim Ausliefern mit einem oder mehreren Tags markiert, etwa der Produkt-ID oder Kategorie-ID. Ändert sich ein Produkt, sendet das Backend einen Purge-Request für genau dieses Tag, und das CDN entfernt weltweit alle Objekte mit diesem Tag, unabhängig von deren URL.

Tag-basierte Instant-Purges propagieren bei den meisten großen CDN-Anbietern in unter 150 Millisekunden global, während einzelne URL-Purges ohne Tag-System oft mehrere Sekunden bis Minuten benötigen, weil jede betroffene URL einzeln adressiert werden muss. Magentos Full Page Cache lässt sich über einen Event-Observer bei catalog_product_save_after oder ähnlichen Events an eine solche Purge-API anbinden, sodass Preisänderungen im Admin-Panel die Edge-Kopie in Echtzeit invalidieren, statt Minuten oder Stunden auf den TTL-Ablauf zu warten.

# Tag-basierten Instant Purge nach einer Produktaenderung ausloesen
curl -X POST "https://api.cdn-provider.example/purge/tag" \
  -H "Authorization: Bearer $CDN_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"tags": ["product-1234", "category-55"]}'

# Antwort bestaetigt die globale Propagation
# {"status":"ok","purge_id":"c9f2a1","propagated_pops":184}

6. TTL-basiertes Expiry und Stale-While-Revalidate

Neben dem expliziten Purge bleibt die klassische Time to Live (TTL) die Grundlage jeder Cache-Strategie: Eine kurze TTL von wenigen Minuten hält Inhalte frisch, erhöht aber die Origin-Last durch häufigere Revalidierungen; eine lange TTL von Tagen oder Wochen senkt die Origin-Last drastisch, riskiert dafür veraltete Inhalte zwischen Purges. Die Kunst liegt darin, TTL pro Content-Typ statt global zu setzen.

Stale-While-Revalidate löst den klassischen Zielkonflikt eleganter: Läuft die reguläre TTL ab, liefert der Edge-Server die abgelaufene, aber noch als "akzeptabel stale" markierte Kopie sofort an den Nutzer aus und stößt im Hintergrund asynchron eine Revalidierung beim Origin an. Der Nutzer bemerkt keine zusätzliche Latenz, während der Cache innerhalb von Millisekunden aktualisiert wird. Stale-If-Error ergänzt das um Resilienz: Ist der Origin-Server während der Revalidierung nicht erreichbar, liefert der Edge weiterhin die letzte bekannte gute Kopie aus, statt einen Fehler zu zeigen, typischerweise für einige Stunden bis Tage konfiguriert.

7. Statische vs. dynamische Inhalte: CDN-Strategie für Magento

Statische Assets wie CSS-, JavaScript- und Font-Dateien unter pub/static sind nach dem setup:static-content:deploy-Lauf inhaltsadressiert versioniert: Ändert sich der Inhalt, ändert sich der Dateiname über einen Hash. Solche Dateien können mit Cache-Control: public, max-age=31536000, immutable ein Jahr lang am Edge liegen bleiben, ganz ohne Purge-Bedarf, weil eine neue Version automatisch eine neue URL erhält. Für Produktbilder unter pub/media gilt dasselbe Prinzip mit etwas kürzerer TTL, da Bilder gelegentlich unter derselben URL ausgetauscht werden.

HTML-Seiten wie Kategorie- und Produktseiten sind halbstatisch: Sie ändern sich selten, aber unvorhersehbar, etwa bei Preisänderungen. Hier ist die Kombination aus Magentos Full Page Cache und CDN mit mittlerer TTL (15 bis 60 Minuten) plus tag-basiertem Instant-Purge der richtige Ansatz. Echte dynamische Endpunkte wie Warenkorb, Checkout und Kundenkonto dürfen dagegen niemals über das CDN gecacht werden: Cache-Control: private, no-store stellt sicher, dass personalisierte Inhalte immer frisch vom Origin kommen, während Fragmente wie der Warenkorb-Zähler per AJAX oder ESI in ansonsten gecachtes HTML nachgeladen werden.

<!-- config.xml: Default-Werte fuer CDN-Basis-URLs statischer und medialer Inhalte -->
<config>
    <default>
        <web>
            <unsecure>
                <base_static_url>https://cdn.example-shop.de/static/</base_static_url>
                <base_media_url>https://cdn.example-shop.de/media/</base_media_url>
            </unsecure>
            <secure>
                <base_static_url>https://cdn.example-shop.de/static/</base_static_url>
                <base_media_url>https://cdn.example-shop.de/media/</base_media_url>
            </secure>
        </web>
    </default>
</config>

8. Bildoptimierung und Transformation am Edge

Viele CDNs führen Bildtransformationen direkt am Edge durch, statt vorgerenderte Varianten aus dem Origin auszuliefern. Anhand des Accept-Headers erkennt der Edge-Server, ob ein Browser AVIF oder WebP unterstützt, und liefert automatisch das kleinste passende Format aus, AVIF spart gegenüber JPEG bei vergleichbarer Wahrnehmungsqualität häufig 40 bis 50 % an Dateigröße. Über Query-Parameter oder Client-Hints wie Sec-CH-Width lässt sich zusätzlich die Zielbreite pro Gerät bestimmen, sodass ein Smartphone kein für Desktop skaliertes Originalbild herunterladen muss.

Der erste Request für eine bestimmte Format-Größen-Kombination löst die Transformation aus und kostet dadurch etwas mehr Zeit; jede weitere Anfrage nach derselben Variante trifft danach einen regulären Cache Hit und wird ohne erneute Verarbeitung ausgeliefert. Diese Rechenlast wandert damit vollständig vom Origin-Server, der potenziell tausende Bildvarianten pro Produkt generieren müsste, zum CDN-Edge, der sie bedarfsgerecht und nur einmal pro Variante erzeugt.

// Edge-Funktion: Format und Breite anhand von Accept-Header und Client-Hints waehlen
export async function onRequest(request) {
  const accept = request.headers.get('Accept') || '';
  const width = request.headers.get('Sec-CH-Width') || '800';

  let format = 'jpeg';
  if (accept.includes('image/avif')) {
    format = 'avif';
  } else if (accept.includes('image/webp')) {
    format = 'webp';
  }

  const originUrl = new URL(request.url);
  originUrl.searchParams.set('format', format);
  originUrl.searchParams.set('width', width);

  // Edge-Cache-Key enthaelt Format und Breite, damit Varianten getrennt gecacht werden
  return fetch(originUrl.toString(), {
    cf: { cacheKey: `${originUrl.pathname}-${format}-${width}` }
  });
}

9. CDN-Auswahl für E-Commerce: Abdeckung, Bilder, Bot-Schutz

Bei der CDN-Auswahl für einen Magento-Shop zählt zuerst die geografische PoP-Abdeckung im Verhältnis zur tatsächlichen Kundschaft: Ein Anbieter mit dichtem PoP-Netz in der DACH-Region bringt wenig, wenn ein relevanter Teil der Kunden aus Nordamerika oder Asien zugreift. Zweitens spielt eingebaute Bildoptimierung eine Rolle, weil sie einen separaten Image-Processing-Dienst überflüssig machen kann. Drittens ist Bot- und DDoS-Schutz in der Praxis ein zweischneidiges Schwert: Aggressive WAF-Regeln blockieren zuverlässig volumetrische Angriffe, können aber auch legitime Preisvergleichs-Crawler, Checkout-Callbacks von Zahlungsanbietern oder Monitoring-Bots fälschlich aussperren.

Das Preismodell verdient ebenfalls Aufmerksamkeit: Manche Anbieter berechnen nach ausgeliefertem Bandbreitenvolumen, andere nach Anzahl der Requests, was sich bei bildlastigen Produktkatalogen mit hoher Cache-Hit-Rate stark unterschiedlich auswirkt. Die folgende Tabelle vergleicht typische Caching-Strategien nach Content-Typ, wie sie in einem produktiven Magento-Setup nebeneinander existieren.

In der Praxis existieren alle fünf Strategien parallel im selben Magento-Shop: Ein einheitliches "Alles cachen" oder "Nichts cachen" führt entweder zu veralteten Preisen oder zu unnötig hoher Origin-Last. Wer Content-Typen sauber trennt, TTL und Cache-Key pro Typ konfiguriert und Instant Purge gezielt für preis- und lagerkritische Inhalte einsetzt, erreicht eine Cache-Hit-Rate von 90 % oder mehr, ohne die Aktualität personalisierter Bereiche zu gefährden.

10. Zusammenfassung

CDN-Caching für Magento-Shops löst ein physikalisches Grundproblem: Die Distanz zwischen Besucher und Origin-Server lässt sich nicht wegoptimieren, wohl aber durch Edge-PoPs in unmittelbarer Nähe der Nutzer umgehen. Ein Cache Hit am Edge liefert in wenigen Millisekunden aus, während ein Cache Miss über Origin Shield und Request Collapsing die Last auf dem Ursprungsserver trotzdem kontrolliert hält. Sauber konfigurierte Cache-Keys ohne Session-Cookies und ohne ungefilterte Marketing-Parameter sind die Voraussetzung für eine Cache-Hit-Rate von 90 % oder mehr.

Purge-Strategien und TTL-Konfiguration ergänzen sich, statt sich zu ersetzen: Tag-basierter Instant Purge sorgt für sofortige Aktualität bei Preis- und Lageränderungen, während Stale-While-Revalidate zwischen den Purges für konstant niedrige Latenz sorgt, auch während der Hintergrund-Aktualisierung. Die konsequente Trennung zwischen statischen, halbstatischen und echten dynamischen Inhalten entscheidet letztlich darüber, ob ein CDN einen Magento-Shop wirklich beschleunigt oder nur eine zusätzliche Komponente ohne messbaren Effekt bleibt.

11. FAQ: CDN-Caching-Grundlagen