How to force the browser to reload cached CSS/JS files?

Question

I have noticed that some browsers (in particular, Firefox and Opera) are very zealous in using cached copies of .css and .js files, even be

Answer 1

Not sure why you guys are taking so much pain to implement this solution.

All you need to do if get the file's modified timestamp and append it as a querystring to the file

In PHP i would do it as:

<link href="mycss.css?v=<?= filemtime('mycss.css') ?>" rel="stylesheet">

filemtime is a PHP function that returns the file modified timestamp.

Answer 2

For ASP.NET 4.5 and greater you can use script bundling.

The request http://localhost/MvcBM_time/bundles/AllMyScripts?v=r0sLDicvP58AIXN_mc3QdyVvVj5euZNzdsa2N1PKvb81 is for the bundle AllMyScripts and contains a query string pair v=r0sLDicvP58AIXN_mc3QdyVvVj5euZNzdsa2N1PKvb81. The query string v has a value token that is a unique identifier used for caching. As long as the bundle doesn't change, the ASP.NET application will request the AllMyScripts bundle using this token. If any file in the bundle changes, the ASP.NET optimization framework will generate a new token, guaranteeing that browser requests for the bundle will get the latest bundle.

There are other benefits to bundling including increased performance on first time page loads with minification.

Answer 3

Say you have a file available at:

/styles/screen.css

your can either append a query parameter with version information onto the URI, e.g.:

/styles/screen.css?v=1234

or you can prepend version information, e.g.:

/v/1234/styles/screen.css

IMHO the second method is better for CSS files because they can refer to images using relative URLs which means that if you specify a background-image like so:

body {
    background-image: url('images/happy.gif');
}

its URL will effectively be:

/v/1234/styles/images/happy.gif

This means that if you update the version number used the server will treat this as a new resource and not use a cached version. If you base your version number on the Subversion/CVS/etc. revision this means that changes to images referenced in CSS files will be noticed. That isn't guaranteed with the first scheme, i.e. the URL images/happy.gif relative to /styles/screen.css?v=1235 is /styles/images/happy.gif which doesn't contain any version information.

I have implemented a caching solution using this technique with Java servlets and simply handle requests to /v/* with a servlet that delegates to the underlying resource (i.e. /styles/screen.css). In development mode I set caching headers that tell the client to always check the freshness of the resource with the server (this typically results in a 304 if you delegate to Tomcat's DefaultServlet and the .css, .js, etc. file hasn't changed) while in deployment mode I set headers that say "cache forever".

Answer 4

It seems all answers here suggest some sort of versioning in the naming scheme, which has its downsides.

Browsers should be well aware of what to cache and what not to cache by reading the webservers response, in particular the http headers - for how long is this resource valid ? was this resource updated since I last retrieved it ? etcetera.

If things are configured 'correctly', just updating the files of your application should (at some point) refresh the browsers caches. You can for example configure your web server to tell the browser to never cache files (which is a bad idea).

A more in-depth explanation of how that works is here https://www.mnot.net/cache_docs/#WORK

Answer 5

This question is super old, and appears first thing when anybody googles this issue. This is not an answer to the question the way op wants it, instead is an answer to devs with this problem while developing and testing. And i can't post a new question on this topic since will be marked as duplicate.

Like many others, i just wanted to remove caching briefly.

"keep caching consistent with the file" .. its way too much hassle ..

Generally speaking, I don't mind loading more - even loading again files which did not change - on most projects - is practically irrelevant. While developing an app - we are mostly loading from disk, on localhost:port - so this increase in network traffic issue is not a deal breaking issue.

Most small projects are just playing around - they never end-up in production. so for them you don't need anything more..

As such if you use Chrome Dev Tools, you can follow this disable caching approach like in the image below:

And if you have firefox caching issues:

Do this only in development, you also need a mechanism to force reload for production, since your users will use old cache invalidated modules if you update your app frequently and you don't provide a dedicated cache sync mechanism like the ones described in the answers above.

Yes, this info is already in previous answers but i still needed to do a google search to find it.

Hopefully this answer is very clear and now you don't need to.

Answer 6

I suggest implementing the following process:

• version your css/js files whenever you deploy, something like: screen.1233.css (the number can be your SVN revision if you use a versioning system)

• minify them to optimize loading times