When I deploy the version I will add the number as query string with the JavaScript and CSS file like following?
'app/source/scripts/project.js?burst=32472938' I am using the above to burst the cache in the browser.
But in Firefox, I am getting the latest script that I have modified. But in Chrome, I am not getting the latest script that I have modified. Instead of that I am getting the old one.
But in developer console, I am seeing the burst number which is modified in latest.
5 Answers
Answers 1
According to the Google documentation, the best way to invalidate and reload the file is to add a version number to the file name and not as a query parameter:
'app/source/scripts/project.32472938.js'
Here is a link to the documentation:
https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching#invalidating_and_updating_cached_responses
Another way is to use an ETag (validation token):
https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching#validating_cached_responses_with_etags
Here is how you would set up an ETag with Nginx:
http://nginx.org/en/docs/http/ngx_http_core_module.html#etag
And lastly, a tutorial about browser caching with Nginx and ETag:
https://www.digitalocean.com/community/tutorials/how-to-implement-browser-caching-with-nginx-s-header-module-on-centos-7#step-2-%14-checking-the-default-behavior
Answers 2
I'm uncertain of whether this still applies these days, but there were some cases in the past where proxies could cause a query-string value to be ignored for caching purposes. There's an article from 2008 that discussed the idea that query-string values weren't ideal for the purpose of breaking caching, and that it was better to revise the filename itself -- so, referencing project_32472938.js instead of using the query-string.
(I've also seen, in places, some discussion of unusual cases where certain clients were not seeing these updates, but it seemed to be inconsistent -- not tied to Chrome, necessarily, but more likely tied to a specific installation of Chrome on a specific machine. I'd certainly recommend checking the site on another computer to see if the issue is repeated there, as you could at least narrow down to whether it's Chrome in general, or your specific install of Chrome that is having problems.)
All that said, it's been quite a while since 2008, and that may not be applicable these days. However, if it continues to be a problem -- and you can't find a solution to the underlying problem -- it at least offers a method use to circumvent it.
Answers 3
I don't think that Chrome actually causes the problem, because it would break almost all web applications (eg: https://www.google.com/search?q=needle)
It could be that your deployment was a bit delayed, eg.
- Start install new scripts
- Check with Chrome (receives old version on new ID)
- Install finishes
- You try with Firefox (receives new version)
- Chrome still shows old version because it cached the old script with new ID
Or you have a CDN like Azure between your web server and your browser.
With standard settings Azure CDN ignores the query string for the caching hash.
Answers 4
try those meta tags:
<meta http-equiv="cache-control" content="max-age=0" /> <meta http-equiv="cache-control" content="no-cache" /> <meta http-equiv="expires" content="0" /> <meta http-equiv="expires" content="Tue, 01 Jan 1980 1:00:00 GMT" /> <meta http-equiv="pragma" content="no-cache" /> Answers 5
i not sure , but for try...
google crome always ignore it..
you need to add a '?random.number' or "?date.code" to every link each time a url is pressed on your website. eg if 'myhomepage.html?272772' is stored in the cache, then by generating a new random number eg 'myhomepage.html?2474789', google chrome will be forced to look for a new copy.
0 comments:
Post a Comment