Pixelastic

Here are some quick notes on various browser caching behavior. I was fiddling with Wireshark to optimise my caching strategy and found some quirks one should be aware of.

First, let's define some reload vocabulary.

• initial load is the first time the page is loaded, when the cache is empty.
• hard reload is the classical reload. Clicking the Reload icon, or pressing Ctrl+R / F5.
• link reload is when the page is loaded again after you click on a link to it
• soft reload will be loading the page again by pressing enter in the address bar
• navigational reload is the reloading of a page that occurs while using the previous/next buttons.

For the rest of this blog post, we will assume an HTML page loading the same .jpg file multiple times and the same swf file multiple times too (we will use both IE specific and general swf markup).

The html itself is not cached.

Also, all those static assets will have a Cache-Control:max-age=29030400 header.

All the network tests have been made using Wireshark.

Chrome

Initial load : Download of jpg and swf once each. Perfect.

Link reload & navigational reload: Nor jpg nor swf is loaded again. Perfect.

Soft reload & hard reload : The jpg is downloaded again but not the swf. Chrome sends a Cache-Control:max-age=0 header to the jpg request, to force loading it again.

Reloading images is a standard behavior on images, but I wouldn't have expected it on soft reloads.

Safari 5 Win

Safari behaves much like Chrome, with one important difference. It does not cache swf files at all.

Initial load : The jpg gets downloaded perfectly, but the swf gets downloaded multiple times, one per instance.

Link reload & navigational reload : The jpg is correctly fetched from cache, but the swf are all downloaded again. No swf is ever cached.

Soft reload & hard reload : Much as Chrome, Safari forces the reload of the jpg here. As you might guess, it also reload all the swf too, multiple times.

It means that Safari 5 does not cache any swf file at all. That's pretty impressive.

This same caching bug is talked about on this other blog. I've also tried including flash files from within another flash file (much like the Satay method). The results are the same : no swf flash is ever cached, even in the same html request.

It is supposed to have been fixed in Safari Mac (anyone can confirm this? I don't own a Mac) but the issue is still here on Safari Windows.

IE6, IE7 and IE8

IE6, IE7 and IE8 behaves the same here. They have a less severe version of the bug than Safari 5. At the time of writing I didn't have IE9 to test on it.

Initial load : Same bug as Safari here. The swf are downloaded multiple times, once for each instance. The jpg is only download once.

Link reload, navigational reload and soft reload : This time, everything is fetched from the cache. Actually, even the html is seems fetched from cache (I didn't investigate that much)

Hard reload : Html and jpg are fetched from the server, swf file stays in the cache.

It appears that (surprisingly) IE behaves quite well. Its caching behavior is more aggressive than the others (soft reload is really soft). However, it still have a nasty side effect of loading swf files multiple times on the same page. Shouldn't happen a lot in the real world, but still nice to know.

Firefox 4.0

Initial load : No issue arising. It does fetch each resource once.

Link reload, navigational reload and soft reload : Fetches everything from cache, nice.

Hard reload : Re-request jpg and swf files by adding a Cache-Control: max-age=0 request header. This feels like the expected behavior.

 

You may have seen the Pragma:no-cache response header on various website (if you're that kind of guy actually reading HTTP response headers...).

What you may not know is that this Header doesn't actually exists. The Pragma header is supposed to be Request header, not a Response header.

It is not only useless, it may also trigger strange caching bugs in IE6. I'm sure you know what kind of IE6 quirks I'm talking about. The best is to remove it, just to be sure.

This is a common misconception (I myself didn't know that before reading this excellent caching tutorial), and that header is still returned in a lot of request.

For example, if you set your session.cache_limiter to nocache in your php.ini, then PHP will send this header (as defined in the session_cache_limiter doc. This is obviously wrong.

It also adds a weird Expires: Thu, 19 Nov 1981 08:52:00 GMT header. I don't like it as it allow easy fingerprinting of the server-side technology used.

I changed my session.cache_delimiter value to private_no_expire to return better headers.
First, it removed the useless Pragma, but it also removes the Expires header (Cache-Control is enough).

Yesterday I moved this domain from one server to another on my Dreamhost account (actually, I moved the whole domain from one Dreamhost account to another, but that's the same).

The DNS saved at the registrar where the same (ns1.dreamhost.com, ns2.dreamhost.com and ns3.dreamhost.com). The transfer went seamlessly and I was able to access my website on the new server in an invisible way.

But, strangely, some hours laters I started to experience slow down when accessing the website and finaly all my requests timed out, be it either from Firefox or a direct ping.

I tried with my windows xp and my Ubuntu 8.04. I even change the DNS on xp to use opendns, run an ipconfig /flushdns, rebooted. On Ubuntu I've done a /etc/init.d/dns-clean start. I even rebooted my adsl box, thinking there was something wrong with the DNS cache on my side.

I even contacted both Dreamhost and Gandi with a complete traceroute to know if they could help me, as I thought having done everything that I could think of to resolve the issue. They assure me that their configuration was fine and the problem wasn't on their side.

When asking friends, or testing with http://downforeveryoneorjustme.com/ it occured that the problem really was on my side.

Everyone were true. The problem lied somewhere in between, in the DNS cache hold by my ISP that wasn't correctly up to date. I don't really understand how that could happen, I thought rebooting my Freebox would clear its cache, and specifying dns addresses of opendns would bypass the dns resolve of my ISP but it seems not to be the case.

Anyway, after waiting for some more hours, my website was again reachable through ssh and ftp.

So, if you're sure your dns configuration is correct both on your register and on your hosting service, make sure to clear every DNS cache you can have on your own side. That include windows inner dns cache, those of your browser, those of your router, and those of your specified preferred DNS resolving server.

If all that failed, it should be caching issue with your ISP, and there is nothing you can do about that, except waiting.