The real cost of ignoring a caching strategy

The version of this that works is simpler than the version most people imagine. Nobody bills you for neglecting a caching strategy. The cost shows up somewhere else.

Real-world numbers from actual visitors matter more than a score produced on a fast laptop. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

Where the cost lands

• Time spent on work that should not have been necessary
• Enquiries that quietly never arrive
• The fastest request is the one never made
• Rework, once the problem is finally visible

Cache static assets aggressively with fingerprinted filenames. There is a version of this that is over-engineered, and it is worth avoiding. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

What to do next

Decide your invalidation rules before you need them. The cost of getting this wrong is rarely visible on the day it happens. It rarely shows up as a line item, which is exactly why it slips.

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
• 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.