Cache-Control-Header-Builder
Erstellen Sie in Sekundenschnelle visuell standardmäßige, hochoptimierte Cache-Control-HTTP-Header. Definieren Sie öffentliche/private Bereiche, legen Sie Ablauffristen für maximales Alter und maximales Alter mit benutzerfreundlichen Voreinstellungen fest, fügen Sie veraltete Fallbacks hinzu und kopieren Sie gebrauchsfertige Serverkonfigurationen für Nginx, Apache, Vercel und Next.js. Privat, schnell und lokal.
Select your cacheability scope, set browser/CDN expiration parameters, enable stale recovery limits, and specify revalidation holds.
Cache-Control: public, max-age=3600
Plain-English Caching Rule Translation
Browsers will cache this resource locally for up to 1 hour and load it instantly from cache without checking the server.
CDNs and public proxies will cache this resource for up to 1 hour (matching the browser limit).
Once the cache expires, browsers will typically check with the server, but may serve a cached copy under certain network/browser fallback conditions.
Standard caching directive layout suitable for ordinary web assets.
Funktionen des Cache-Control Header Builder
- Konfiguration feinkörniger Direktiven: Konfigurieren Sie ganz einfach den Cache-Bereich, das maximale Browseralter, CDN-Überschreibungen, veraltete Fallbacks, eine erneute Validierung und Unveränderlichkeitseinstellungen.
- Einfache englische Übersetzungen: Verstehen Sie genau, wie Ihre Header-Konfiguration Browser, CDNs und Proxys anweist, Ihre Web-Assets zu speichern, zu validieren und bereitzustellen.
- Multiplattform-Code-Integration: Generieren Sie sofort Integrations-Snippets für Nginx, Apache, Vercel, Next.js, Netlify, Express, PHP und Cloudflare Workers.
- 100 % lokale und sichere Sandbox: Jede Berechnung, Header-Kompilierung und jeder Snippet-Export wird vollständig clientseitig in Ihrem lokalen Browser ausgeführt und gewährleistet so absolute Privatsphäre.
Die Caching-Hierarchie (Browser vs. CDN)
Web-Caching erfolgt auf mehreren Ebenen. Erstens speichert der Browser-Cache Ressourcen lokal auf dem Benutzercomputer. Zweitens speichern gemeinsam genutzte Caches wie Proxys, Gateways und Content Delivery Networks (CDNs) Dateien näher an Benutzern an Edge-Standorten. Durch die Verwendung von Anweisungen wie public, private und s-maxage können Sie steuern, welche Ebenen Ihre Dateien wie lange zwischenspeichern.
Cache-Validierung und -Revalidierung
Anweisungen wie „must-revalidate“ und „proxy-revalidate“ weisen Caches an, was zu tun ist, wenn eine zwischengespeicherte Ressource abläuft (veraltet wird). Wenn eine erneute Validierung erforderlich ist, kann der Cache die veraltete Kopie erst bereitstellen, wenn er erfolgreich beim Ursprungsserver überprüft hat (mithilfe von If-None-Match mit ETags oder If-Modified-Since), dass sich die Ressource nicht geändert hat.
Stale-While-Revalidate-Vorteil
Moderne Webanwendungen nutzen Stale-While-Revalidate, um kritische Rendering-Pfade zu optimieren. Anstatt Benutzer auf Netzwerkanfragen warten zu lassen, wenn ein zwischengespeichertes Element veraltet ist, lädt der Client das veraltete Element sofort aus dem Cache. Im Hintergrund löst der Browser eine Revalidierungsanfrage aus, um den veralteten Cache-Eintrag für die nächste Anfrage durch eine neue Kopie zu ersetzen.
Unveränderlichkeit für Hash-Assets
Bei modernen Frontend-Frameworks, die Content-Hashing für Build-Ausgaben verwenden (z. B. bundle.[hash].js), werden sich Dateien garantiert nie ändern. Das Markieren dieser Antworten als unveränderlich mit einem hohen Maximalalter (z. B. 1 Jahr) verhindert, dass Browser CPU-Zyklen und Serverbandbreite für redundante Neuvalidierungsprüfungen verschwenden, selbst bei harten Browseraktualisierungen.
Häufig gestellte Fragen
Cache-Control ist ein Standard-HTTP-Header, der Anweisungen enthält, die Browser, Proxys und Content Delivery Networks (CDNs) anweisen, wie Ressourcen zwischengespeichert werden. Es regelt die Cachefähigkeit, Ablauffristen, Anforderungen zur erneuten Validierung und veraltete Fallback-Richtlinien, um die Webleistung und Bandbreitennutzung zu optimieren.
Die max-age-Direktive definiert, wie lange (in Sekunden) eine Antwort für den Client-Browser als aktuell gilt. Die s-maxage-Direktive überschreibt insbesondere das maximale Alter für gemeinsam genutzte Caches, Proxys und CDNs (wie Cloudflare oder Fastly), sodass Sie Assets auf Edge-Knoten für eine andere Dauer als im Benutzerbrowser zwischenspeichern können.
Die No-Store-Anweisung verbietet jedem Cache (privater Browser oder öffentliches CDN), Teile der Anfrage oder Antwort zu speichern; Es wird jedes Mal frisch vom Ursprungsserver abgerufen. Die No-Cache-Anweisung ermöglicht es Caches, die Antwort zu speichern, zwingt sie jedoch, sie vor der Wiederverwendung mit dem Ursprungsserver zu validieren (mithilfe von ETag oder Last-Modified).
Die unveränderliche Direktive teilt dem Browser mit, dass sich der Antworttext während seiner maximalen Lebenszeit niemals ändern wird. Dadurch wird verhindert, dass der Browser bedingte Neuvalidierungsanfragen an den Server sendet, wenn der Benutzer die Seite manuell aktualisiert, wodurch das Neuladen der Seite für statische, gehashte Bundle-Assets (wie main.a8f9b2.js) beschleunigt wird.
Die Anweisung „stale-while-revalidate“ ermöglicht es Caches, dem Client sofort ein abgelaufenes (veraltetes) zwischengespeichertes Asset bereitzustellen und gleichzeitig einen Hintergrundabruf auszulösen, um die neue Version vom Ursprungsserver abzurufen, was zu einer wahrgenommenen Latenzreaktion von 0 ms führt.
Ja, 100 %. Die gesamte Header-Kompilierung, Übersetzung und Code-Snippet-Generierung erfolgt vollständig clientseitig in Ihrem Webbrowser. Es werden niemals Einstellungen, API-Pfade oder Parameterwerte auf externe Server hochgeladen, wodurch der vollständige Datenschutz gewahrt bleibt.