All: If you got here via a search, realize this is an old post (2008) and that Chrome now supports HTTP Pipelining and SPDY HTTP/3. 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.
2009-06-30 — 18:52
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.
2009-06-30 — 22:29
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.
2009-07-01 — 00:52
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.
2009-07-01 — 04:29
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.
2010-03-01 — 04:09
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.
2010-03-16 — 20:50
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
2010-07-13 — 18:08
“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.