A fast response is not useful when it delivers an outdated version of the truth.
Speed often depends on remembering yesterday
Caching is one of the most useful ideas in software.
Instead of rebuilding a page or requesting the same data every time someone visits, a system keeps a prepared copy and serves it again.
That makes websites faster, reduces pressure on databases and lowers infrastructure costs.
Most of the time, visitors benefit without ever knowing it is happening.
The problem begins when the saved copy is no longer the truth.
The content was new. The response was old.
During our recent publishing investigation, two new Insights had already been published in Sanity.
Their individual URLs worked.
But the main Insights page still showed an older collection of articles. The sitemap also continued listing an earlier set of URLs.
The website was functioning.
It was simply functioning with outdated information.
That made the problem harder to recognise. Nothing had crashed. There was no obvious error message. The system was confidently returning the wrong version.
More than one cache may be involved
Modern applications can cache information in several places.
A page may be generated ahead of time and stored.
A data request may return a previously saved result.
A content delivery network may keep its own copy near the visitor.
The hosting platform may still be serving an earlier deployment.
Looking at only one layer can therefore give an incomplete answer.
In our case, both the Insights listing and the Sanity query used to create it needed attention. The sitemap had similar behaviour.
Fixing only one part would not have made the publishing process dependable.
Caching needs a freshness strategy
Caching itself was not the mistake.
The missing piece was a clear rule for when the stored information should be replaced.
For content that changes only during deployments, static generation may work perfectly well.
For scheduled publishing, however, the website must be able to recognise that new content has appeared after the last build.
That may involve:
- timed revalidation;
- CMS webhooks;
- targeted cache invalidation;
- dynamic requests;
- or a deliberate no-store strategy.
The right choice depends on how quickly the information must become visible and how much traffic the system handles.
We chose reliability first
For the Insights listing and sitemap, the immediate priority was simple:
Newly published content had to appear without waiting for another deployment or an old cache to expire.
Those surfaces were changed to request current Sanity data rather than depend on an earlier stored result.
That slightly reduces the performance benefit of caching, but it removes uncertainty from scheduled publishing.
For a modestly trafficked company website, dependable visibility was more valuable than saving a small number of requests.
Performance is not only about speed
A page that loads instantly but shows yesterday’s information is not performing well.
Good performance includes:
- speed;
- correctness;
- freshness;
- availability;
- and predictable behaviour.
Caching should support those outcomes, not quietly compete with them.
Engineering Lesson
Caching is valuable when the rules for freshness are understood.
Without those rules, an optimisation can become a source of invisible failure—serving old information quickly and consistently while everyone assumes the system is current.
