Anatomy of a mobile web experience: google.com
In a recent blog post that I did here on mobiForge (Server-side device detection used by 82% of Alexa top 100 sites) some people expressed surprise that a 47 byte difference in the HTML payload delivered by Google to different devices constituted a significant level of server-side adaptation. On checking my results, it turned out that this minor 47 byte file size difference actually masks an entirely different HTML document served to different devices—an approach that Google use extensively in its mobile presences.
This discussion led us to understand that people probably don't realise just how extensively server-side adaptation is used by the major internet brands in order to fine-tune the user experience for each platform. To help shine a light on this I'm going to look at the approaches that some major brands use in delivering their mobile web experiences. First up, it's Google.
These following screenshots, taken at the approximate resolution of the real device, show how google.com looks on three popular phones. You can browse the device properties on DeviceAtlas here: iPhone, BlackBerry Curve, Nokia 6300. For convenience I'm using the 320x480 resolution of the first 3 generations of iPhone here, not the 640x960 screen of the iPhone 4 and 4s.
The following table shows some of the key differences between the
versions of the same page served up to different devices on visiting
google.com. In my particular case I get redirected to google.ie since
I'm based in Ireland but the
same approach is used across all of the Google entry points for each
|iPhone||BlackBerry Curve||Nokia 6300|
|HTML size (Kb)
|Images size (Kb)
|Total page weight (Kb)
|No. of HTTP requests||9||2||2|
||HTML5||HTML 4.01||XHTML Mobile|
|Media queries utilized||✗||✗||✗|
This extensive server-side adaptation continues once you are served
a set of search results, though at this point some of the differences
more visible. Google presents a much richer set of results for iOS and
Android phones than it does for the Nokia 6300 and BlackBerry.
Disappointingly, Google chooses not to include a tel: link for the
Nokia and Blackberry, even though both devices support this feature
just as well as Android and iOS.
So what are the lessons to be learned here? The first point is that
delivering an optimum mobile experience to a wide range of devices
requires some tuning to match the document served with the device
making the request—cosmetic rearrangements of elements on the page
not pass muster.
Secondly, this level of device adaptation is impossible to achieve after the fact on the client side, with the same base HTML document presented to each device—many of the decisions that Google have made here require server-side adaptation. This ability to cater for a much wider range of devices is unique to server-side adaptation, because only what is strictly needed for each type of device need be sent.
Finally, in keeping with Google's philosophy of delivering
as fast as possible, all of the heavy lifting for this adaptation is
done server-side before anything is delivered to the client—no
additional client-side code or queries are required to run before the
user sees the rendered page.
In order to probe a website to see if it delivers different user experiences for different mobile devices you need to replicate the HTTP headers sent by the real device as far as possible. These headers are used by sites to determine the best content to return in response to the device's request. The most important of these headers is the User-Agent header but to fully replicate a real device you need to send other headers also, since sites may have adaptation logic that triggers on these too. Apart from the User-Agent header, the most significant headers are the Accept and x-wap-profile.
In all cases I was not logged into Google and I stripped all cookies
to ensure each device was treated individually.