CSS File Caching

Browser Caching of CSS files

Your file will probably be cached - but it depends...

Different browsers have slightly different behaviors - most noticeably when dealing with ambiguous/limited caching headers emanating from the server. If you send a clear signal, the browsers obey, virtually all of the time.

The greatest variance by far, is in the default caching configuration of different web servers and application servers.

Some (e.g. Apache) are likely to serve known static file types with HTTP headers encouraging the browser to cache them, while other servers may send no-cache commands with every response - regardless of filetype.

...

So, first off, read some of the excellent HTTP caching tutorials out there. HTTP Caching & Cache-Busting
for Content Publishers was a real eye opener for me :-)

Next install and fiddle around with Firebug and the Live HTTP Headers add-on , to find out which headers your server is actually sending.

Then read your web server docs to find out how to tweak them to perfection (or talk your sysadmin into doing it for you).

...

As to what happens when the browser is restarted, it depends on the browser and the user configuration.

As a rule of thumb, expect the browser to be more likely to check in with the server after each restart, to see if anything has changed (see If-Last-Modified and If-None-Match).

If you configure your server correctly, it should be able to return a super-short 304 Not Modified (costing very little bandwidth) and after that the browser will use the cache as normal.

Css file caching

Yes, adding a unique query string to the resource's URI will force the client to fetch a "fresh" version (since the client doesn't know that it's merely an update of a previously cached resource). This is known as fingerprinting and you typically use a timestamp or an incrementing version number¹ of the CSS file.

Google Web Fundamentals has a great article on HTTP cache optimization. Especially the section titled "Invalidating and updating cached responses:"

How do you get the best of both worlds: client-side caching and quick updates? You change the URL of the resource and force the user to download the new response whenever its content changes. Typically, you do this by embedding a fingerprint of the file, or a version number, in its filename—for example, style.x234dff.css.

Do note, that the fingerprint does not need to be a sequential number. Any value – hash, version, etc. – will do as long as the risk of collisions is limited.

¹⁾ This is what's done here on SO, e.g. http://sstatic.net/js/global-login.js?v=12

Preventing Caching of CSS Files

I've ran across this problem a few times and usually over come the problem on production sites by calling my css like this

<link rel="stylesheet" type="text/css" href="style.css?v=1" />

When you roll out an update just change the v=1 to v=2 and it will force all of your users browsers to grab the new style sheets. This will work for script files as well. If you view source on Google you will notice they use this approach as well.

Chrome will not cache CSS files. .js files work fine

I faced similar kind of issue and turns out to be web.config's compilation attribute was set to debug=true, as-

<compilation debug="true"></compilation>

It causes your files to neither be bundled nor cached on browser. Just removing debug=true resolved my issue. So I changed it to-

<compilation></compilation>

Edit-

For Chrome specifically, it could be related to your certificate.

Chrome does not cache resources from servers with self-signed certificate.

See here

Refresh CSS file in cache with ?version=XXX

When the file gets cached, it will be with the full url including the ? and stuff after it. The caching headers are supplied by the server and obeyed by the browser.

Essentially

file.css?version=DDMMYYYY

and

file.css

Are 2 separate files for the browser, with no connection what so ever.

My suggestion to you would be to use the new url consistently on all pages.

Browser loads JS files from cache, but not CSS files

Your server responded with different session cookie when requesting these css files, and your header set with Vary: Cookie, which caused the browser to send request again because of the session cookie change.