hatestheinternet
post image is Blue Mountain Supercomputer

Nomenclature

Before we even crack a text editor or create a CDN bucket, we need to stop and think about the three types of assets common across every website and use this to develop our caching strategy. Note that these might not apply to all sites, but I'd lay even money they're the same across most. At the very least I'd recommend you give it a quick once-over because I can pretty much guarantee you I don't call anything by it's proper name. I take it as a point of pride.

Static Assets

These little guys are generally, well, little, and there are usually a lot of them. This is where we find all our JavaScript, CSS, font resources and anything else related to the presentation and operation of the site itself. The assumption is these files will change from time to time, mostly in response to changes and updates at the module or theme level.

Future Expiry

When I'm talking about future caching, I'm talking about a time to live of around 4 weeks. This is the strategy I use for my static assets as I've found a month offers the best balance between maximum caching and module/theme updates. If you find yourself changing things often, however, you should probably turn your future cache down to 2 weeks or whatever works for you because, if it winds up too far out of whack with your dynamic content, you could find yourself up shit's creek.

Content Assets

When I say this, I mean everything realted to our site's content: Images and their derivatives, videos, downloadable recipes for fudge... Basically everything we upload or the server creates to display a node or item or whatever your CMS calls them. These files, they're not gong to change at all. Once you've created your node and attached your images and video and whatever else, that's it, she's there for the life time of your site or until your CMS garbage collects them. (Unless it sucks.)

Far Future Expiry

This is the caching lifetime I use for my content assets, and it's always access plus one year. As with the future expiry, if you find yourself changing your content assets often (which, really, you shouldn't ever need to), you might need to dial this back a bit.

Dynamic Content

This is the stuff our PHP or ASP (ew) or whatever spits out in response to a user's request. Depending on your CMS and how tight your tech game is, caching this might range from difficult to impossible. For this bucket, we're going to leave the setting of expiry dates up to our CMS and so as long as it's setting the appropriate no cache headers on administration pages and unpublished content, you shouldn't have any problems throwing a CDN in front.

At this level, I see using a CDN as more of a server load management and Slashdotting prevention exercise than actual caching. Plus, since everything here is dynamically generated, your CMS will probably have a way of adjusting expiries for older content to offload even more to the distribution network.

Now that that's out of the way, let's get geeky.