4

For like the last 5-6 years I have designed all my web projects so all front-end resources like javascript files are fetched as little as possible from the server

So I have used expires headers on the webserver with 1 year expire. On the front-end I have added the version in the query string like this

<script src="my_js_file.js?v=323"></script>

But recently I have experienced that Goole Chrome has become more strict about it, so you have to clear the browser cache to update your javascript files if you don't change the version in the query string like ?v=4939. But sometimes it looks like it doesn't always update the cache anymore even if the version is added by one

Is this a bug in chrome or a new "feature" to make the internet "faster"? If it is, this is a shit feature which doesn't let you control your versions of a website anymore

update

This is not a problem for me while developing the site but for the users of the website.. The cache is not updated when a new version is released

Community
  • 1
  • 1
clarkk
  • 27,151
  • 72
  • 200
  • 340
  • on mobile, there is a "save bandwidth" option, where the website is proxy-processed (we need a better word for that) so you get a cached version of the website, wich probably is less updated than the original one. on desktop, updating the same website over and over again does do something alike, check using incognito and you should get a fresh cache. – LordNeo Jan 27 '17 at 20:17
  • also on devtools->network enable the "Disable cache" feature if you're developing websites or disable the expire headers on your server while developing the website. – LordNeo Jan 27 '17 at 20:19
  • just for clarity, is there any service like varnish between the webserver and the client? since those types of services could handle a older version of the html file causing this kind of issue. – joaumg Jan 27 '17 at 20:23
  • there is no caching after the webserver – clarkk Jan 27 '17 at 20:32
  • 1
    If you're changing the query string, it's a *different url* - the browser cannot cache a url it has not yet been to. – Aaron Cicali Apr 25 '17 at 05:11

4 Answers4

2

Since some browsers doesn't acknowledge changing query string as a new file, do like this instead

<script src="my_js_file.3.2.3.js"></script>

Edit

Google suggest: you do this by embedding a fingerprint of the file, or a version number, in its filename—for example, style.x234dff.css.

Here are a couple of posts that might be useful, with some more explanations/sample/guides:

Asons
  • 84,923
  • 12
  • 110
  • 165
1

In absence of either an official confirmation or a reproducible example proving the opposite, I'd assume what is already stated in a comment here above

If you're changing the query string, it's a different url - the browser cannot cache a url it has not yet been to

So I'd look for another root cause. Now, notice what the OP is saying:

It's not a problem for me but for the users of the website

That matches with my experience of this issue: actually it is a deploy issue. That can happen if:

  1. the page with the fake parameter (version number, hash, etc..) is moved to production first, while the new version of the .js script is delayed (for a few minutes)
  2. in the meantime some users browse the web page, so their browsers cache the new version number in the paramenter, still pointing to the old .js script
  3. when the new .js is finally overwritten in production, it is too late because those user browsers have already memoized the new call.

The solution is to ensure that the new .js is deployed to production before the updated version of the page that is calling it.

Btw, notice - as pointed out in the answer of @LGSon and in other comments like this one - that a query parameter could cause a cache miss, but this is the opposite problem, not the one described in the question, namely of stale data in cache.

  • Well, the problem is **not** a _deploy_ issue, unless you make it one, by not publish updated files at the same time you change their references. And doing so put you at risk for worse issues than caching, e.g. added functionality that lacks unpublished methods etc. – Asons Nov 11 '19 at 12:44
  • Who is using a deploy solution that make it possible to _fake parameter (version number, hash, etc..) is moved to production first, while the new version of the .js script is delayed_ ? ... that sounds like suicide. – Asons Nov 11 '19 at 15:14
0

Chrome has indeed been caching more aggressively in recent versions.

With devtools open, refreshing works as it used to (a few times to clear). Chrome seems to remember everything with devtools closed.

Aaron Cicali
  • 1,496
  • 13
  • 24
0

For testing/debugging purposes, CTRL+F5 forces a "hard refresh" which clears the cache. For your users' sake, you'll need to change the version number as @LGSon says, but that's a huge pain for debugging.

Sean Kendle
  • 3,538
  • 1
  • 27
  • 34