Google Chrome: One thing we do know… (HTTP Pipelining)
Jan 24 2012: Big Update. Chrome 17 will have pipelining. More info here.
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.
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.
Mark Pauley
June 30 2009 at 18:52
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.
Stephen Pierzchala
June 30 2009 at 22:29
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.
Mark Pauley
July 1 2009 at 00:52
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.
Stephen Pierzchala
July 1 2009 at 04:29
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.
Zauber Exonar
March 1 2010 at 04:09
Great post, Thanks,You can test pipeline using this free HTTP pipeline tool and test the response return from the web when sending different HTTP Get or post with pipeline:http://soft-net.net/SendHTTPTool.aspx
roy554
March 16 2010 at 20:50
“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.
Alex
July 13 2010 at 18:08