Tower Defense: Cache Control

Summary

For those of you who landed here directly and missed my implausible intro, this isn’t a game. It’s something even better: an article about caching! I’ll describe the techniques used on my sites jasonthorsness.com and hn.unlurker.com. The latter is open-source so you can peruse the implementation. If you are looking to defend a meager budget with web-exposed side projects from an onslaught of web traffic you might find these approaches helpful. And if you are part of the problem, a user among countless others in your horde, driven en masse in wave after wave against my defenses — read on to scout my setup and find out whether or not it’s up to the challenge. The article progresses through three difficulty levels: Difficulty LevelDescriptionEasyMostly-static sitesMediumData-driven dynamic sitesHardAuthenticated per-user sites Easy: Mostly-Static Sites Static means the content is the same for every user and doesn’t change as a function of time. For example, due to my sluggish pace of writing, jasonthorsness.com remains unchanged for weeks in between updates. Even then, my older articles like this one don’t change unless I adjust a common layout. For this kind of site, applying content-hashed resources, using a CDN, and keeping dynamic bits client-side is the dominant industry combination. Content-Hashed Resources To improve the handling of supporting resources (CSS, JS, images, etc.) a universal practice in modern web frameworks is to add content hashes to the resource names. By deriving the name of the file from its contents, you can consider a file with a given name unchanging. For example, on this site, one of the fonts is at the time of writing served as /_next/static/media/bd734242e06bd6ad-s.p.woff2 with the cache-control header of public,max-age=31536000,immutable. The bd734242e06bd6ad part of the name is a hash of the file contents. The CDN and the user’s browser will cache this file for as long as they want without worrying about it becoming stale. If I ever ch...