Ein Shop kann am Origin-Server blitzschnell antworten und für Nutzer auf einem anderen Kontinent trotzdem träge wirken. Der Grund ist Physik: Licht legt in Glasfaser nur rund 124 Meilen pro Millisekunde (Cloudflare) zurück -- etwa zwei Drittel der Vakuumgeschwindigkeit. Jede Entfernung kostet messbar Zeit, bevor das erste Byte ankommt. Genau hier setzen CDN und Edge-Caching an: Sie verlagern Kopien Ihrer Inhalte auf Server nahe am Nutzer, sodass Anfragen nicht mehr quer über den Globus zum Origin reisen müssen. Der Effekt ist direkt geschäftsrelevant. Amazon stellte fest, dass jede zusätzliche 100 Millisekunden (Amazon) Latenz rund 1 Prozent (Amazon) Umsatz kosteten, und Akamai maß, dass eine Verzögerung von 100 Millisekunden (Akamai) die Conversions um bis zu 7 Prozent (Akamai) drücken kann. Dieser Beitrag zeigt, wie Sie ein CDN, Edge-Caching und Cache-Control-Header so kombinieren, dass Ihre Core Web Vitals auch fern vom Standort stabil bleiben -- abgegrenzt vom Origin-Caching mit Varnish und Redis, das eine eigene Schicht bildet.
Warum Distanz die Time to First Byte bestimmt
Die Time to First Byte misst die Zeit von der Anfrage bis zum ersten empfangenen Byte der Antwort. Sie setzt sich aus DNS-Auflösung, Verbindungsaufbau, TLS-Handshake und der Server-Verarbeitung zusammen -- und durch jeden dieser Schritte zieht sich die Netzwerklatenz. Eine der wichtigsten Ursachen dieser Latenz ist schlicht die Distanz zwischen Nutzer und Server. Cloudflare illustriert das mit einem Beispiel: Ein in Columbus, Ohio gehosteter Server antwortet auf Anfragen aus dem rund 160 Kilometer entfernten Cincinnati in 5 bis 10 Millisekunden (Cloudflare), während Anfragen aus dem etwa 3.500 Kilometer entfernten Los Angeles eher 40 bis 50 Millisekunden (Cloudflare) brauchen -- und das nur für eine einzige Strecke.
Diese Latenz addiert sich, weil ein Verbindungsaufbau mehrere Hin- und Rückwege (Round Trips) erfordert. Bei einer transkontinentalen Verbindung summieren sich DNS, TCP-Handshake und TLS-Verhandlung schnell zu mehreren hundert Millisekunden, bevor überhaupt das erste inhaltstragende Byte fließt. Genau deshalb fühlt sich derselbe Shop in einem entfernten Markt langsamer an, obwohl die reine Server-Verarbeitung identisch ist. Eine fundierte Server-Optimierung betrachtet die TTFB daher nie nur lokal, sondern aus Sicht der real verteilten Nutzerschaft.
TTFB, Edge und Origin -- die Begriffe
Wie ein CDN den Weg zum Nutzer verkürzt
Ein Content Delivery Network ist ein global verteiltes Netz aus Edge-Servern. Statt jede Anfrage zum Origin zu leiten, liefert das CDN Inhalte vom Knoten aus, der dem Nutzer am nächsten liegt. Aus hunderten Millisekunden Round-Trip-Zeit werden so oft nur wenige -- die wahrgenommene Geschwindigkeit steigt deutlich, ohne dass der Origin stärker belastet wird. Tatsächlich ist diese Auslieferungsform längst Mainstream: Im Datensatz des Web Almanac werden 54 Prozent (Web Almanac, 2024) von über 1,3 Milliarden Requests aus einem CDN beantwortet.
Die Verbreitung folgt allerdings einem klaren Muster nach Reichweite. Während 71 Prozent (Web Almanac, 2024) der 1.000 meistbesuchten Websites ein CDN nutzen, sind es bei den größten 1 Million Sites nur 49 Prozent (Web Almanac, 2024) und bei den größten 10 Millionen lediglich 35 Prozent (Web Almanac, 2024). Gerade kleinere und mittlere Shops verschenken hier also häufig Potenzial: Die Technik, die große Anbieter selbstverständlich einsetzen, ist auch für sie zugänglich. Da rund 57 Prozent (Statista, 2024) der weltweiten E-Commerce-Umsätze auf Mobilgeräten entstehen -- oft über Mobilfunk mit höherer Grundlatenz -- wirkt die Nähe des Edge dort besonders stark.
Geografische Nähe
Edge-PoPs liefern statische Inhalte aus der Region des Nutzers. Der Round Trip zum entfernten Origin entfällt für den Großteil der Anfragen, was die TTFB unmittelbar senkt.
Origin-Entlastung
Jeder Cache-HIT am Edge ist eine Anfrage, die den Origin nicht erreicht. Das schützt den Ursprungsserver vor Lastspitzen und stabilisiert die Antwortzeiten unter hohem Andrang.
Optimierte Verbindungen
CDN-Knoten halten oft warme, wiederverwendbare Verbindungen zum Origin vor und terminieren TLS am Edge. Das verkürzt Handshakes und beschleunigt selbst dynamische Antworten.
Cache-Control: die Sprache, die der Edge versteht
Ein CDN cacht nicht beliebig, sondern folgt den Anweisungen, die Ihr Origin in den HTTP-Antwort-Headern mitsendet. Der wichtigste davon ist Cache-Control. Er legt fest, ob, wo und wie lange eine Antwort zwischengespeichert werden darf. In der Praxis ist dieser Header weit verbreitet: Laut Web Almanac nutzen 74,8 Prozent (Web Almanac, 2024) der Desktop-Requests einen Cache-Control-Header. Entscheidend ist jedoch nicht seine bloße Präsenz, sondern die richtige Direktive für den jeweiligen Ressourcentyp.
# Statisches Asset mit Hash im Dateinamen -- lange cachen, unveränderlich
Cache-Control: public, max-age=31536000, immutable
# HTML-Dokument -- am Edge cachen, aber serverseitig revalidieren
Cache-Control: public, s-maxage=600, stale-while-revalidate=60
# Personalisierte Seite -- nie am Edge ablegen
Cache-Control: private, no-storeDrei Bausteine verdienen besondere Aufmerksamkeit. s-maxage setzt die Lebensdauer ausschließlich für geteilte Caches wie das CDN und lässt sich getrennt vom Browser-Cache (max-age) steuern. immutable signalisiert, dass eine Datei sich nie ändert -- ideal für versionierte Assets. Und stale-while-revalidate erlaubt dem Edge, eine leicht veraltete Antwort sofort auszuliefern und im Hintergrund eine frische Version zu holen, sodass kein Nutzer auf die Revalidierung warten muss. Wie das Zusammenspiel mit Browser- und Applikations-Cache aussieht, vertieft unser Beitrag zu Caching-Strategien mit Varnish und Redis, der die Schichten hinter dem Edge beleuchtet.
Personalisierte Inhalte gehören nicht in den geteilten Cache
Was sich cachen lässt -- und was nicht
Nicht jede Ressource eignet sich gleich gut für den Edge. Statische Assets sind nahezu ideal: Laut Web Almanac sind 99,3 Prozent (Web Almanac, 2024) der CSS-Antworten und 95,3 Prozent (Web Almanac, 2024) der Skripte cachebar, bei Schriftarten sogar 99,8 Prozent (Web Almanac, 2024). Insgesamt gelten 90,4 Prozent (Web Almanac, 2024) aller Desktop-Antworten als cachebar. Diese Dateien ändern sich selten, lassen sich versionieren und können mit langer Lebensdauer am Edge liegen.
Beim HTML-Dokument wird es differenzierter: Nur 72,6 Prozent (Web Almanac, 2024) der HTML-Antworten sind cachebar, weil HTML häufig personalisierte oder zeitkritische Inhalte trägt. Hier hilft Edge-Caching mit kurzer s-maxage und stale-while-revalidate, oder eine Trennung in statische Rahmen und dynamisch nachgeladene Fragmente. Wer ohnehin an Bildoptimierung mit modernen Formaten arbeitet, profitiert doppelt: Kleinere Bilddateien, die am Edge liegen, reisen kurze Wege und sind klein -- zwei Hebel, die sich addieren.
Eine Grenze hat der Edge allerdings: Ressourcen, die von fremden Domains geladen werden, liegen nicht in Ihrem CDN und entziehen sich Ihrer Cache-Kontrolle. Genau das gilt für externe Skripte, deren Auslieferung der Anbieter steuert. Sie reisen weiter eigene Wege und können die Vorteile eines schnellen Edge wieder zunichtemachen. Wie sich solche Skripte gezielt reduzieren lassen, behandelt unser Beitrag zum Entschlacken von Third-Party-Scripts -- ein Hebel, der Edge-Caching sinnvoll ergänzt.
| Ressourcentyp | Edge-Eignung | Empfohlene Strategie | Typische Lebensdauer |
|---|---|---|---|
| Versionierte Assets (CSS, JS, Fonts) | Sehr hoch | public, immutable | bis zu einem Jahr |
| Bilder und Medien | Hoch | public, lange max-age | Wochen bis Monate |
| Statisches HTML | Mittel | s-maxage plus revalidate | Sekunden bis Minuten |
| Personalisierte Seiten | Keine | private, no-store | nicht am Edge |
| API mit dynamischen Daten | Gering | kurze s-maxage oder no-store | Sekunden oder gar nicht |
Cache-Invalidierung: frisch bleiben ohne Tempoverlust
Die schwierigste Frage beim Edge-Caching lautet nicht, wie man cacht, sondern wie man veraltete Inhalte wieder loswird. Liegt eine Antwort mit langer Lebensdauer am Edge, sehen Nutzer Änderungen erst, wenn die Lebensdauer abläuft -- es sei denn, der Cache wird gezielt invalidiert. Der robusteste Ansatz ist das Cache-Busting über den Dateinamen: Ändert sich eine Datei, ändert sich ihr Hash im Namen, und der Edge behandelt sie als neue Ressource. Genau deshalb dürfen versionierte Assets bedenkenlos ein Jahr lang cachen.
Für Inhalte, deren URL stabil bleibt -- etwa eine Produktseite, deren Preis sich ändert -- braucht es aktive Invalidierung. Zwei Verfahren haben sich bewährt: das gezielte Löschen einzelner Pfade (Purge) und das gruppierte Invalidieren über Cache-Tags, bei dem ein einzelnes Ereignis alle zugehörigen Seiten auf einmal entwertet. Erfahrungsgemäß (Projekterfahrung) ist eine durchdachte Tag-Strategie der Unterschied zwischen einem Cache, der entlastet, und einem, der ständig Ärger macht. Routenbasiertes Code-Splitting hilft hier zusätzlich, weil sich Änderungen auf einzelne, klar abgegrenzte Dateien begrenzen lassen.
Praxistipp: stale-while-revalidate als Sicherheitsnetz
Edge-Caching im Shop: Personalisierung sauber trennen
Im E-Commerce kollidiert der Wunsch nach Edge-Caching scheinbar mit der Realität personalisierter Inhalte: Warenkorb, Login-Status und kundengruppenspezifische Preise lassen sich nicht naiv global cachen. Der Ausweg liegt in der Trennung. Statische und halbstatische Bereiche -- Kategorieseiten, Produktbeschreibungen, Bilder, Skripte -- werden am Edge ausgeliefert, während personalisierte Fragmente per clientseitigem Aufruf oder über eine nicht gecachte Teilantwort nachgeladen werden. So profitiert der große, für alle gleiche Teil der Seite von der Edge-Nähe, ohne dass private Daten verwechselt werden.
Bei serverseitig gerenderten Shops auf Basis von Shopware CE bedeutet das, die Storefront-Auslieferung bewusst zu strukturieren: Das stabile Seitengerüst darf am Edge liegen, der personalisierte Header-Bereich mit Warenkorb wird separat geladen. Welche Hebel hier konkret greifen, vertieft unsere Seite zur Shopware-Performance. Entscheidend ist die saubere Markierung per Cache-Control und die Wahl der richtigen Vary-Header, damit der Edge für unterschiedliche Varianten -- etwa Sprache oder Komprimierung -- getrennte Einträge hält, ohne den Cache zu fragmentieren.
Edge-Caching im Shop ist keine Alles-oder-nichts-Entscheidung. Die Kunst liegt darin, den für alle identischen Teil einer Seite konsequent an den Edge zu bringen und den personalisierten Rest sauber davon zu trennen -- dann sinkt die TTFB für die meisten Bytes, ohne dass Personalisierung verloren geht.
Typische Fehler beim Edge-Caching vermeiden
Edge-Caching ist wirkungsvoll, aber fehleranfällig, wenn es schematisch eingesetzt wird. Der folgenschwerste Fehler ist die versehentliche Auslieferung personalisierter Inhalte aus einem geteilten Cache. Ebenso verbreitet sind zu kurze Lebensdauern, die die HIT-Quote drücken, sowie fehlende Invalidierung, durch die Nutzer veraltete Preise oder Bestände sehen. Geduld ist dabei nicht selbstverständlich: Eine Verzögerung von zwei Sekunden erhöhte die Absprungrate in Akamais Messungen um 103 Prozent (Akamai, 2017).
- Personalisierte Antworten konsequent mit private oder no-store kennzeichnen, nie public
- Versionierte Assets per Hash im Dateinamen mit langer max-age und immutable cachen
- s-maxage für den Edge getrennt von max-age für den Browser steuern
- stale-while-revalidate nutzen, um Cache-Stampedes beim Ablauf zu vermeiden
- Aktive Invalidierung über Purge oder Cache-Tags für stabile URLs einplanen
- Vary-Header bewusst setzen, um den Cache nicht unnötig zu fragmentieren
Ein weiterer Klassiker ist das Optimieren ohne Messung. Wer Cache-Header ändert, ohne HIT-Quote und TTFB vorher und nachher zu beobachten, arbeitet im Blindflug. Da die Wahrscheinlichkeit eines Absprungs bei einer Ladezeit von einer auf drei Sekunden um 32 Prozent (Google/SOASTA, 2017) und von einer auf fünf Sekunden um 90 Prozent (Google/SOASTA, 2017) steigt, zählt jede eingesparte Hundertstelsekunde. Eine fundierte Performance-Analyse zeigt, welche Ressourcen am Edge liegen, wie hoch die reale HIT-Quote ist und wo die TTFB je Region noch klemmt.
Messen, absichern und global schnell bleiben
Edge-Performance ist kein Dauerzustand, sondern braucht Beobachtung. Zentrale Kennzahlen sind die Cache-HIT-Quote, die TTFB getrennt nach Region und der Anteil der Anfragen, die den Origin erreichen. Sinkt die HIT-Quote, lohnt der Blick auf Lebensdauern, Vary-Header und unbeabsichtigt nicht cachebare Antworten. Aufschlussreich ist die geografische Segmentierung: Erst sie zeigt, ob Nutzer in entfernten Märkten wirklich von einem nahen PoP bedient werden oder ob Anfragen unbemerkt zum Origin durchschlagen.
Wir kombinieren synthetische Messungen aus mehreren Weltregionen mit Real User Monitoring aus echten Sitzungen. Synthetische Tests decken Regressionen schnell und reproduzierbar auf, Felddaten zeigen die tatsächliche Erfahrung auf unterschiedlichen Verbindungen. Da 53 Prozent (Google, 2018) der mobilen Besuche abgebrochen werden, wenn das Laden länger als drei Sekunden dauert, ist diese kontinuierliche Beobachtung kein Luxus. Sie ist Teil unserer Performance-Leistungen, die Origin und Edge gemeinsam betrachten.
Der Kern in einem Satz
Der Aufwand zahlt sich mehrfach aus. Eine niedrige TTFB verbessert den Largest Contentful Paint und damit die Core Web Vitals, was die organische Sichtbarkeit stärkt. Schnellere Auslieferung in entfernten Märkten senkt die Absprungrate und hebt die Conversion -- eine um 0,1 Sekunden schnellere mobile Ladezeit steigerte Retail-Conversions um 8,4 Prozent (Google/Deloitte, 2020). Und ein entlasteter Origin bleibt auch unter Lastspitzen stabil. So wird aus geografischer Nähe ein dauerhafter Geschwindigkeitsvorteil -- der Hebel, den eine spezialisierte Server-Optimierung gemeinsam mit dem Origin-Caching konsequent bedient.