How to get a caching strategy right
The version of this that works is simpler than the version most people imagine. The short answer to a caching strategy is that it is mostly a sequence of small decisions, not one big one.
Real-world numbers from actual visitors matter more than a score produced on a fast laptop. Write the reasoning down alongside the decision, because the reasoning is what changes first.
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 the sort of thing that looks like polish right up until it costs you an enquiry.
The steps
- Establish what you have today before changing anything
- Cache static assets aggressively with fingerprinted filenames
- Decide your invalidation rules before you need them
- Write down the decision so the next person does not re-litigate it
Decide your invalidation rules before you need them. The teams that handle this well are rarely the ones with the biggest budgets. Write the reasoning down alongside the decision, because the reasoning is what changes first.
Turning this into a decision
The short version
Speed is a feature people notice only in its absence, and then they leave rather than complain. Three things worth confirming about a caching strategy before you move on:
- Someone can say what the current setup is without going to look
- The fastest request is the one never made — and you know whether that is true here
- There is a way to tell whether the last change to this helped
If you are not sure where your systems currently stand on this, it takes us about an hour to find out.