HTTP-Cache und TTL: Funktionsweise, Strategien und SEO-Auswirkungen

HTTP-Caching und TTL (Time To Live) sind zwei grundlegende Konzepte der Web-Performance. Der Cache ermöglicht es, Ressourcen (Bilder, CSS, JavaScript) temporär in der Nähe des Nutzers zu speichern, damit sie bei jedem Besuch nicht erneut heruntergeladen werden müssen. Der TTL legt fest, wie lange eine Ressource in diesem Cache verbleiben darf, bevor sie als veraltet gilt. Richtig konfiguriert reduzieren diese Mechanismen die Ladezeiten erheblich, entlasten den Ursprungsserver und verbessern die Core Web Vitals — mit direktem Einfluss auf das SEO.

Was ist HTTP-Caching?

HTTP-Caching ist ein Mechanismus, der verschiedenen Komponenten der Auslieferungskette einer Webseite erlaubt, eine lokale Kopie heruntergeladener Ressourcen vorzuhalten. Wenn ein Browser eine Seite zum ersten Mal lädt, lädt er jede Ressource vom Server herunter. Wenn diese Ressourcen von HTTP-Headern begleitet werden, die angeben, dass sie gecacht werden dürfen, speichert der Browser (und/oder das CDN) eine Kopie davon. Bei nachfolgenden Besuchen wird die Ressource aus diesem lokalen Cache ausgeliefert, anstatt erneut vom Server heruntergeladen zu werden — was erheblich schneller ist.

Es gibt mehrere Cache-Ebenen in der Auslieferungskette einer Web-Ressource. Der Browser-Cache speichert Ressourcen direkt auf dem Gerät des Nutzers — auf der Festplatte oder im Arbeitsspeicher. Der CDN-Cache (auch Edge-Cache genannt) speichert Ressourcen auf Servern des Verteilungsnetzes, die geografisch nah an den Nutzern liegen. Der serverseitige Cache (Reverse-Proxy-Cache, z. B. Varnish oder Nginx) speichert Ressourcen auf Hosting-Seite, noch bevor sie das Netzwerk erreichen.

Cache-Control-Header: wie das Cache-Verhalten definiert wird

Der HTTP-Header Cache-Control ist der wichtigste Mechanismus, über den ein Server seine Caching-Anweisungen kommuniziert. Er wird mit jeder HTTP-Antwort gesendet und kann mehrere kombinierte Direktiven enthalten. Hier sind die wichtigsten:

• max-age=N: Die Ressource darf für N Sekunden gecacht werden. Beispiel: max-age=31536000 = 1 Jahr. Die am häufigsten verwendete Direktive für statische Ressourcen.
• s-maxage=N: Wie max-age, gilt jedoch nur für geteilte Caches (CDN, Reverse Proxies), nicht für den Browser-Cache. Ermöglicht unterschiedliche Richtlinien für CDN und Browser.
• no-cache: Die Ressource darf gecacht werden, aber der Cache muss vor der Auslieferung immer beim Server prüfen, ob sie noch gültig ist (via ETag oder Last-Modified).
• no-store: Die Ressource darf nirgendwo gecacht werden. Nur für sehr sensible Inhalte verwenden (persönliche Daten, Transaktionen).
• public: Die Ressource darf von jedem Cache gespeichert werden, einschließlich geteilter CDN-Caches.
• private: Die Ressource darf nur im Browser des Nutzers gecacht werden, nicht in Zwischen-Caches.
• immutable: Gibt an, dass sich die Ressource während ihrer Lebensdauer (max-age) nie ändern wird. Der Browser sendet auch nach Ablauf keine Validierungsanfrage.

Für statische Bilder in einem Online-Shop lautet die optimale Direktive in der Regel: Cache-Control: public, max-age=31536000, immutable. Diese Kombination gibt an, dass das Bild öffentlich, für ein Jahr und unveränderlich gecacht werden darf. Wenn sich das Bild ändert (neues Produktfoto), muss die URL geändert werden, um den Cache zu umgehen — eine Technik, die als "Cache Busting" durch URL-Versionierung bezeichnet wird.

TTL (Time To Live): Wie lange soll eine Ressource im Cache bleiben?

Der TTL (Time To Live) ist die Dauer, für die eine gecachte Ressource als frisch (fresh) gilt und direkt ohne Rückfrage beim Ursprungsserver ausgeliefert werden kann. Er wird in Sekunden im max-age-Header angegeben. Nach Ablauf dieser Zeit gilt die Ressource als veraltet (stale) — sie kann in bestimmten Fällen noch ausgeliefert werden, sollte aber idealerweise neu validiert werden.

Die Wahl des TTL ist ein Abwägen zwischen zwei gegensätzlichen Zielen: die Cache-Nutzung maximieren (langer TTL = weniger Serveranfragen) und sicherstellen, dass Nutzer aktuelle Inhalte erhalten (kurzer TTL = Änderungen verbreiten sich schnell). Für selten geänderte Ressourcen wie Produktbilder ist ein langer TTL (1 Jahr) optimal. Für häufig geänderte Ressourcen wie Preise oder Lagerbestände ist ein kurzer oder nullwertiger TTL notwendig.

• 1 Jahr (31.536.000 Sekunden): Produktbilder, versionierte CSS/JS, Web-Fonts — stabile Ressourcen mit URL-Versionierung
• 1 Monat (2.592.000 Sekunden): Marken- oder Kategoriebilder, die gelegentlich aktualisiert werden
• 1 Stunde bis 1 Tag: halbdynamische Inhalte, Kategorieseiten, Produktlisten
• 0 oder no-store: Warenkorbseiten, Checkout-Seiten, Daten eingeloggter Nutzer — niemals cachen

Cache-Invalidierung: wie Inhaltsänderungen verwaltet werden

Langzeitcaching wirft eine offensichtliche Frage auf: Was passiert, wenn sich Inhalte ändern? Wenn ein Bild für 1 Jahr gecacht wird, Sie es aber nach 2 Monaten ändern, werden Besucher 10 Monate lang die alte Version sehen. Hier kommen Cache-Invalidierungsstrategien ins Spiel.

Die zuverlässigste Strategie ist die URL-Versionierung (URL Versioning oder Cache Busting). Das Prinzip: Die URL der Ressource enthält einen eindeutigen Bezeichner, der sich jedes Mal ändert, wenn sich die Ressource ändert. Zum Beispiel /images/produkt-schuh-v2.webp statt /images/produkt-schuh.webp. Oder über einen Parameter: /images/produkt.jpg?v=1705234567. Wenn sich das Bild ändert, ändert sich die URL, und der Cache behandelt diese neue URL als völlig neue Ressource — ohne Probleme mit veralteten Inhalten.

Eine weitere Strategie ist die CDN-Purge-API: Moderne CDNs bieten eine API, über die bestimmte URLs oder URL-Gruppen in ihrem Cache sofort invalidiert werden können. Wenn ein Händler ein Bild in seinem Backend ändert, invalidiert ein API-Aufruf an das CDN den Cache für dieses Bild. Nachfolgende Besuche rufen die neue Version direkt vom Ursprungsserver ab, die dann erneut gecacht wird.

CDN-Cache vs. Browser-Cache: Ergänzung und Unterschiede

CDN-Cache und Browser-Cache ergänzen sich und dienen unterschiedlichen Zwecken. Der CDN-Cache kommt allen Besuchern zugute, neuen wie wiederkehrenden: Ein Bild, das auf einem Frankfurter CDN-Node gecacht ist, wird jedem Besucher in Deutschland schnell ausgeliefert, unabhängig davon, ob er Ihren Shop zuvor besucht hat. Der Browser-Cache kommt nur wiederkehrenden Besuchern auf ihrem eigenen Gerät zugute: Hat ein Nutzer das Bild bei einem früheren Besuch bereits heruntergeladen, liefert sein Browser es von der lokalen Festplatte aus, ohne jegliche Netzwerkanfrage.

In der Praxis ergänzen sich beide Cache-Ebenen: Der CDN-Cache reduziert die Latenz beim ersten Seitenaufruf (neuer Besucher oder abgelaufener Browser-Cache), während der Browser-Cache das Netzwerk bei wiederholten Besuchen auf demselben Gerät vollständig eliminiert. Eine Ressource mit max-age=31536000 erfordert nur einmal pro Jahr und Gerät eine Netzwerkanfrage — ein sehr bedeutender Performance-Gewinn für treue Besucher.

ETag und Last-Modified: bedingte Cache-Validierung

Selbst bei einem abgelaufenen TTL ist der Browser nicht gezwungen, eine Ressource von Grund auf neu herunterzuladen. Er kann eine bedingte Anfrage senden, um zu prüfen, ob sich die Ressource geändert hat: Falls nicht, antwortet der Server mit dem HTTP-Status 304 (Not Modified) ohne Antwort-Body — das spart Bandbreite und bestätigt gleichzeitig die Aktualität der gecachten Ressource.

Der ETag (Entity Tag) ist ein eindeutiger Bezeichner, den der Server für eine bestimmte Version einer Ressource generiert — typischerweise ein Hash des Dateiinhalts. Wenn der Browser eine bedingte Anfrage stellt, sendet er den ETag seiner gecachten Version im If-None-Match-Header. Hat der Server denselben ETag (die Ressource hat sich nicht geändert), antwortet er mit 304; andernfalls sendet er die neue Version mit einem neuen ETag.

Der Last-Modified-Header funktioniert ähnlich: Der Server gibt das Datum der letzten Änderung der Ressource an, und der Browser sendet es bei bedingten Anfragen im If-Modified-Since-Header. Diese Validierungsmechanismen halten den Cache aktuell, ohne Bandbreite zu verschwenden, wenn sich Inhalte nicht geändert haben.

Wie Lexiik Caching und Invalidierung automatisch verwaltet

Lexiik implementiert eine optimale Caching-Strategie für Bilder in PrestaShop-Shops und löst automatisch das Invalidierungsproblem, das Langzeitcaching normalerweise riskant macht. Jedes auf Cloudflare R2 hochgeladene Bild erhält die Header Cache-Control: public, max-age=31536000, immutable — ein Jahr Caching auf allen Cloudflare-Edge-Nodes und in den Browsern der Besucher.

Das Invalidierungsproblem wird von Lexiik automatisch über zwei Mechanismen gelöst. Erstens die URL-Versionierung: Von Lexiik CDN ausgelieferte Bilder verwenden Bezeichner in ihren URLs, die sich automatisch ändern, wenn das Bild im PrestaShop-Backend geändert wird. Zweitens automatische Cloudflare-Purge-API-Aufrufe: Wenn sich ein Bild ändert, sendet Lexiik eine Purge-Anfrage an Cloudflare, um den CDN-Cache für dieses spezifische Bild sofort zu invalidieren, ohne andere Bilder zu beeinflussen. Besucher erhalten das neue Bild beim nächsten Besuch, ohne jemals eine veraltete Version zu sehen.

Warum Langzeitcaching das SEO verbessert

Ein TTL von einem Jahr auf Produktbilder verbessert das SEO durch mehrere direkte und indirekte Mechanismen. Direkt: Bilder, die aus dem Cache (CDN oder Browser) geladen werden, erscheinen in Zehn- oder Hundert-Millisekunden, im Vergleich zu mehreren Sekunden bei einem vollständigen Netzwerkdownload. Dies verbessert den LCP — die Core-Web-Vital-Metrik, die am stärksten mit Bildern zusammenhängt — und kann eine Seite nach Googles Schwellenwerten von einem „Schlechten” zu einem „Guten” Score bewegen.

Indirekt reduziert effektives Caching die Anzahl der HTTP-Anfragen an Ihren Ursprungsserver. Weniger Serverlast = besserer TTFB (Time To First Byte) für die dynamischen HTML-Inhalte, die Ihr PrestaShop generiert. Ein TTFB unter 200 ms wird von Google empfohlen; ein Server, der mit Bildanfragen überflutet wird, kann einen verschlechterten TTFB aufweisen, der alle Performance-Metriken beeinträchtigt.

Schließlich sorgt ein gut konfigurierter Browser-Cache für wiederkehrende Besucher — die oft am ehesten zum Kauf bereit sind — für ein nahezu sofortiges Surferlebnis. Produktseiten scheinen unmittelbar zu laden, Bilder sind bereits im Speicher vorhanden. Dies glättet den Kaufprozess und reduziert Abbrüche, mit positiven Auswirkungen auf Verhaltensmetriken, die Google berücksichtigen kann.

• Verbesserter LCP: Bilder werden aus dem lokalen Cache oder CDN in Millisekunden geladen
• Verbesserter TTFB: weniger Anfragen an den Ursprungsserver = geringere Serverlast = HTML wird schneller ausgeliefert
• Besserer PageSpeed-Score: Google Lighthouse bestraft das Fehlen einer Langzeit-Cache-Richtlinie
• Bandbreiteneinsparung: weniger übertragene Daten = niedrigere Kosten und bessere Performance auf Mobilgeräten
• Verbessertes Erlebnis für wiederkehrende Besucher: nahezu sofortige Navigation für Stammkunden