2

I use Axios for my AJAX requests in my Vue components and noticed that (after page refresh) requests to cached endpoints were being sent to the server instead of hitting the cache if they were called from the mounted hook. Every other request was hitting the browser cache correctly.

I had two (different) requests being dispatched from the mounted hook and when I moved the second request inside the .then() of the first request it started hitting the browser cache.

What causes this behaviour? How can I have page data loaded from the cache inside the mounted hook?

Edit: This behaviour is seen in Firefox. Pasting the request URLs in a new tab loads the data from the browser cache correctly. I've still not found a solution to force the requests to respect the cache control in the Vue code inside the mounted hook.

wrkyle
  • 529
  • 1
  • 13
  • 36
  • Does this answer your question? [Is Chrome ignoring Cache-Control: max-age?](https://stackoverflow.com/questions/11245767/is-chrome-ignoring-cache-control-max-age) – tao Jan 10 '21 at 06:56
  • In short: an easy way to check if cache-control works correctly is to copy/paste the URL in a new tab, instead of hitting Refresh. But, here's the thing: when you're checking that cache-control works correctly, you're actually testing Google Chrome developers' work, not yours. It's the same mistake as testing Vue in your unit tests, instead of testing inputs/outputs (a.k.a: your work). – tao Jan 10 '21 at 07:04
  • I don't see a solution here. I'm also seeing this behaviour in Firefox. – wrkyle Jan 10 '21 at 07:13
  • I did notice that pasting the GET URL in a new tab loaded the data from the cache properly. Still not sure how to force these requests to respect the cache control in situ. – wrkyle Jan 10 '21 at 07:16

1 Answers1

2

tl,dr;
To properly test client-side caching for a page, copy/paste the URL in a new tab instead of hitting F5.

why?

What happens when a user hits Refresh is not entirely up to you, as a developer. It's also up to the browser manufacturer.

If you're looking for a way to forbid a browser to load fresh data when it already has a version which, according to your cache-control server-side settings, is still valid, there isn't one.

It's up to the browser manufacturer to guess what the user really wants and to provide it. On average, when the guess is correct, their market share goes up. When wrong, it goes down. For obvious reasons, you have no say in it.

You should also consider the vast majority of site owners do not know how to tweak cache-control and don't bother paying someone to do it for them, so they just go with defaults. So, in order to keep their users happy, browser manufacturers need to guess correctly when the user wants the content refreshed, even if the server says it's fresh enough.

In other words, you can't enforce client side caching (but you can server-side!). You can only suggest it. If the browser manufacturer has reason to believe the user wants a "Clear cache and hard reload" but is not tech-savvy enough to perform it, they'll perform it on simple Refresh.

Chrome, based on large amounts of usage data, tries to guess what's the "primary cache" for a page and what is "secondary cache". It tries to balance providing fresh content (by wiping out primary cache for that page) with doing it in a timely manner (by not wiping out secondary cache). I believe any resource loaded by more than one page on the same domain is marked as "secondary" although I'd guess the algorithm is smarter than just that.

Firefox, as far as I know, doesn't have multiple types of refresh, so if the user hits refresh all cache for said page is gone.

tao
  • 82,996
  • 16
  • 114
  • 150