One of my great “ah, ha!” moments in Application Delivery came when I was reading a post about compression by F5’s Lori MacVittie. At the time, I was with my previous employer and was considering starting a project to implement compression. When I began discussing it with others, I was told that certain versions of IE had issues with compressed data, even though they sent headers saying they accepted gzip. Since our customers were long term care facilities and could feasibly have older technologies, it wasn’t crazy to think they’d be browsing using pre-IE6 and might have problems. Since our principle rule in IT was to “First Do No Harm,” I didn’t want to cause a negative experience for some users simply to speed things up for others. My mistake at that time was that I made a blanket assumption about all users. I decided that because I shouldn’t compress content for older browsers, I couldn’t compress at all. In Lori’s article, she talks about how compression isn’t always advantageous – especially over a LAN. Prior to reading the article, I really hadn’t considered all the information users were giving me and even better, that I could make decisions based on that information.

When a user visits a website, their browser sends a number of “HTTP-Headers” (An incomplete list). A great example of an HTTP Header, is “User-Agent.” In this header, the web browser informs the site it’s visiting what type of browser it is.

Google Chrome, for example, sends “Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.1 (KHTML, like Gecko) Chrome/6.0.428.0 Safari/534.1″

With this information, a website owner can decide to treat certain browsers differently than others.

An iPhone, for instance, might send something like”HTTP_USER_AGENT=Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1C25 Safari/419.3”

Some sites do an excellent job of leveraging this information to provide a better user experience. If you go to certain sites with an iPhone, you might notice yourself being redirected to m.example.com, or mobile.example.com or another “mobile-specific” site specially designed for a mobile device. Users obviously appreciate this since it keeps them from constantly having to zoom in and out and scrolling just to see the pages. While many companies create iPhone apps for situations like these, that doesn’t help people who have other mobile devices, hence the requirement for a mobile-specific site. One thing you’ll likely noticing when visiting mobile-specific sites is that it’s not simply the same content with a different resolution – it’s typically different menus, buttons, and fewer images. Since most iPhone browsing is being done via a cellular network, it’s good to consider latency as an experience inhibitor.

Using Lori’s example of providing compression only when it improves the user experience, we can apply the same logic to users with the iPhone user-agent header. On an F5 device, for instance, we’d create an iRule to be executed on HTTP_Request events that would look at the user-agent header and if it contained “iPhone,” we’d either send a redirect so the user would go to our mobile site, or compress data more aggressively, or even both. Using my own example of trying to compress data without causing issues for older browsers, I wouldn’t want to compress simply because a browser sent the “accept-encoding gzip” header – I’d really want to make sure I’m only compressing for user-agents I know can handle compressed data so it’d be a combination of both the “user-agent” and “accept-encoding gzip” headers. I often run into sites that, while being smart enough to detect my user-agent and make decisions based on it, provide a negative experience. For example, here’s the text I see when I navigate to a certain site using Google Chrome –

Please Upgrade Your Browser
To provide you with the most efficient experience, (removed)
utilizes advanced browser features of Internet Explorer 5.0 and greater.

Your Internet browser does not meet the minimum criteria.
Please download the latest version of Internet Explorer.

I’m obviously using one of the most capable browsers on the market, and this particular site not only says it won’t support me, but it also says I’d be better off with IE5. The only “saving grace” is that they provide a link through which I can download a browser they do support. Unfortunately, I’m stuck at this page and am not seeing any of their site’s content. Better behavior would be that I make it to their home page, am informed of the features the site doesn’t think I support, and can make a decision on whether I’d like to move forward. This site is obviously looking at the user-agent header, but is unfortunately making a blanket decision that because mine doesn’t contain IE, I’m not compatible. When this logic was written, Chrome didn’t exist. This behavior requires the logic to adapt constantly to new browsers. In this case, the site might be better off looking for headers that determine whether the browser supports the specific features required by IE.

Another interesting thought that popped into my head on the drive home yesterday was the type of inferences you can make about the person behind specific user-agents. If, for instance, I’m using Chrome to visit your site, I’m likely an advanced user who cares about new technology – do you really want to tell me that your site doesn’t support me and that I’d be better off with IE5? How about if I’m visiting your site with an iPhone – what does that say about me?

I’d love to see some of the analytics data comparing something like “conversion rate” for retail sites among different browsers. I imagine very few people purchase from their phone but I expect that quite a few of them are comparing prices – if that’s the case, it might make sense to have pricing readily available on your “mobile-specific” site.

Advertisements