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

All: If you got here via a search, realize this is an old post (2008) and that Chrome now supports HTTP Pipelining and SPDY.  Thanks, smp.

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.

About these ads

7 thoughts on “Google Chrome: One thing we do know… (HTTP Pipelining)

  1. Mark Pauley

    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.

    Reply
  2. Stephen Pierzchala

    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.

    Reply
  3. Mark Pauley

    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.

    Reply
  4. Stephen Pierzchala

    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.

    Reply
  5. Zauber Exonar

    IIS 4 and 5 not supporting pipelining is no reason for it to be pulled from the RFC. Bear in mind: IIS is microsoft technology. And microsoft has a history of ignoring, twisting, or abusing standards. Especially when it benefits them. See J++ for a good example of the twisting/abusing concept.

    Reply
  6. Alex

    “Pipelining only works when the remote server supports it, if the remote server fails to pipeline then your page will actually load much slower.”Why would this be? I've never seen it be “much slower”, nor can I think of any reason this would be the case.”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.”That's the real reason nobody uses it: at best, it's much faster, but at worst, it fails horribly.

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s