GitHub Pagesツール

無料 Cache-Control ヘッダービルダー

静的アセット、HTMLページ、機密コンテンツ向けのCache-Control HTTPヘッダーを作成します。

ツールを読み込み中...

Cache-Control ヘッダービルダーとは

The Cache-Control HTTP header tells browsers and CDNs how long to keep a resource before fetching a fresh copy. Setting it correctly improves page speed for repeat visitors and reduces unnecessary requests. Missing or overly aggressive cache headers are a common reason users see stale content after a deploy.

クイックアンサー

Use the Cache-Control HTTP header to tell browsers and CDNs how long to keep a resource before revalidating. For static sites: use public, max-age=31536000, immutable on fingerprinted CSS/JS, public, max-age=0, must-revalidate on HTML, and no-store on sensitive pages.

制限事項

GitHub Pages does not support custom Cache-Control headers — only ETag and Last-Modified are provided automatically. Use Cloudflare or another CDN in front for custom caching rules.
The immutable directive is not an official RFC standard but is widely supported by modern browsers and CDNs. Very old HTTP/1.1 proxies may ignore it.
Browsers may still cache content when offline or in back-forward cache even when Cache-Control says no-store. Cache-Control is a hint, not a guarantee.

使い方

Select the resource type that matches your content: static HTML, fingerprinted CSS/JS, images, feeds, private pages, or no-store.
Choose your hosting platform for specific deployment tips if needed.
Copy the Cache-Control header value and add it to your server config, CDN rules, or hosting platform headers file.

主な用途

Set aggressive caching for fingerprinted CSS and JS files with content-hash filenames.
Prevent caching of authentication pages, checkout flows, and sensitive user data.
Configure feed and sitemap freshness so crawlers get up-to-date content without excessive requests.

用途

使用例

例

Fingerprinted assets on Netlify

A static site uses hashed filenames like main.a3f8b2.js. Set the Cache-Control header to public, max-age=31536000, immutable in the Netlify _headers file so returning visitors load instantly from cache.

例

Sensitive checkout page

An e-commerce site serves a checkout page that must never be cached by CDNs or browsers. Set Cache-Control: no-store to ensure every request fetches a fresh copy from the origin.

よくあるミス

Setting a long max-age on HTML pages that change frequently — users see stale content after a deploy.
Using no-store on every page instead of targeted no-cache or max-age=0, which harms performance.
Forgetting that GitHub Pages ignores custom Cache-Control headers — only ETag and Last-Modified are set automatically.

検証

Check the Cache-Control header in the browser DevTools Network tab — look for the response header on the specific resource.
Use curl -I https://yoursite.com/path to verify headers from the command line. Confirm the CDN is passing through the origin header correctly.

FAQ

Cache-Control ヘッダービルダーのFAQ

What is the difference between no-cache and no-store?

no-cache means the browser must revalidate with the server before using a cached copy — the response can still be cached, but must be confirmed fresh. no-store means nothing may be cached at all, not even in memory. Use no-cache with must-revalidate for most update-critical pages; use no-store only for sensitive data like payment pages.

How do I set Cache-Control on GitHub Pages?

GitHub Pages sets Cache-Control: max-age=600 (10 minutes) for HTML and max-age=31536000 (1 year) for versioned assets automatically. You cannot override these values. If you need custom cache headers, use Cloudflare in front of GitHub Pages with Page Rules, or switch to Netlify or Vercel which support custom _headers files.

What does immutable mean in Cache-Control?

The immutable extension tells the browser to skip revalidation even when the user hits the refresh button. Use it only on versioned resources with content-hash filenames (like app.a3f8b2.js). If the content changes, the filename changes, so the cached version is never stale by definition. Never use immutable on non-versioned URLs.

How long should I cache images on a static site?

For images without versioned filenames, a max-age of 86400 (24 hours) is a safe default — images change rarely but you want updates to propagate within a day. For fingerprinted images (logo.v2.png), use max-age=31536000 with immutable. For images that change daily (like a daily chart), use max-age=3600 or max-age=0 with must-revalidate.