Mobile comparison of Top 11

March 14, 2011 8:01 pm | 7 Comments

A few weeks ago I announced Jdrop while at Webstock. After Webstock I took some vacation time on Waiheke Island. Now that I’m back I wanted to show how Jdrop is useful for doing mobile analysis.

Preamble

As a reminder, Jdrop is a JSON repository in the cloud. Jdrop itself doesn’t do anything specific for mobile analysis. But what it does do is provide a way to gather information from mobile devices and analyze it later from your desktop where you have more screen real estate. A bigger screen is important when you’re looking at things like document source and lists of resources.

The apps that integrate with Jdrop are what actually gather the data and do the analysis. Right now there are three main apps integrated with Jdrop (all of them are bookmarklets): Page Resources, Docsource, and DOM Monster. Rather than add each of these bookmarklets individually to your mobile browser, you can get them all just by adding my uber Mobile Perf bookmarklet.

Actual Analysis

Using the Mobile Perf bookmarklet I analyzed 11 top U.S. sites on the desktop (Firefox 3.6), iPad, and iPhone. On the desktop and iPad I used my Mom’s home wifi; iPhone was over AT&T 3G.

For each site and platform I gathered the following information:

• reqs – number of HTTP requests (from Page Resources)
• HTML – size of the HTML document (from Docsource)
• elems – number of DOM elements (from DOM Monster)

The overall results are interesting. The iPhone versions of these websites are about half the size of their desktop counterparts in terms of number of requests and number of DOM elements, but are 75% when it comes to the size of the HTML document. The increased relative size of HTML documents is an interesting artifact I explore later in this post. The iPad averages fall in between desktop and iPhone – not a surprise given its bigger screen but limited networking and processing power.

A recent feature added to Jdrop is the ability to make data public. I gathered all of this data using Jdrop and made it public which allows me to link directly to the raw data so you can see it as part of the analysis that follows. You can take a look at the Public JSON page on Jdrop and use the filter to search for any other data you’re interested in.

Let the analysis begin.

Google Search

Doing a Google search for flowers shows it has versions customized for the iPad as well as the iPhone. The iPad version is about 75% in size compared with the desktop version. The iPhone version, on the other hand, is much smaller than the desktop version: 30% as many requests, 75% of the HTML, and 60% as many DOM elements.

It’s interesting that the ratio of requests between the iPhone and desktop versions is so small but the ratio of HTML size is so high. My first guess was data: URIs. Using data: URIs would reduce the number of requests but increase the size of the HTML document. Sure enough, the iPhone document source has 68 images specified as data: URIs, whereas the iPad and desktop versions only have 10.

This is a great example of how the relevance of performance best practices differs between desktop and mobile.

We’ve known about data: URIs as a performance best practice for years. I first blogged about them back in April of 2007. But neither Page Speed nor YSlow have a rule that recommends using data: URIs. And yet here they’re used extensively for mobile by one of the the most successful websites in the world. Data: URIs might not be a high priority on the desktop where latency is lower and browsers can open more simultaneous connections, but they’re worth another look if you’re trying to speedup your mobile website.

Bing

The number of HTTP requests made for a Bing search for flowers is similar across desktop, iPad, and iPhone: 19, 19, and 16. The iPad version is slightly smaller than the desktop version in terms of HTML size (93kB vs. 59kB) and number of DOM elements (988 vs. 889).

The big surprise here is that the size of the iPhone HTML document. At 198kB it’s 2x bigger than the desktop version and 4x bigger than the iPad HTML size, even though its number of DOM elements is less than half of the other versions.

Why is the iPhone HTML document so much bigger than the desktop and iPad versions? This was a bit harder to figure out. My first guess was data: URIs, just like Google Search, but there aren’t any data: URIs in the Bing docsource for iPhone.

I had to unravel this one by looking at the actual response sent over the network. The easiest way to do that is to change my desktop browser user agent to iPhone. (I never do this the first time I’m analyzing a mobile website, but in this case I already have the docsource, page resources, and number of DOM elements, so I can make sure the version I get by changing my user agent matches what I originally received on my mobile device.) I was surprised to see that the size of the HTML document response is ~30K uncompressed (~9K compressed). So why does the Docsource bookmarklet report it as 198kB?

The Docsource bookmarklet uses the document.documentElement.innerHTML property. That property is ~198kB in length. So something is causing the ~30kB response to expand to ~198kB of HTML. Diffing the ~30kB network response with documentElement.innerHTML highlights calls to the RMS._load function:

_load:function(b){
    var a=null;
    if(localStorage)
        try{a=localStorage.getItem(b)}
    catch(c){}
    return a
}

Sure enough, if you clear your localStorage and repeat the search the network transfer size of the HTML document source is ~200kB. Some of the blocks of that HTML document are saved to localStorage so they can be retrieved from there on subsequent searches thus reducing the size of the HTML document. Very nice! You can study the Bing response and see how they structured various STYLE blocks to make it easy to extract that data and save it to localStorage.

Yahoo Search

In terms of HTML size and number of DOM elements, the iPad and iPhone versions of a Yahoo search for flowers are progressively smaller than the desktop version. The iPad version is about half of the desktop version, and the iPhone is less than a quarter of the desktop version.

Although the iPad and iPhone versions are progressively smaller than the desktop version in terms of HTML size and number of DOM elements, all three versions have about 24-25 HTTP requests. This is counter intuitive – one would think that the smaller screen sizes would have fewer requests. The bulk of these requests are images: the desktop page resources has 17 images, the iPad has 19 images, and iPhone has 15 images. So the iPhone does have fewer images, and those images are generally smaller.

The big difference comes in terms of CSS background images. Both the desktop and iPad versions have 1 CSS background image, compared with 7 for the iPhone version. The iPhone’s CSS background images contain two named “core-spring.png”. They have different version numbers (v=9 and v=12), but are similar. Two of the background images (“os_mag_glass.png” and “arrow_right2.png”) have similar images in “core-sprite.png”. Getting the iPhone down to 1 CSS background image, like the desktop and iPad versions, would eliminate 6 HTTP requests.

Wikipedia

Wikipedia’s “flowers” page is identical on the desktop and iPad. The iPhone version is smaller in all three categories. The number of requests on the iPhone is high – 27 compared to the average of 15 requests. Most of these are large images that aren’t visible in the initial page, but they are loaded before the window onload event. This isn’t a huge deal, but it does make page load measurements longer and can block more important resources like scripts at the bottom of the page. It would be better to load these images dynamically after the onload event.

Facebook

The Facebook login page was tested instead of a logged-in page to avoid differences based on user account. The desktop and iPad versions are almost identical. The iPhone version, on the other hand, is less than a quarter of the size of the others. How did they achieve such a reduction of HTTP requests – from 16 down to 4?

Comparing the desktop version’s page resources to the iPhone version’s page resources shows that the iPhone version is much lighter. The desktop version has 4 scripts, 5 stylesheets, 2 images, and 4 CSS background images. The iPhone version has 2 stylesheets and 1 image (plus the HTML document) – that’s it. If you visually compare the desktop and iPhone versions you’ll confirm that the iPhone UI is much simpler, thus explaining the big drop in number of requests.

Twitter

Twitter’s login page is about the same on desktop and iPad. The iPhone version is significantly smaller, especially in terms of number of HTTP requests. A visual comparison shows that the iPhone UI is much simpler than the desktop UI. Not only is the number of HTTP requests dramatically smaller, but the HTML document size is much smaller, as well. There are no data: URIs or calls to localStorage in the iPhone HTML, which keeps the HTML size so small.

Amazon

Amazon’s front page is the same on desktop and iPad. The iPhone version is significantly smaller:1/3 as many requests, an HTML document 1/10 the size, and 1/5 the number of DOM elements.

Although the iPhone version is much smaller, the number of HTTP requests could be reduced. The iPhone page resources shows it has 8 CSS background images. Running SpriteMe (yes, you can even run SpriteMe on mobile devices!) shows 3 of these could be eliminated by using sprites. And perhaps the logo, gold chest, and cart could be sprited, as well. A sprite image exists in the desktop page resources that contains the logo, cart, gold chest, and some of the gradients and arrows. Creating a similar sprite for mobile could drop the number of requests from 16 to 11.

eBay

eBay’s front page is similar to Amazon in that the desktop and iPad versions are identical. The iPhone version, on the other hand, is 1/2 to 1/3 the size. The size of the HTML document and the number of DOM elements is below the average (which is good), but the number of HTTP requests is higher than average (not so good).

In the 16 HTTP requests in the iPhone page resources there are10 images and 4 CSS background images. Of these, 4-8 look like good candidates for spriting. Alternatively, many of these images are small and could be inlined as data: URIs.

Craigslist

Craigslist is the same across all three platforms: desktop, iPad, and iPhone. The page is light so performance is not an issue, but the amount of content is visually overwhelming on the iPhone’s small screen.

(Just a funny side note: I tested this from my Mom’s house in North Carolina. Craigslist redirected me to the version for Jacksonville, NC which for some reason has a domain name based on the nearby town of Onslow. I just thought it was funny that my performance testing got sent to a URL starting with “onslow”.)

Yahoo Front Page

There are a few curiosities when comparing the desktop and iPhone versions of the Yahoo front page. The iPhone version has about the same number of HTTP requests and the HTML document is half the size, but the number of DOM elements is greater by ~20%. Although the iPhone version has fewer scripts, stylesheets, and CSS background images, it has 31 images compared to just 16 images in the desktop version. Many of these images are downloaded after the window onload event. It appears that they are being prefetched – they’re not visible on the screen so perhaps are used on subsequent pages.

The iPad version is dramatically smaller than both the desktop and iPhone versions. This is the only website where the iPad version is smaller than the iPhone version. Why would the iPad version be whittled down so much smaller than the iPhone version? The UI is very different. Perhaps there’s less prefetching happening, with less certainty of where the user may go next.

Youtube

There’s something interesting going on with the Youtube page. While the number of HTTP requests and DOM elements gets progressively smaller, the size of the HTML document on the iPad and iPhone is more than 2x larger than that of the desktop version. The iPhone version uses 6 data: URIs compared to the desktop version, but the biggest cause of the larger HTML document on iPhone is inlining JavaScript instead of fetching it from external scripts. Similar to the data: URI technique, this reduces the number of HTTP requests by embedding the resources inside the HTML document.

Conclusion

I hope you’ve found these mobile observations informative, but even more I hope you’ve seen that Jdrop is a useful mechanism for gathering, analyzing, and sharing mobile performance data. Take it for a spin, and if you have a tool, especially a bookmarklet, that does performance analysis contact me about integrating it with Jdrop.

7 Comments