A short guide to a caching strategy

This is cheap to get right at the start and expensive to retrofit. Everything we would tell a client about a caching strategy in the time it takes to drink a coffee.

Speed is a feature people notice only in its absence, and then they leave rather than complain. The version that survives contact with a real deadline is the simple one.

Why it matters

The fastest request is the one never made. In practice this is a scheduling problem more than a technical one. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

How we handle it

Cache static assets aggressively with fingerprinted filenames. The reasoning matters more than the rule, because the rule has exceptions. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

Common failure modes

Decide your invalidation rules before you need them. There is a version of this that is over-engineered, and it is worth avoiding. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

In practice

Performance work is mostly subtraction, which makes it unpopular and effective. Three things worth confirming about a caching strategy before you move on:

• Someone can say what the current setup is without going to look
• Decide your invalidation rules before you need them — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If any of that sounds like a description of your current setup, it is fixable.