Wednesday, May 26, 2010

Browser Cache - Your Friend and Foe

Because we use a ton of Static Content (e.g. Java Script, CSS, HTML) in our new application, the last few years I've been involved in dealing with Internet Browser Caches. We cache our Static Content locally so the users don't have to download it every time they hit our site. While this made us very fast, we were having perpetual problems with invalidating browser cache when Static Content files change.

We had a number of architectural meetings about it with a number of suggestions on how to deal with it. URL re-writing, ETAGs, unique file names were all brought up. What we ended with was a directory versioning scheme where we inject a unique number into the base URI path and then update an authority file that orchestrates the pages, injecting the unique number. During deployment the files are staged under the unique number on the web server file system.

If you look a look at Google's home page, you can see they do something similar. Here is a Java Script file they are including on their home page. Looks like they took the idea and put it on steroids to me.

Bing did something similar, but is more similar to what we do. Bing's number kind of looks like a TFS changeset number ;)

Since I've spent most of my life on the server side, I never realized how many gains you get from using Browser Cache effectively. Here are a couple of stats I took off our site while looking at the caching.

With the browser cache empty.
One 18.1 KB File = 172 MS

With the browser cache populated with the file.
One 18.1 KB File = 31 MS

I guess the lesson learned is using Browser Cache is great if you know enough on how to invalidate the cache when you need to push a new version of the code.