Monthly Archives: August 2012

Revisiting User Agent Strings

I will start by pointing out that I will not spend time any time discussing the historic value of User Agent strings (also referred to as Browser IDs). A few sites have done it rather well (MSDN, MDN).

In this day and age, we optimize everything from our JS and CSS files to HTTP and image requests. We use tools that compress images better (or strip bytes off it). I propose an optimization that has been over-looked for years, for one reason or another!

For every single request made in this world via a browser, the browser adds a User-Agent header in the request, yes, every single time!

Mozilla/5.0

My first jab is at “Mozilla/5.0”. Is it still 1995? No. Then why are we carrying this “legacy” with us. Personally, I believe it is there so whenever a new developer asks why its there, it gives the senior developer an opportunity to re-live and re-tell the story of Browser Wars!

So, without any delay, lets look at what exactly is being sent by the famous browsers:

(For sanity, I’m not including IE6, IE7 or IE8 but trust me, they are VERY long!)

Internet Explorer 9 32-bit (70 bytes):
Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)

Internet Explorer 9 64-bit (75 bytes):
Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)

First stop, Internet Explorer. I just do not understand why I’m seeing the “compatible” string even though I’m not running in compatibility mode. But according to Microsoft, “it indicates that Internet Explorer is compatible with a set of common features”. Umm, what common features? We’ll never know. I also find it fascinating that Internet Explorer tells which 64-bit CPU you are using (that x64), Intel or AMD. What I just love is that really useful “feature” disappears for Internet Explorer running on “Windows Phone 7”! Oh come on… I would love for my Windows Phone to shout to the world what’s my CPU!

Firefox 13 (74 bytes):
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0.1

Second stop, Firefox. See something repeating? Yep, that is the version of Firefox, in this case, 14.0 that is repeated twice. Why? Because Gecko version is kept the same as Firefox since Firefox 5. Then you might think what is “20100101” there for? I won’t bother trying to explain as things get really confusing really fast, specially considering that for mobile browsers this is same as the Firefox version (Whaaat??) Just head over to Mozilla for a dose of confusion as I’m starting to think they might even not know why it’s there to begin with, or how it helps someone by putting this info in a UA String.

Opera 12.01 (100 bytes):
Opera/9.80 (Windows NT 6.1; WOW64; U; Edition United States Local; en) Presto/2.10.289 Version/12.01

Opera does something that no one else does. They have actually dropped “Mozilla/5.0”. Which is my proof that the internet does not come to a halt when you remove it! Dead proud of it but my happiness doesn’t last long! For some reason Opera tells everyone, “Hey, its Opera 9.80” but then at the end, confesses its 12.01. I would love to argue about why it could’ve been better handled but there’s something else I want to point out. That “U”!!! Its an encryption identifier that has become obsolete since 1996! If that’s not enough, for some reason Opera is telling everyone that its “Edition United States Local”, which I assume means “it’s” a United States edition. How does it help anyone is beyond my limited thinking! I’m in the UK, and I doubt it’ll change if I was in France. That “en” is a two letter language code for English. I hope Opera is not telling everyone that I’m running a US English Edition of Opera, because I do not see how it can help the server serve me the right “content”, or someone needs to tell Opera that there is an “Accept-Language” header that they should use.

Safari 5.1 (106 bytes):
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/534.57.2 (KHTML, like Gecko) Version/5.1.7 Safari/534.57.2

Chrome 21 (106 bytes):
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.60 Safari/537.1

Lastly, Chrome and Safari, I’ll rant them together, well because Chrome just copies what Safari does. First, Safari and Chrome tell everyone, “Hey, its KHTML” but then they say, “Tell you what, we’re like Gecko”. I also think since the project is called “WebKit”, it should not be “AppleWebKit” but I don’t want to start a fan boy war. What I find fascinating with Safari’s version is that they use WebKit’s version right after Safari. And then create a separate declaration for “Version” which is actually for Safari. Go figure!

Operation Clean Up

My proposal is to simplify the damn thing. And here it is:

[Browser Engine]/[Version] ([OS]; [Architecture/Others]) [Browser]/[Version]

And the new User Agent strings will look like:

Internet Explorer 9 32-bit (44 bytes):
Trident/5.0 (Windows NT 6.1; WOW64) MSIE/9.0

Internet Explorer 9 64-bit (38 bytes):
Trident/5.0 (Windows NT 6.1) MSIE/9.0

Firefox 6 (53 bytes):
Gecko/20100101 (Windows NT 6.1; WOW64) Firefox/6.0.2

PS: Someone needs to tell Gecko team on how to do versions.

Opera 12.01 (50 bytes):
Presto/2.9.168 (Windows NT 6.1; WOW64) Opera/12.01

Safari 5.1 (51 bytes):
WebKit/534.57.2 (Windows NT 6.1; WOW64) Safari/5.1.7

Chrome 21 (56 bytes):
WebKit/537.1 (Windows NT 6.1; WOW64) Chrome/21.0.1180.60

Savings?

Let’s take example of Yahoo!. Its a pretty optimized website but it makes 80 HTTP requests. Lets see how it pans out in terms of savings:

Browser Current Proposal Savings
Size per Request Size for 80 requests Size per Request Size for 80 requests
IE 32-bit 70 5600 44 3520 -37.14%
IE 64-bit 75 6000 38 3040 -49.33%
Firefox 13 74 5920 53 4240 -28.38%
Opera 12.01 100 8000 50 4000 -50.00%
Safar 5.1 106 8480 52 4160 -50.94%
Chrome 21 106 8480 56 4480 -47.17%

* All numbers are in bytes.

Just to re-iterate. This information is not cached, not zipped, and sent every single time! For every single page request. Imagine the amount of bandwidth we can save on mobile devices! Just imagine…

Flattr this!