Getting started with a caching strategy
We end up explaining this on discovery calls often enough that it deserved writing down. A short on-ramp to a caching strategy for teams who have not touched it before.
Real-world numbers from actual visitors matter more than a score produced on a fast laptop. If it only works because one person remembers to do something, it does not work yet.
Why this earns attention
The fastest request is the one never made. It is worth being explicit about, because assumptions differ quietly. If two people in the business would answer this differently, that gap is the actual problem.
Your first week
- Find out what is already in place
- Cache static assets aggressively with fingerprinted filenames
- Change one thing and measure it
Decide your invalidation rules before you need them. This is the sort of thing that compounds, quietly, in both directions. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.
What this looks like day to day
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
- 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
Worth checking on your own setup before it becomes someone else's problem to fix.