GitHub Pages tools

Gratis Cache-Control Header Builder

Bouw correcte Cache-Control HTTP-headers voor statische assets, HTML-pagina's en gevoelige inhoud.

Tool laden...

Wat is Cache-Control Header Builder?

De Cache-Control HTTP-header vertelt browsers en CDN's hoe lang ze een bron moeten bewaren voordat ze een nieuwe kopie ophalen. Het correct instellen ervan verbetert de paginasnelheid voor terugkerende bezoekers en vermindert onnodige verzoeken. Ontbrekende of te agressieve cache-headers zijn een veelvoorkomende reden dat gebruikers verouderde content zien na een implementatie.

Snel antwoord

Gebruik de Cache-Control HTTP-header om browsers en CDN's te vertellen hoe lang ze een bron moeten bewaren voordat ze opnieuw valideren. Voor statische sites: gebruik public, max-age=31536000, immutable op fingerprint CSS/JS, public, max-age=0, must-revalidate op HTML en no-store op gevoelige pagina's.

Last updated: 2026-05-28

Beperkingen

  • GitHub Pages ondersteunt geen aangepaste Cache-Control-headers - alleen ETag en Last-Modified worden automatisch verstrekt. Gebruik Cloudflare of een andere CDN ervoor voor aangepaste cacheregels.
  • De immutable-richtlijn is geen officiële RFC-standaard maar wordt breed ondersteund door moderne browsers en CDN's. Zeer oude HTTP/1.1-proxy's kunnen het negeren.
  • Browsers kunnen content nog steeds cachen wanneer offline of in back-forward cache, zelfs wanneer Cache-Control no-store zegt. Cache-Control is een hint, geen garantie.

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

Zo gebruik je deze tool

  1. Selecteer het brontype dat overeenkomt met uw content: statische HTML, fingerprint CSS/JS, afbeeldingen, feeds, privépagina's of no-store.
  2. Kies indien nodig uw hostingplatform voor specifieke implementatietips.
  3. Kopieer de Cache-Control headerwaarde en voeg deze toe aan uw serverconfiguratie, CDN-regels of het headers-bestand van uw hostingplatform.

Waarvoor je het kunt gebruiken

  • Stel agressieve caching in voor fingerprint CSS- en JS-bestanden met content-hash bestandsnamen.
  • Voorkom caching van authenticatiepagina's, afrekenstromen en gevoelige gebruikersgegevens.
  • Configureer feed- en sitemap-freshheid zodat crawlers actuele content krijgen zonder buitensporige verzoeken.

Gebruik

Praktische voorbeelden

Voorbeeld

Fingerprint assets op Netlify

Een statische site gebruikt gehashte bestandsnamen zoals main.a3f8b2.js. Stel de Cache-Control-header in op public, max-age=31536000, immutable in het Netlify _headers-bestand zodat terugkerende bezoekers direct vanuit de cache laden.

Voorbeeld

Gevoelige afrekenpagina

Een e-commerce site serveert een afrekenpagina die nooit door CDN's of browsers gecacht mag worden. Stel Cache-Control: no-store in om ervoor te zorgen dat elk verzoek een nieuwe kopie van de oorsprong ophaalt.

Veelgemaakte fouten

  • Een lange max-age instellen op HTML-pagina's die regelmatig wijzigen - gebruikers zien verouderde content na een implementatie.
  • No-store gebruiken op elke pagina in plaats van gerichte no-cache of max-age=0, wat de prestaties schaadt.
  • Vergeten dat GitHub Pages aangepaste Cache-Control-headers negeert - alleen ETag en Last-Modified worden automatisch ingesteld.

Verificatie

  1. Controleer de Cache-Control-header in het DevTools Netwerk-tabblad - zoek naar de response-header op de specifieke bron.
  2. Gebruik curl -I https://uw site.com/pad om headers vanaf de commandoregel te verifiëren. Bevestig dat de CDN de oorsprongheader correct doorgeeft.

FAQ

Vragen over Cache-Control Header Builder

Wat is het verschil tussen no-cache en no-store?

no-cache betekent dat de browser opnieuw moet valideren met de server voordat een gecachte kopie wordt gebruikt - de respons kan nog worden gecacht, maar moet als vers worden bevestigd. no-store betekent dat er helemaal niets mag worden gecacht, zelfs niet in het geheugen. Gebruik no-cache met must-revalidate voor de meeste update-kritieke pagina's; gebruik no-store alleen voor gevoelige gegevens zoals betaalpagina's.

Hoe stel ik Cache-Control in op GitHub Pages?

GitHub Pages stelt automatisch Cache-Control: max-age=600 (10 minuten) in voor HTML en max-age=31536000 (1 jaar) voor versiebeheerde assets. U kunt deze waarden niet overschrijven. Als u aangepaste cache-headers nodig heeft, gebruik dan Cloudflare voor GitHub Pages met Page Rules, of schakel over naar Netlify of Vercel die aangepaste _headers-bestanden ondersteunen.

Wat betekent immutable in Cache-Control?

De immutable-extensie vertelt de browser om hervalidatie over te slaan, zelfs wanneer de gebruiker op de vernieuwknop drukt. Gebruik het alleen op versiebeheerde bronnen met content-hash bestandsnamen (zoals app.a3f8b2.js). Als de content verandert, verandert de bestandsnaam, dus de gecachte versie is per definitie nooit verouderd. Gebruik nooit immutable op niet-versiebeheerde URL's.

Hoe lang moet ik afbeeldingen cachen op een statische site?

Voor afbeeldingen zonder versiebeheerde bestandsnamen is een max-age van 86400 (24 uur) een veilige standaard - afbeeldingen veranderen zelden maar u wilt dat updates binnen een dag worden doorgevoerd. Voor fingerprint afbeeldingen (logo.v2.png) gebruikt u max-age=31536000 met immutable. Voor dagelijks veranderende afbeeldingen gebruikt u max-age=3600 of max-age=0 met must-revalidate.

Gerelateerde tools

Meer github pages tools

Probeer ook

Probeer ook