UA switching: be careful
At least once a day I’m in a conversation, email thread, or twitter exchange about monitoring websites. Lately this has focused on mobile. Tools like WebPagetest make it easier to monitor websites from the perspective of a desktop browser, but doing this from the perspective of a mobile device is still a significant challenge.
This issue is a current topic of discussion around HTTP Archive Mobile. Blaze.io supports the project through its Mobitest framework: every two weeks I submit 1000 URLs to their framework which downloads each URL 3 times on a real iPhone. I love that the resultant waterfall chart and screenshots are gathered from a real phone. But our next step is to scale this up to 100K and then 1M URLs. It’s going to be hard to scale up to this using real phones due to cost and maintenance issues.
Another alternative is to use an emulator. The timings won’t be identical to the actual mobile device, but HTTP Archive Mobile is more focused on HTTP headers, size and number of responses, etc. These structural aspects of the page should be identical between the actual phone and its emulator. We’ll soon do side-by-side tests to confirm this.
But this post is about a third alternative: UA switching. Changing the User-Agent string of a desktop browser to mimic a mobile browser and using that to gather the data could be accomplished this afternoon. The issue is that the results might differ from what is seen on an actual phone. Websites that don’t do anything special for mobile would probably be similar enough. And websites that look at the UA string on the serverside to determine how to alter the page would also be okay. But websites that adapt the page based on browser feature detection on the clientside, e.g. responsive web design, would differ dramatically.
When asked for an example of such a site I recalled seeing Scott Jehl at Breaking Development Conference talking about the recent launch of Boston Globe using responsive web design. It’s an amazing feat of engineering. Its adaptability from a single code base across so many devices is beautiful to watch in this promo video.
Because the Boston Globe uses responsive web design, the UI varies depending on the browser – not the UA string. Here’s a screenshot from my iPhone. The content has been modified to fit on the iPhone’s smaller screen.
Figure 1. iPhone browser
Figure 2 shows the Boston Globe as rendered inside Chrome on my laptop. Since the screen is much bigger the content is laid out quite differently compared to the iPhone. We see three columns instead of one, a wider horizontal navigation bar, etc.
Figure 2. Chrome
Figure 3 is also from Chrome, but in this case I changed the User-Agent string to mimic an iPhone:
Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_3_1 like Mac OS X; en-us) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8J2 Safari/6533.18.5Even though the UA string says “iPhone”, the page is laid out exactly as it is for normal Chrome. (I confirmed the UA string by inspecting HTTP headers.)
Figure 3. Chrome with iPhone User-Agent string
Responsive web design is fairly new. There are still a number of websites that modify the HTML layout based on serverside UA detection. In fact, while generating the screenshot for Figure 3 I tried several other websites and most of them returned a layout customized for iPhone.
If you’re working on a framework to monitor mobile websites, be careful about taking the UA switching approach. If the websites you’re monitoring do serverside UA detection, you’ll probably be okay. But if the web app is based on clientside feature detection, the results you receive from UA switching won’t match what is seen on real mobile devices. As the adoption of responsive web design increases so will the number of websites that fall into this gap of mismeasurement. Real devices or emulators are a safer bet.
Andrew Hedges | 28-Sep-11 at 9:32 am | Permalink |
I guess your caveat depends on what you’re testing. I’m guessing the Globe returns 90+% the same content (e.g., not serving things like Flash ads to iPhone) no matter the UA string and relies on CSS to show/hide various features. If you’re monitoring for content changes, that might be OK.
Thomas | 30-Sep-11 at 9:22 am | Permalink |
Hi Steve,
How do you change the User-Agent in Chrome?
Steve Souders | 01-Oct-11 at 8:52 pm | Permalink |
@Andrew: Yes, if the site is the same for all clients then it doesn’t matter. However, if it does change based on the client then if it does clientside feature detection changing the UA will likely not capture those changes.
@Thomas: Use the -user-agent commandline option.
Ville | 03-Oct-11 at 5:29 am | Permalink |
Resizing the browser to match the size of the iPhone screen gives similar layout for both sites. As Andrew mentioned, the site probably relies on CSS media queries to change the layout.
As the iPhone (and a lot of other mobile browsers) are based on webkit, would it be possible to write a Chrome extension that would make the browser capabilities match more closely with iOS browser? It could never make them match exactly, but get it at least closer by disabling plugins and removing features not supported by iOS Safari (for example, webworkers).
Steve Souders | 03-Oct-11 at 10:01 am | Permalink |
@Ville: It would be easier & more accurate to use the emulator than trying to make Chrome act like an iPhone. FYI – this spreadsheet compares # of requests and total bytes transferred for the Top 1000 websites on iPhone 4.3 vs the simulator. The averages are very close. Some individual sites differ significantly, but that’s mostly due to variances in the site from hour-to-hour (ads, etc.).
Gerben | 05-Oct-11 at 11:12 am | Permalink |
Beside resizing your browser, you could also change the BOM (Browser Object Model) a bit with JS (greasemonkey) to even more accurately simulate mobile.
e.g. change the screen properties like this:
Screen.prototype.__defineGetter__(“width”, function() { return window.innerWidth }); (Do the same for height, availWidth etc.)
The same can be done for window.navigator, and with a bit more work window.matchmedia(). No need for complicated extensions, just simple JS.
Tony | 07-Oct-11 at 6:35 am | Permalink |
One of the biggest chalenges with Mobile Web development and testing is that there are no stand alone browser emulators for the different mobile OS. For example for Android you have to download the entire SDK and launch the OS emulator to get to the browser.
Stev – you are at a perfect poisition to push companies like Google, Apple, and Microsoft to release standalone mobile browser emulators – this way we can properly test in our own computers!
Diaa | 11-Oct-11 at 12:07 am | Permalink |
here’s a firefox addon to change User-Agent
https://addons.mozilla.org/en-US/firefox/addon/useragentupdater/
Irakli Nadareishvili | 11-Oct-11 at 6:54 am | Permalink |
Steve,
thanks for a great blog post.
I definitely share your belief in Responsive Design and call for caution regarding user-agent-based switching.
That said, for full fairness it should also be noted that due to current fragmented state of web (Esp. mobile web) browsers, non user-agent-based, media query-driven Responsive design only goes so far.
There’re two major problems that I am aware of:
1. Not all browsers support media queries. An important example that comes to mind would be [somewhat] older versions of Blackberry that may still be important target audience esp. internationally.
2. Performance optimization. Typically static assets like: Javascript, CSS, Images and video/audio appropriate for high-bandwidth desktop browsing and for [often] low-bandwidth mobile browsing are different. Server-side detection can allow the level of optimization that can not currently be achieved by just media queries or is hard to achieve.