A caching strategy: what to get right first

Teams tend to reach for this after something has already gone wrong. If you only fix one thing about a caching strategy this quarter, make it the first item below.

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.

Start here

The fastest request is the one never made. It is worth being explicit about, because assumptions differ quietly. Budget a little time for it every quarter and it never becomes a project of its own.

Then this

Cache static assets aggressively with fingerprinted filenames. Where this goes wrong is almost never a lack of knowledge. Write the reasoning down alongside the decision, because the reasoning is what changes first.

Eventually

Decide your invalidation rules before you need them. None of that requires a large budget, only a decision and someone to own it. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

How to tell if yours is fine

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
• Cache static assets aggressively with fingerprinted filenames — and you know whether that is true here
• There is a way to tell whether the last change to this helped

None of this needs a rewrite. Most of it is a morning's work once someone decides to do it.