HTTP Pipelining Benchmark Firefox 16

In my earlier post I suggested enabling HTTP Pipelining to boost page load time performance in Firefox 16.0.2 and I figured it was important to also do some “real world testing” so I did exactly that by loading five times with the cache cleared each time using a benchmark tool while having HTTP Pipelining on and off.

These are the results and as you can see except for the first run HTTP Pipelining proved to result in faster page load times than having it off which is the default in Firefox.

Firefox HTTP Pipelining Benchmark

With everything from Firefox OS, Chrome Canary, Chromium Dev, Safari iOS, Chrome Mobile and Opera having HTTP Pipelining enabled why is it that Firefox for Desktop should not follow suit?


  1. ZoubIWah says

    How does one reproduce the test ? (is there a global timer in firefox somewhere we can enable?) thanks!

  2. Michael says

    Do you have something that confirms it’s enabled by default in desktop Safari and Chrome? I thought it was only on in mobile by default…

    Last time I saw it discussed, I think the main obstacle to turning it on by default was proxies which don’t follow the standards (while claiming that they do, so that browsing is completely broken and the user can’t tell why).

    • says

      I have corrected that… Its just Safari for iOS and Chrome Dev Channel… But Opera does have it…. Firefox OS has it and Chrome Mobile has it and all of those products are widely used especially if you consider the amount of iPhones sold alone.

      • Michael says

        Yes, but both that fact, and your testing, are not taking into account the variety of network setups on PCs. The issue isn’t so much whether it works with websites, as such, but whether it works through the huge and varied collection of proxies and network security things that desktop Firefox sits behind.

        Safari for iOS and Chrome mobile are widely used, but they’re not used on the desktop so it’s not really comparable. Opera isn’t widely used on desktop either.

        Thanks for correcting the post though.

  3. Anonymous 2358 says

    This is a terribly inadequate benchmark. Five runs on one site is practically meaningless for what you’re trying to prove. And besides, isn’t representative of popular sites which might exhibit great benefits from pipelining. Try something with more JavaScript and images — Amazon and eBay are better choices. And don’t forget to disable SPDY.

    You should also be asking a fundamental question: Why is your first benchmark run much slower than the subsequent runs?

  4. says

    Despite pipelining can avoid a lot of RTTs spent in sending GET commands to fetch resources on several web sites (that’s the improvement you’re seeing in here), the risk HoL blocking [1] and finding ways to avoid them in a lot of other situations and web sites is a hard problem to resolve.

    That’s why pipelining isn’t enabled by default. So, downloading a web page can be faster in some sites, but it also can be very slow in others.




    • says

      I know about HoL Blocking but I also know the IETF in 2011 issued a draft on HTTP Pipelining Enhancements that addresses HoL Blocking and the other known Deployment issues. Notably its clear that these hurdles are not extreme to the point that it is impossible to deploy in production considering the adoption by various other browsers.

      • says

        Ok, didn’t know that. Do you have a link to the draft document? I’d like to analyze the improvements.

        Anyway, in the HTTPbis WG seems HTTP/2.0 is moving forward to improve the situation.

        Thank you

  5. Caspy7 says

    I’m curious, will it be slower on the first run of every site (or page maybe)?
    If that’s the case then it could overall slow down browsing as the majority of pages I go to I’ve not been to before.
    I understand this is a simple conclusion, but it’s based on limited data.