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.


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:

Overall Averages
reqs HTML elems
desktop 31 110 kB 1166
iPad 28 86 kB 908
iPhone 15 75 kB 567

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

Google Search
reqs HTML elems
desktop 19 199 kB 1456
iPad 15 148 kB 1105
iPhone 6 149 kB 855

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.


reqs HTML elems
desktop 19 93 kB 988
iPad 19 59 kB 889
iPhone 16 198 kB 374

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:

    var a=null;
    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

Yahoo Search
reqs HTML elems
desktop 24 174 kB 2221
iPad 25 83 kB 967
iPhone 25 38 kB 387

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.


reqs HTML elems
desktop 47 121 kB 1642
iPad 47 121 kB 1632
iPhone 27 83 kB 1108

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.


reqs HTML elems
desktop 16 31 kB 524
iPad 16 29 kB 519
iPhone 4 2 kB 114

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.


reqs HTML elems
desktop 45 57 kB 873
iPad 61 55 kB 886
iPhone 3 12 kB 185

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.


reqs HTML elems
desktop 55 135 kB 1157
iPad 49 134 kB 1157
iPhone 16 11 kB 247

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.


reqs HTML elems
desktop 39 69 kB 934
iPad 39 64 kB 908
iPhone 22 24 kB 304

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.


reqs HTML elems
desktop 4 32 kB 1121
iPad 4 32 kB 1115
iPhone 4 32 kB 1115

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

reqs HTML elems
desktop 42 216 kB 1013
iPad 22 33 kB 473
iPhone 39 106 kB 1254

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.


reqs HTML elems
desktop 29 82 kB 895
iPad 15 193 kB 337
iPhone 5 193 kB 297

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.


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 Responses to Mobile comparison of Top 11

  1. Steve, another great post. Great work on Jdrop, and this post clearly points out there are differences in optimizing web performance for desktop vs for mobile. I like how Bing uses local storage. Further, why won’t people use more “DataURI” on the desktop? We have “DataURI” implemented in Yottaa product and it makes a big difference. Though desktop browsers can open more connections etc, saving the number of request is still worthwhile. Do you see any particular reason “DataURI” is not more widely used (besides it takes work to use it, and can’t indepdently cache these small objects)?

  2. I think it would be much less confusing if you mention that by “public” you mean “it’s behind a login page, but anyone with a google or twitter account that logs in can see the data”.

    Example: (rendition) and (raw JSON). JDrop is a good idea that would be even better still with clear messaging about what it is and isn’t. It’s not good for sharing data with casual site visitors that don’t care to log in, but it’s great for applications where there’s incentive to log in and that benefit from network effect of a large user base.

    (I assume that attributing data to logged-in users instead of allowing anyone anonymous read or write access adds some level of accountability and makes JDrop somewhat less prone to various classes of abuse, besides giving you a large degree of interest and behaviour tracking for users, should you want to.)

  3. @Coach: The main reason data: URIs aren’t used more is exactly what you mentioned – cacheability. Since HTML documents are typically not cached, and the data is in the HTML document, it means that data has to be sent with every HTML document. If the data is small (16×16 logo images) that’s not so bad, but for larger images as well as scripts and stylesheets the increase in HTML document size is costly. For sites that have a low number of page views per session and low sessions per month data: URIs make more sense, but if your users visit many pages many times the benefits of caching can be more advantageous.

    @Johan: That’s just a bug. You should be able to see the data without logging in. I’ll fix that today.

  4. The use of localStorage by Bing is interesting. Is BSI (Browser Side Includes) a new acronym, similar to SSI (Server Side Includes) or ESI (Edge Side Includes)? Are you going to write a future post with more details on that technique with best practices and gotchas, or is that an exercise left to the reader?

    I did find this link from 2004 that uses the term client side includes and leverages the fact that JavaScript is cached, and has inline script tags calling functions that document.write:

  5. Jacksonville is in Onslow County. The URL may be based on the county, not the town.

    Not sure, though, as it appears that where I live is rolled in with a city in the next county over…and I live in the largest city of a county that also contains a town with the same name as the county, and neither one is the county seat…

  6. Some insight on one of your findings:

    “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.”

    Makes sense. I would want to reduce as much overhead as possible and a majority of it comes from cost due to sheer number of requests. I can easily reduce that number by combining similar resources (JavaScript, CSS, some CSS images can be merged into CSS sprites, etc.) but can only do so much with actually compressing overall size. Works well enough for most, though.

    Very thorough article. Looking forward to reading more from you!

  7. check out the lycos mobile page as well. significantly smaller in comparison to their desktop home….and its fully ajaxified.