0

I'm a developer on a website which has a server which serves HTML and another server which handles API requests. I use a CDN to cache both the HTML and API responses. I feel that it gives me all the control I need while keeping the cache settings in one place. If I make a deployment of new website version I just invalidate the cache on HTML pages and API responses at the click of one button. I can also set different cache settings per certain pages/API routes.

That being said there're cache control headers for a server to notify the client for how much time a response is valid (e.g. max-age). I'm sure there may be use cases for the use of the headers (maybe if some extremely granular caching settings need to be applied based on some intricate business logic). Another advantage of using max-age for example is that browser can cache a response locally. However, if a CDN allows for 100 ms HTML response I don't think it makes a huge difference if a browser goes ahead and actually performs the request.

A big downside of using cache control headers in my opinion is:

  1. the complexity of maintaining cache settings all over the code base (no single point of truth like a CDN dashboard).
  2. When a new website version is deployed it is easy to add a new version hash/id to some header in API response so that the client may be issues with "old" frontend logic interacting with "new" API logic.

I'm wondering if using cache control headers is justifiable in the scenario I described (website with HTML and API servers) and what advantages outweigh the disadvantages I described?

Yos
  • 155
  • 1
  • 10
  • 1
    Use cache control headers when you want the client to cache the response for some period of time to reduce unnecessary calls to the server. It sounds like you are OK with having the client not cache anything, so you don't need to use the headers. – Dan Wilson Apr 28 '21 at 20:58

1 Answers1

2

Cache control headers put the client in control of caching. This is desirable when the data is static for assets like images, JavaScript, style sheets, etc. Client side caching was originally built for slow browsers, running on slow computers connected to slow networks.

Think back 25 years. Windows 95 was all the rage. An HTML file that takes 100ms to download and render now might have taken 15 seconds just to download back then — much less parse and render on screen. Caching things in the client could save you 15 seconds per request, which is huge. Client side caching was very much a product of the time: slow browsers; slow computers; slow networks, and a mostly static world wide web.

Now fast forward to today. I think the only static site on the internet is my old blog (for which I've long since forgotten the address). Everything is dynamic. Content. Images, even. Sites are updated frequently. Internet speeds are several orders of magnitude faster, as are computers and browsers. The combination of fast internet speeds, frequent site updates, dynamic content and fast computers and mobile devices has rendered client caching moot in most use cases. You save 100ms, not 10+ seconds.

Client side caching just doesn't have as much of an impact on performance for today's dynamic web sites.

If performance is good and a CDN is giving you better cache control, then it is a better tool for the job. No reason not to use it. No reason to use client side caching.

Greg Burghardt
  • 34,276
  • 8
  • 63
  • 114
  • 1
    On the other hand, consider if your users are on a metered connection (like a mobile plan with limited data). Those users might not like it if they use precious bytes to retrieve the same content over and over again. – Bart van Ingen Schenau Apr 29 '21 at 06:13
  • @BartvanIngenSchenau: Yes, you are correct. It all comes down to the use case for client side caching. The use case is slow connections, slow hardware, slow software. And as you pointed out, a new use case would be metered connections. Images and video are going to chew up the majority of that data, though. HTML, CSS and JavaScript can be compressed very efficiently. JSON/XML data from web services anymore is tantamount to dynamic data, so caching those responses is not beneficial, and could be accomplished by caching things in JavaScript. – Greg Burghardt Apr 29 '21 at 11:36