Ideally, in my opinion, when the browser makes a request for example.com/something the server should send a continuous stream of data. It could work something like this:
1) The browser sends the request along with a list of files it already has cached (maybe a special type of cache that never expires so the browser would know that it wouldn't need that file ever again).
2) Then web server sends the actual HTML that needs to be rendered, followed by whatever files the browser may need (css, js, images, etc). The browser would know where the HTML block starts and where other pieces begin, so from its point of view it's the same as if it requested those pieces. The difference is that the server anticipates these requests and sends them along all in one batch. The very first piece would be a list of files the server is sending, so the browser would know what to expect. At the end of the stream, if there are any more files that are needed that haven't been included in the main stream, the browser would just request them as usual.
Doing something like this would effectively render most page accesses to a single request, going from 10 or more requests to a single request would have quite a bit of an impact. For this to work though, both the browser and server would need to support such a feature...
Yes. HTTP/1.1 arranged for this with pipelining 11 years ago.
But there were servers that thought they supported pipelining and had corruption issues, so the clients got scared and wouldn't use it. (Besides, the modems on the edge of the web were the problem, not the latency.) Then the proxy people said "Why bother? No one uses it.", and the clients continued to not implement it, or did but left it off by default with a switch to turn it on in a disused lavatory, behind the "Beware of the Leopard" sign. Meanwhile, the server people having run out of useful and useless features to add to their vast code bases actually got around to making pipelining work correctly.
Welcome to 2010.
• Most popular web servers support pipelining, probably correctly.
• <1% of browsers will try it.
• Proxies (firewall and caching) largely break it.
• If you are using scripts that can change the state of the web server, then your head might explode when you consider what happens with pipelined requests.
Pipelining is not enough even if the internet infrastructure was perfect. Why?
1. Slow requests stall the entire pipeline.
2. The initial request stalls the pipeline.
3. The pipeline is being pulled instead of pushed so your performance is still roundtrip-lag-bound if you have cascading references. For example an HTML file references a .css file which references PNG costs 3 round trips at least.
True, if latency dominates that much in your situation, which can happen with no congested pipes in the path. An HTML5 "manifest" with pipelining would take care of all but the initial and 2nd latency.
SPDY is definitely implemented in Chrome/Chromium, though I don't know if it's on by default. I believe at least some google services (google.com in particular) support it publicly as well.
You basically just described HTTP pipelining, which has been part of HTTP for over a decade.
The main problem is that somebody might have installed some broken proxy in the middle that doesn't understand HTTP pipelining. That is why browsers usually disable it by default. The second problem is that sometimes it is faster to open multiple parallel connections.
1) The browser sends the request along with a list of files it already has cached (maybe a special type of cache that never expires so the browser would know that it wouldn't need that file ever again).
2) Then web server sends the actual HTML that needs to be rendered, followed by whatever files the browser may need (css, js, images, etc). The browser would know where the HTML block starts and where other pieces begin, so from its point of view it's the same as if it requested those pieces. The difference is that the server anticipates these requests and sends them along all in one batch. The very first piece would be a list of files the server is sending, so the browser would know what to expect. At the end of the stream, if there are any more files that are needed that haven't been included in the main stream, the browser would just request them as usual.
Doing something like this would effectively render most page accesses to a single request, going from 10 or more requests to a single request would have quite a bit of an impact. For this to work though, both the browser and server would need to support such a feature...