Browser-Caching erklärt: Cache-Control, ETag und CDN-Optimierung

Zwei Schichten des HTTP-Cachings

Der Browser fordert eine Ressource an
      ↓
① Starker Cache (kein Server-Roundtrip)
   Cache-Control: max-age=31536000
      ↓ abgelaufen
② Validierungs-Cache (Server fragen, ob sich etwas geändert hat)
   ETag / Last-Modified → 304 Not Modified
      ↓ Ressource geändert
③ Neue Ressource vom Server abrufen → 200 OK

Cache-Control-Direktiven

Direktive	Bedeutung	Beispielanwendung
`max-age=N`	Cache für N Sekunden verwenden	JS/CSS (1 Jahr)
`s-maxage=N`	CDN cached für N Sekunden	HTML (1 Tag)
`no-cache`	ETag jedes Mal revalidieren	API-Antworten
`no-store`	Überhaupt kein Caching	Sensible Daten
`immutable`	Inhalt ändert sich nie	Hash-benannte Assets
`stale-while-revalidate=N`	Veralteten Inhalt für N Sekunden serveen, während revalidiert wird	i18n-JSON

ToolsKu-Cache-Konfiguration

# _next/static/chunks/app-abc123.js
Cache-Control: public, max-age=31536000, immutable

# /de/pdf/merge/index.html
Cache-Control: public, max-age=3600, s-maxage=86400

# /i18n/toolClients/de.json
Cache-Control: public, max-age=86400, stale-while-revalidate=604800

ETag-Validierungs-Caching

# Erste Anfrage
GET /api/config HTTP/1.1
→ 200 OK
   ETag: "abc123"
   Cache-Control: no-cache

# Nachfolgende Anfrage
GET /api/config HTTP/1.1
   If-None-Match: "abc123"
→ 304 Not Modified (leerer Body, spart Bandbreite)

ETags werden von einem Inhalts-Hash abgeleitet. Unveränderter Inhalt gibt 304 zurück und der Browser verwendet seine lokale Kopie.

CDN-Cache-Architektur

ToolsKu ist auf Alibaba Cloud OSS + CDN bereitgestellt:

Benutzer fordert https://www.toolsku.com/de/ an
      ↓
CDN-Edge-Knoten (Peking / Shanghai / Guangzhou)
      ↓ Cache-Treffer → direkte Antwort (TTFB ~20ms)
      ↓ Cache-Fehler
OSS-Ursprung (Peking)
      ↓ Ressource zurückgeben + CDN-Cache befüllen
CDN → Benutzer

Cache-Schlüssel-Design

CDN-Schlüssel sind normalerweise URL + Query-String. Achten Sie auf:

?v=123 und ?v=456 sind unterschiedliche Cache-Einträge
Anfragen mit Accept-Language können den Cache aufteilen (Vary-Header)
ToolsKu verwendet pfadbasierte Lokalen (/zh-CN/, /en/), um Vary-Probleme zu vermeiden

Häufige Cache-Fallen

1. Aktualisiertes JS, aber Benutzer sehen den alten Build

Ursache: Altes JS ist stark gecacht; neues HTML verweist auf neue Dateinamen, aber altes JS bleibt im Cache.

Lösung: Inhalts-Hash-Dateinamen (Next.js-Standard _next/static/chunks/app-[hash].js). Inhaltsänderung → Hash-Änderung → natürliche Invalidierung.

2. HTML-Cache verbirgt frischen Inhalt

Lösung: Kürzeres max-age + s-maxage bei HTML oder aktives Bereinigen über die CDN-Refresh-API.

3. Service-Worker-Cache vs. HTTP-Cache

Der Service-Worker-fetch-Handler kann alle Anfragen abfangen — hat Priorität vor dem HTTP-Cache. Erhöhen Sie die Cache-Version bei SW-Updates und löschen Sie alte Caches.

Cache-Debugging-Tools

Chrome DevTools → Network: Size-Spalte ((disk cache) / (memory cache) / tatsächliche Größe)
Response-Header: Cache-Control, ETag, Age prüfen
ToolsKu HTTP-Statuscode-Referenz: 200, 304, 404 usw. verstehen

Zusammenfassung

Solides Caching ist Kern der Web-Performance. Starker Cache + Validierungs-Cache + CDN-Edge-Knoten geben ToolsKu ein TTFB von ca. ~50ms beim First Paint. Cache-Control und ETag zu verstehen ist grundlegende Frontend-Performance-Arbeit.