HTTP Archive Mobile

May 13, 2011 12:30 am | 4 Comments

This morning during my talk at Mobilism I announced the HTTP Archive Mobile – a permanent repository for mobile performance data.

Ever since I announced the HTTP Archive (based on data gathered from Internet Explorer using WebPagetest) people have been asking, “What about data gathered from a mobile device?” It’s a logical next step. Thankfully, Blaze.io came on the scene a few months ago with a solution, Mobitest, for connecting to mobile devices and gathering this kind of information. Blaze.io has been doing great work in the area of mobile performance. I met Guy Podjarny, Blaze.io’s CTO, a few months ago and we’ve had several discussions about performance. A few weeks ago Guypo and I decided to start working on the HTTP Archive Mobile. It required a few changes on his side and a few on mine, but we quickly got it up and running and have been gathering data for the past week in anticipation of this announcement.

Here are some interesting comparisons of the Top 100 web pages from desktop vs mobile:

  • Total bytes downloaded is 401 kB for desktop vs 271 kB for mobile.
  • Total size of images, scripts, and stylesheets is smaller on mobile, but size of HTML is bigger. This is likely from JavaScript, CSS, and images being inlined in the HTML document – a good sign for performance.
  • The New York Times is in the top 5 pages with the most JavaScript with 230 kB on desktop and 326 kB on mobile – 94 kB more JavaScript on mobile than desktop.
  • The percentage of sites that have at least one redirect is 54% for desktop compared to 68% for mobile. Many websites (Facebook, Yahoo!, Bing, Taobao, etc.) redirect from www.* to m.* on mobile browsers. But it would be better to lower the mobile percentage since redirects inflict an even greater delay on mobile devices.
 

Total Bytes Downloaded Top 100 URLs from IE8
 

Total Bytes Downloaded Top 100 URLs from iPhone 4

This is just the beginning. The HTTP Archive Mobile is currently in “Alpha” mainly because we’re gathering data for just the Alexa Global Top 100 sites and only have a week’s worth of data. More URLs and more data are on the way. Already there are valuable takeaways from what’s there, and these will increase as the number of websites and length of time grow. Take a look for yourself and add comments below on anything you find that’s interesting or puzzling. And thanks again to Guypo and Blaze.io for making the Mobitest framework available for collecting the data.

4 Responses to HTTP Archive Mobile

  1. Kevin Kiley | 13-May-11 at 7:10 am | Permalink |

    Which Mobile Device(s) does this data suite represent?
    Was this data collected directly on the Mobile device(s)
    or was it gathered by ‘imitating’ Mobile User-Agent(s)
    from a Server application?

  2. Steve Souders | 13-May-11 at 7:21 am | Permalink |

    @Kevin: This data was gathered from iPhone 4.3. See the Blaze.io methodology page for more info. They also have Android available.

  3. Eitan Konigsburg | 18-May-11 at 8:21 am | Permalink |

    “The New York Times is in the top 5 pages with the most JavaScript with 230 kB on desktop and 326 kB on mobile – 94 kB more JavaScript on mobile than desktop.”

    Granted, the NYT homepage is very JS heavy. I just wanted to point out that the NYT homepage doesn’t do anything differently for mobile devices. It’s the same page. However, due to advertisements and changing content, two tests at different times can result in vastly different results. If you check the history graph of our page on mobile HTTP archive (http://mobile.httparchive.org/viewsite.php?pageid=588#trends), you will see numbers around the 230 kB range from earlier this month.

    I agree that the amount of JS on NYT pages is a performance issue, even more so on mobile, but I wanted to mention that the difference in the test results has nothing to do with mobile vs. desktop.

    We have the same difficulties when we do our own performance testing.

  4. Steve Souders | 19-May-11 at 9:06 am | Permalink |

    @Eitan: Thanks for replying! Yes, the variability of ads makes apples-to-apples comparison difficult. That’s exacerbated here because of the small sample size (3 page loads in a short period of time). I do notice ~40 kB of JS downloaded from graphics8.nytimes.com on mobile which explains part of the delta. But you’re right, the larger ad scripts on mobile are responsible for the bulk of the size increase.