A caching strategy: the questions we get asked most

This is cheap to get right at the start and expensive to retrofit. The questions about a caching strategy that come up most often on our calls.

Real-world numbers from actual visitors matter more than a score produced on a fast laptop. It is the sort of thing that looks like polish right up until it costs you an enquiry.

Do we need to care about this?

The fastest request is the one never made. This is the sort of thing that compounds, quietly, in both directions. If two people in the business would answer this differently, that gap is the actual problem.

Can it wait until after launch?

Occasionally. More often the post-launch version costs several times the pre-launch one. The cost of getting this wrong is rarely visible on the day it happens.

How do we know it is working?

Decide your invalidation rules before you need them. That sounds obvious written down. It is still the thing most often skipped. It is the sort of thing that looks like polish right up until it costs you an enquiry.

How to tell if yours is fine

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

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