Google Chrome: One thing we do know… (HTTP Pipelining)

In: Technology| Web Performance| WebPerformance.Org| Work

2 Sep 2008

As a Web performance consultant, I view the release of Google Chrome with slightly different eyes than many. And one of the items that I look for is how the browser will affect performance, especially perceived performance on the end-user desktop.

One thing I have been able to determine is that the use of WebKit will effectively rule out (to the best of my knowledge) the availability of HTTP Pipelining in the browser.

HTTP Pipelining is the ability, defined in RFC 2616, to request multiple HTTP objects simultaneously across an open TCP connection, and then handle their downloads using the features built into the HTTP/1.1 specifications.

I had an Apple employee in a class I taught a few months back confirm that Safari (which is built on WebKit) cannot use HTTP Pipeling for reason that are known only to the OS and TCP stack developers at Apple.

Now, if the team at Google has found a way to circumvent this problem, I will be impressed.

Spread the Love:
  • Facebook
  • Twitter
  • Ping.fm
  • Digg
  • StumbleUpon
  • LinkedIn
  • Reddit
  • Slashdot
  • Netvouz
  • Identi.ca
  • Technorati
  • del.icio.us
  • email

Related Posts

  • You're wrong. Chrome could pipeline, nothing in Webkit prevents this. Chrome doesn't use the CFNetwork loader nor does WebKit marry the browser to any given network / HTTP stack, just look at the code. The reason Chrome doesn't support pipelining is likely to be the same reason that no other browser pipelines out of the box: pipelining is broken. Pipelining only works when the remote server supports it, if the remote server fails to pipeline then your page will actually load much slower. This is the case with IIS 4 and 5 which are common enough to cause concern. Also it turns out that some mods to Apache don't pipeline properly, resulting in garbled output. The ultimate solution will be a compromise as is seen with the fledgling 'support' for pipelining in Firefox's HTTP stack which is off by default.
  • Cool. Now, if it's not supported by anyone, it should get pulled from the RFC. And now that the browser engines are almost all abstracted from the browser that wraps around them, maybe it's time to look at what works to make browsers and content delivery faster.
blog comments powered by Disqus

About this blog

Stephen Pierzchala is one of a 10-year veteran of the Web performance field who also writes on topics that interest his non-linear world-view.

Contact

stephen@pierzchala.com

+1 (508) 410-3865