GitHub-Pages-Tools

Kostenlose Cache-Control Header Builder

Erstelle korrekte Cache-Control-HTTP-Header für statische Assets, HTML-Seiten und sensible Inhalte.

Tool wird geladen...

Was ist Cache-Control Header Builder?

Der Cache-Control-HTTP-Header teilt Browsern und CDNs mit, wie lange eine Ressource aufbewahrt werden soll, bevor eine frische Kopie abgerufen wird. Die korrekte Einstellung verbessert die Seitengeschwindigkeit für wiederkehrende Besucher und reduziert unn枚tige Anfragen. Fehlende oder zu aggressive Cache-Header sind ein häufiger Grund, warum Benutzer nach einem Deployment veraltete Inhalte sehen.

Kurze Antwort

Verwenden Sie den Cache-Control-HTTP-Header, um Browsern und CDNs mitzuteilen, wie lange eine Ressource vor einer erneuten Validierung aufbewahrt werden soll. Für statische Seiten: Verwenden Sie public, max-age=31536000, immutable für versionierte CSS/JS-Dateien, public, max-age=0, must-revalidate für HTML und no-store für sensible Seiten.

Last updated: 2026-05-28

Einschränkungen

GitHub Pages unterstützt keine benutzerdefinierten Cache-Control-Header —nur ETag und Last-Modified werden automatisch bereitgestellt. Verwenden Sie Cloudflare oder ein anderes CDN davor für benutzerdefinierte Caching-Regeln.
Die immutable-Direktive ist kein offizieller RFC-Standard, wird aber von modernen Browsern und CDNs weitgehend unterstützt. Sehr alte HTTP/1.1-Proxys ignorieren sie möglicherweise.
Browser können Inhalte im Offline-Modus oder im Back-Forward-Cache weiterhin zwischenspeichern, selbst wenn Cache-Control no-store angibt. Cache-Control ist ein Hinweis, keine Garantie.

Sources:MDN Web Docs · W3C Specifications · jquery.app on GitHub

So nutzt du dieses Tool

Wählen Sie den Ressourcentyp, der zu Ihrem Inhalt passt: statisches HTML, versioniertes CSS/JS, Bilder, Feeds, private Seiten oder no-store.
Wählen Sie bei Bedarf Ihre Hosting-Plattform für spezifische Deployment-Tipps.
Kopieren Sie den Cache-Control-Header-Wert und fügen Sie ihn Ihrer Serverkonfiguration, Ihren CDN-Regeln oder der Header-Datei Ihrer Hosting-Plattform hinzu.

Wofür du es nutzen kannst

Aggressives Caching für versionierte CSS- und JS-Dateien mit Content-Hash-Dateinamen einrichten.
Caching von Authentifizierungsseiten, Checkout-Abläufen und sensiblen Benutzerdaten verhindern.
Feed- und Sitemap-Aktualität konfigurieren, damit Crawler aktuelle Inhalte ohne übermässige Anfragen erhalten.

Anwendungsfalle

Praxisbeispiele

Beispiel

Versionierte Assets auf Netlify

Eine statische Seite verwendet gehashte Dateinamen wie main.a3f8b2.js. Setzen Sie den Cache-Control-Header auf public, max-age=31536000, immutable in der Netlify _headers-Datei, damit wiederkehrende Besucher sofort aus dem Cache laden.

Beispiel

Sensible Checkout-Seite

Eine E-Commerce-Seite stellt eine Checkout-Seite bereit, die niemals von CDNs oder Browsern zwischengespeichert werden darf. Setzen Sie Cache-Control: no-store, um sicherzustellen, dass jede Anfrage eine frische Kopie vom Ursprungsserver abruft.

Haufige Fehler

Ein langes max-age auf HTML-Seiten setzen, die sich häufig ändern —Benutzer sehen nach einem Deployment veraltete Inhalte.
no-store auf jeder Seite verwenden anstatt gezielt no-cache oder max-age=0, was die Leistung beeinträchtigt.
Vergessen, dass GitHub Pages benutzerdefinierte Cache-Control-Header ignoriert —nur ETag und Last-Modified werden automatisch gesetzt.

Überprüfung

Überprüfen Sie den Cache-Control-Header im Browser-DevTools-Netzwerk-Tab —suchen Sie nach dem Antwort-Header für die spezifische Ressource.
Verwenden Sie curl -I https://ihreseite.com/pfad, um Header von der Befehlszeile aus zu überprüfen. Bestätigen Sie, dass das CDN den ursprünglichen Header korrekt durchreicht.

FAQ

Fragen zu Cache-Control Header Builder

Was ist der Unterschied zwischen no-cache und no-store?

no-cache bedeutet, dass der Browser vor der Verwendung einer zwischengespeicherten Kopie mit dem Server erneut validieren muss —die Antwort kann weiterhin zwischengespeichert werden, muss aber als aktuell bestätigt werden. no-store bedeutet, dass gar nichts zwischengespeichert werden darf, nicht einmal im Arbeitsspeicher. Verwenden Sie no-cache mit must-revalidate für die meisten updatekritischen Seiten; verwenden Sie no-store nur für sensible Daten wie Zahlungsseiten.

Wie setze ich Cache-Control auf GitHub Pages?

GitHub Pages setzt automatisch Cache-Control: max-age=600 (10 Minuten) für HTML und max-age=31536000 (1 Jahr) für versionierte Assets. Sie können diese Werte nicht überschreiben. Wenn Sie benutzerdefinierte Cache-Header benötigen, verwenden Sie Cloudflare vor GitHub Pages mit Page Rules oder wechseln Sie zu Netlify oder Vercel, die benutzerdefinierte _headers-Dateien unterstützen.

Was bedeutet immutable in Cache-Control?

Die immutable-Erweiterung teilt dem Browser mit, die erneute Validierung zu überspringen, selbst wenn der Benutzer die Aktualisierungstaste drückt. Verwenden Sie es nur für versionierte Ressourcen mit Content-Hash-Dateinamen (wie app.a3f8b2.js). Wenn sich der Inhalt ändert, ändert sich der Dateiname, sodass die zwischengespeicherte Version per Definition niemals veraltet ist. Verwenden Sie immutable niemals für nicht versionierte URLs.

Wie lange sollte ich Bilder auf einer statischen Seite zwischenspeichern?

Für Bilder ohne versionierte Dateinamen ist ein max-age von 86400 (24 Stunden) ein sicherer Standardwert —Bilder ändern sich selten, aber Sie möchten, dass Aktualisierungen innerhalb eines Tages verbreitet werden. Für versionierte Bilder (logo.v2.png) verwenden Sie max-age=31536000 mit immutable. Für Bilder, die sich täglich ändern (wie ein tägliches Diagramm), verwenden Sie max-age=3600 oder max-age=0 mit must-revalidate.

Verwandte Tools