Nate Volker

Edge Cache Caching Strategies for Static Sites

So you've got a static site. You've implemented all the stuff in HTTP Caching Strategies for Static Sites, but your site still feels sluggish. Maybe you're running the site off a solar-powered single-board computer (you wouldn't be the first one). Or maybe you're hosting it from somewhere with super-slow internet. Whatever the case - it's just not fast enough. You need an edge-cache.

What is an Edge Cache?

An edge cache is a computer (or computers) that sit in-front of your web server. Instead of browsers making requests directly to your server, they go through an edge cache first. Most often, an edge cache is run by a third party service (I use Cloudflare). Ideally, you want to let the edge cache respond to as many requests as possible without having to talk to your web server. Since edge caches are typically a distributed network of computers, chances are they will be much closer to your users than your web server is.

Using an Edge Cache in front of a Static Site

Each service will have it's own set-up process that typically involves pointing your domain's DNS at their servers instead of your own. Once that's set up, you'll already be benefitting from using their service. Assuming you're already serving sub-resources with a fingerprinted/hashed filename and a long-lived Cache-Control header, and sending Etag headers with your root resources, the only requests that should be being forwarded to your root server will be root resource requests from browsers with a out-of-date or empty cache.

But we can do better.

The Cache-Control s-maxage directive, used alongside the usual max-age directive can be used to tell the edge cache "you can hold onto this resource, but don't let browsers hold onto it". So if you serve all your root resources with a Cache-Control: s-maxage=31536000,max-age=0 header, you'll only ever see a single request for each resource make it through to your web server. The edge cache would essentially be "hosting" your entire site!

The only issue with this strategy is you typically want to update things at some point, which you can't do if the edge cache never checks for updates. The easy solve for this is to purge everything from your edge cache each time you deploy an update. If your static site is relatively small, you could also write a script that walks through your root resources, checks them against the current "live" version in the edge cache, and then purges them individially.