Five mistakes teams make with a caching strategy

Most teams know this matters. Fewer have decided who owns it. These are the ones we run into repeatedly when we audit a caching strategy.

Performance work is mostly subtraction, which makes it unpopular and effective. Assume whoever inherits this will have half your context and none of your patience.

Warning signs

• Treating it as a launch task rather than an ongoing one
• Assuming someone else already owns it
• The fastest request is the one never made
• Cache static assets aggressively with fingerprinted filenames
• Never checking whether the fix actually worked

Decide your invalidation rules before you need them. The teams that handle this well are rarely the ones with the biggest budgets. Doing this properly once is usually cheaper than doing it approximately three times.

A reasonable first step

How to tell if yours is fine

Real-world numbers from actual visitors matter more than a score produced on a fast laptop. 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.