HTTP Pipelining – Big in Mobile

HTTP pipelining is a performance optimization that is often overlooked due to its low adoption rate – only the Opera browser uses it by default on desktop .

However, on Mobile HTTP pipelining has a much higher adoption rate – at least the Android and Opera browsers employ it, accounting for about 40% of mobile browsing! In this post we’ll explain what is pipelining, how is it used by the browsers, and what you as a web developer should do about it.

HTTP pipelining has been around for quite a while – since HTTP/1.1 was introduced. When using pipelining, an HTTP client may send multiple requests on the same connection, without waiting for the server to respond. Doing so practically eliminates the round-trip time (RTT) overhead of all but the first request, especially if the server responds quickly.

HTTP pipelining can certainly accelerate many websites, as recently demonstrated by Brian Pane. Unfortunately, due to various issues and challenges most major desktop browsers chose not to support HTTP pipelining (or not to enable it by default). Only Firefox and Opera support it, and only Opera enables it by default – less than 2% of total desktop browsing.
In Mobile, HTTP pipelining is an especially interesting opportunity for two reasons:

  1. Mobile networks have a much higher latency on average.
    This makes the value of avoiding extra RTTs greater
  2. Mobile browsers and websites are newer
    As such they tend to get more attention and be more innovative.

And indeed, HTTP pipelining has a much higher adoption amongst mobile browsers. Opera Mini*, Opera Mobile and the Android browser all use HTTP pipelining by default. Together they account for about 40% of mobile browsing. If you’re developing a mobile site, your site is experiencing HTTP pipelining daily, and you should understand how it works.

* Opera Mini uses a proxy to make most requests to the server, and the proxy uses pipelining to make those requests.

The bottom line

Before we dive into details, here’s the final list of HTTP pipelining support. The different columns are explained in the following sections.

Windows Desktop Browsers Supports Pipelining? Server Support Detection Max pipelined requests Max connections per host
IE 9 No - - 6
Chrome 12 No* - - 6
Safari 5.1 No - - 6
Opera 11.5 Yes Per Host 5 6
Firefox 5 Yes (Off by default) Per Connection 4 6

* Logged as an enhancement request since March, 2009

Mobile Browsers Supports Pipelining? Server Support Detection Max pipelined requests Max connections per host
MobileSafari No - - 6
Blackberry No - - 5
Android Yes* Per Connection 3* 4*
Opera Mobile Yes Per Host 11 4
Opera Mini Yes** Per Host 4** 10**

* Details are for “stock” Android. Specific devices varied greatly.

** The stats are for the Opera Mini proxy, as the browser makes very few requests itself

Server Support Detection

The browsers who chose to support HTTP pipelining use heuristics to determine whether the server they’re communicating with supports it as well. The first request to every server is sent by itself (only one request on the connection), and the browser looks for two properties in the response:

  1. Use of HTTP/1.1
  2. An explicit “Connection: Keep-Alive” header (required by Android)

If those are not present, requests will be sent without HTTP pipelining. This validation is done per host for Opera Mini, Opera Mobile and Opera Desktop, and per connection for Android and Firefox.
Support per connection means the first request on a connection is always sent by itself (no pipelining). If the response showed the server supports pipelining, multiple requests may be pipelined on that connection.

Figure 1

Figure 1 shows a network capture of Android Pipelining Connection on www.amazon.com. Note the first request “validates” the connection, followed by piped requests.

Support per host means that once the first request showed the server supports pipelining, all future connections will use pipelining immediately. Opera Mini, Opera Mobile and Opera Desktop all use this approach.

Figure 2


Figure 2 shows a waterfall chart from Opera. Note that all the resources on the page start at once, once support has been established by the fetching of the page itself.

Recovery On “Connection: Close”

When using pipelining, the server may always close the connection before all requests are fulfilled. For example, if requests 1 and 2 are sent on the same connection, the response to request 1 may include a “Connection: close” header. In this case, the browser will honor the close instruction and close the connection, without a response to request 2, and resent request two on a different connection.
It’s worth noting that getting such a “Connection: Close” will not make Opera stop using pipelining on that host, even if all future requests come back with such a “close” header.

Max Pipeline Requests

Since pipelining creates a queue of requests, browsers set a limit on how big the queue can get. This helps mitigate the risk of many requests getting delayed by one slow response (dubbed “head-of-line blocking”). All the browsers we tested preferred opening a new connection to pipelining (until reaching their max connections limit). Additional requests will then be piped on existing connections, until all connections reach their max. Remaining requests will wait in the queue.

The algorithms browsers use for distributing pipelined requests will be covered in a subsequent post.

Android Varies Greatly by Device

Android’s versatility made it very hard to predict whether and how pipelining is used. All the devices that supported pipelining maintained the same logic for determining Server Support, but the number of connections and max pipelined requests were very different. Even pipelining support in general wasn’t constant.

Android Device OS Version Supports Pipelining? Max Connections Per Host Max Connections Max pipelined requests
Nexus S 2.3 Yes 4 4 3
Galaxy S 2.2 Yes 12 12 6
XOOM 3.0 No 6 35 -
Simulator 3.1 Yes 4 4 3

The Nexus S and the simulator likely indicate the way Android was meant to behave. However, Motorola opted to modify the XOOM, adding many connections and disabling HTTP pipelining. Samsung took the opposite direction, and while they also increased the number of connections, they doubled the number of pipelined requests. Figure 3 shows Samsung Galaxy S piping 6 requests at once.

Figure 3

It’s hard to say which values would be ideal, but the variability in Android definitely makes it hard for website owners to optimize for the entire platform. This may be the result of the different hardware specs being tuned for different settings, or just a symptom of the experimentation phase Android seems to be in. We hope that eventually a more consistent behavior will surface.

Seeing as Google is likely the biggest promoter of making the web faster, it’ll be great if they shared the research that made them choose the initial numbers. Doing so may help convince the manufacturers to stick to it, and will help website owners to optimize accordingly. After all, it’ll probably take some time before most of the web switches to SPDY.

I’m A Mobile Website Developer – What does this mean for me?

If you have a mobile website, HTTP pipelining is a part of your reality – whether you like it or not. You should make sure you support it, and try to tap into the performance opportunity it presents.
Here are some specific recommendations:

  1. Make sure your web infrastructure supports HTTP pipelining.
    If it’s not extremely old, it probably does.
  2. Use “Connection: Keep-Alive” to leverage pipelining.
    Make sure to include an explicit “Connection: Keep-Alive” header for Android.
  3. Serve slow (dynamic) resources from a different domain than fast (static) ones.
    With pipelining, multiple requests may get delayed by one slow response.
  4. Use Domain Sharding carefully (or not at all) for browsers that support pipelining
    Opening more connections is more costly than pipelining (especially on Mobile), and Android relies on pipelining so much it opens very few connections.
  5. Test your site.
    For desktop, download and run Opera and enable Firefox pipelining.
    For mobile, tools like http://blaze.io/mobile/, simulators and more can help.
Posted on July 26th, 2011
  • Stephan

    Mhh, The referenced stats for mobile browsing are strange: iPhone has now a lower share than Dec 2008? http://gs.statcounter.com/#mobile_browser-ww-monthly-200812-201107

    • Anonymous

      Since the use of mobile browsing grew dramatically over these three years, and more players joined the market, this actually makes sense to me. I’m sure the actual number of users browsing with iPhone grew since 2008, but as Android grew it took much of the iPhone market share. You can see the Android line in those stats quickly growing in that time span. 

      That said, we don’t collect the stats… They’re not perfect, but they’re the best stats I’m aware of for browser and specifically mobile browser usage.

  • David Berg

    Thanks for the informative article.  As someone in the mobile and application performance space for a long time,  I can attest to the effectiveness of strategies like this for improving performance over high latency and loss connections that are unavoidable with mobile devices.
    My only (rhetorical) question is, why isn’t everyone doing this?

  • Willy

    Having Android rely on “Connection: keep-alive” is bogus, this header should never be emitted in HTTP/1.1 as keep-alive is the default. This means that Android will basically only do pipelining with HTTP/1.0 hosts which were upgraded to 1.1 and which still emit the header, but not with native 1.1 speakers. Too bad…

  • James

    Apple seems to be adding pipelining to Webkit recently, so I would be very surprised if we didn’t also see pipelining show up in Mobile Safari. (Maybe it is already in iOS5?)

    • Anonymous

      There’s some interesting changes in iOS 5 related to this, but I can’t discuss them publicly due to the Apple iOS developer NDA. If you have access to the apple forums (meaning you’ve signed that NDA yourself), you can see my thoughts here: https://devforums.apple.com/thread/117646

  • Pingback: phonydev.com » Mobile performance advice

  • Pingback: Mobile Performance Manifesto | David B. Calhoun – Developer Blog

  • Guilherme

    I did some tests and i didnt get the expected results.
    I used the test of this site with Galaxy S. The page loads 62 images.

    Do you know the reason?

    The first test, Keep Alive
    http://www.softwareishard.com/har/viewer/?inputUrl=http://www.blaze.io/gethar.php%3Fharid%3D111103_AB_3P0

    The second, not
    http://www.softwareishard.com/har/viewer/?inputUrl=http://www.blaze.io/gethar.php%3Fharid%3D111103_JD_3PM

    Thanks.
    Guilherme

    • Anonymous

      I just checked again, and Galaxy S does use Pipelining on the keep-alive page. I couldn’t attach the full network capture, but I attached a screenshot showing it. You can also do a network capture on your server (assuming you have access to do that), or contact me via the contact@blaze.io email and I’ll email it to you.
      Also note that Galaxy S opens 12 connections, and Android verifies pipeline support for every connection, so even with 62 images it won’t pipeline 6 on every connection. I think you need something like (6+1)*12=84 images to trigger that, and even that’s assuming the network conditions don’t tweak things.Lastly, the HAR formats are not the best for presenting Pipelining, I don’t believe it was contemplated when they were designed, given the low usage of pipelining on desktop.

  • http://www.geeknik.com/ geeknik

    I’ve had pipelining enabled in Firefox on the desktop for years (not officially supported yet) and to be honest, I can’t tell a difference when it is on or off. Probably isn’t that big of a deal on the desktop where network connections are relatively stable.