Github pages / Caching assets in website served from GitHub pages

[ecstrema]

Original issue here.

The servers for GitHub pages set CacheControl: max-age=600. It means the cache is set to last only for ten minutes, which is undesirable.

Is it possible to control this value and to set also only-if-cached status?

I know that there is no direct access to the .htaccess file or an equivalent, but I am looking for indirect access via some sort of settings or confirmation, or proof that it is impossible.

[jy95]

It would be nice indeed if we can configure it somehow.
For example inside a setting available on "Pages" settings called "Caching" :

That setting could be some kind of configuration table such as :

Extension	Cache-Control
webp	max-age=10000
	only-if-cached
jpg	max-age=600

• In "Extension", the extension impacted by this rule
• In "Cache-Control" column, the Cache-Control directive

Of course the annoying part for Microsoft will be the implementation ^^

---

If you need an CRA example that has bunch of pictures (already converted in Webp to safe network load) with infinite scroll loading : https://jy95.github.io/games

If I run report (with "https://jy95.github.io/?/games" as these tools doesn't like CRA redirection workaround) on :

• https://pagespeed.web.dev
• https://gtmetrix.com
• https://web.dev/measure/

I can see that "Serve static assets with an efficient cache policy" is the main action

[rubenvannieuwpoort]

Since this question has been inactive for a while, are there any updates on this?

[jason-sachs]

Not sure about the caching policy now, but I have a GitHub pages that cached a 404 not found for a directory --- in other words:

• there was previously no https://SOMEACCOUNT.github.io/SOMEPROJECT/mydir
• I accessed this URL and got a 404 not found
• then I realized I had uploaded to a misspelled directory (e.g. https://SOMEACCOUNT.github.io/SOMEPROJECT/myidr)
• I fixed this
• Now https://SOMEACCOUNT.github.io/SOMEPROJECT/mydir/index.html works
• but https://SOMEACCOUNT.github.io/SOMEPROJECT/mydir and https://SOMEACCOUNT.github.io/SOMEPROJECT/mydir/ still give me a cached 404

[jaredkrinke]

Did this ever resolve for you? I'm curious how long it takes. Edit: my issue resolved after roughly 1 hour.

I just did almost the same thing and it's been at least ten minutes and I'm still being served the cached 404 page even though I fixed my mistake ☹️

[latenitefilms]

I'd also love to see the ability to customise the cache values.

For example, GTmetrix tells me:

[corentinway]

You can setup the cache front the client side, with the javascript Cache API.

https://developer.mozilla.org/fr/docs/Web/API/Cache

It should work.

[latenitefilms]

FWIW - I solved this by using CloudFlare.

[manuelernestog]

Hi @latenitefilms. Can you share with us how did you solve this with Cloudflare? Thanks in advice.

[MrMarble]

@manuelernestog Maybe I'm late but since there's no response...
If you use a custom domain to your github page and that domain is registered through Cloudflare's DNS, you can configure Cache rules on Cloudflare dashboard.

There are some general options and even a custom rule section https://developers.cloudflare.com/cache/how-to/cache-rules/

[koitsu]

I think you need to do some deeper reading + understand how HTTP caching actually works, especially with Cloudflare (who has their own implementation/approach). See https://developers.cloudflare.com/cache/how-to/edge-browser-cache-ttl/set-browser-ttl/ for the important details. While reading this page, remember that the topology is now client <--> CF <--> GHP (a.k.a. "origin web server"). CF effectively becomes an HTTP client, talking to GHP. Think about what CF sees from GHP, cache-header-wise. Please read the page slowly and in full -- not skimming -- because you may be surprised by what CF does.

[extremq]

Cloudflare is a good solution if you already use it as a Proxy

[benui-dev]

Any update on this would be greatly appreciated.

[scottstraughan]

This would be a fantastic feature to add!

If GitHub pages could natively support the CloudFlare "_headers" file or even configuration via the settings, this would make Pages a much more powerful too.

A good use case for this is if you are bundling fonts. At the moment, one of the front-ends I have worked on ships with its own font files. For the sake of keeping things as simple as possible, I decided not to use a CDN and instead ship those files as a local copy via GitHub pages. It works fine.. but due to the short cache time its constantly re-loading on each visit. It would be fantastic to either set it to cache always with revalidation or to be able to at least specify a longer cache time. Otherwise, a CDN would probably be needed as the user experience is not fantastic.

Anyway, just my 2 cent!

[nikolaydubina]

Came here from https://pagespeed.web.dev/analysis

If I can setup caching policy, I would get 100% score! Would be nice to have this policy and make it possible for largest static website hosting platform to let its users to have excellent score!

[asturur]

Has this topic seen any change?

[CycloKid]

seriously! if we could at least increase caching time, it would save github lots of money on bandwidth!
why isnt this feature a thing?

[applejag]

Probably because spending time on this could save them tiny bits of money, but it would cost precious development time, which they probably want to spend elsewhere.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[CharlieDigital]

Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

There seems to be nothing but positives from implementing this:

• Reduce network bandwidth for Microsoft
• Instantly increase page performance across the board for hundreds of thousands - millions (?) of static sites running in GH
• Improve the user experience for end-users consuming those sites with faster response times

It would be great to have the option to have a simple static file like the CNAME file which allows specifying some set of rules for sending headers matching file/path name patterns.

It may be worthwhile to go a JSON/YAML route similar to how Firebase Hosting sets it up: https://firebase.google.com/docs/hosting/full-config#headers

"hosting": {
  // ...

  // Applies a CORS header for all font files
  "headers": [ {
    "source": "**/*.@(eot|otf|ttf|ttc|woff|font.css)",
    "headers": [ {
      "key": "Access-Control-Allow-Origin",
      "value": "*"
    } ]
  } ]
}

It's possible to keep the user interface light for this and make it an advanced option for users that want to tune the behavior. If the user clicks a button like Use custom headers in the Settings page, then drop a file like HEADERS.yaml into the root with the default configuration and then let the user customize behavior from there.

[CycloKid]

i would also say that github should auto-configure github pages (by default) so that pages that are unchanged for extended periods of time gradually get longer cache ages.

perhaps something like this table below?

Time left unchanged	Cache age
< 1 week	~2 hours more or less
1-3 weeks	8-24 hours
1-3 months	2-4 days
4-6 months	4-7 days
6-12 months	7-21 days
More than a year	30+ days

Now while this table example may not fit perfectly with most pages, you probably get the idea of "longer time unchanged = longer time cache age". Different types of content (HTML, CSS, JS, Images, Videos, etc.) will likely need to be configured differently too.

[mrec]

@CycloKid what you're describing is "heuristic caching" and browsers already do it in the absence of any Cache-Control response headers.

I can understand why GitHub wants to avoid new developers getting confused by caching as they make changes, and there's a good case for being stricter with script given that it may be closely tied to page structure, but for cosmetic things like images or CSS I can see zero downsides to including a long stale-while-revalidate along with the short max-age. Check for updates in the background by all means, but it's fine to use the cached resource while that's happening.