We cache too much

2 min read RSS
Make it load faster.

Make it load faster.

As developers we over-engineer by nature. Caching is one of the clearest examples. Something's slow? Add a cache. Still slow? Add another layer.

Good intentions

It's well-intentioned, we're trying to reduce origin hits and speed things up but every layer adds complexity and serves stale responses that are difficult to debug. Sometimes we do this to ourselves knowingly and other times without realising.

Next.js is a good example. Out of the box we're dealing with 4 distinct caching layers, all active by default. That's a lot of layers to reason with, especially when all you wanted was for a CMS change to show up on the page.

Compare that with a framework like Astro, where there's no framework-level cache to manage. Your strategy is just a CDN in front and a webhook to purge on publish. One layer, one job. Astro isn't inherently better but when there's less caching to fight, there's less to go wrong.

Worth the trade-off?

A cache or CDN absolutely has its place. Static assets, images, fonts, we know it's good to cache them aggressively. But for dynamic content is an extra origin call really going to hurt? A modern e-commerce frontend pulling structured content from a headless CMS is going to respond in hundreds of milliseconds at most. If it's not, the problem is usually the query or the infrastructure and a cache is just a band-aid.

The question is whether a few hundred milliseconds saved is worth the complexity of managing invalidation and debugging stale responses.

The discipline

The pattern is always the same. We add layers to improve things, and at some point the layers become the problem. Turning off all caching layers and understanding where the actual slowdown is before reaching for a cache is a good starting strategy.

Liked this article? Give it a