- pipelining is still single-file request-response though. With SPDY, you can send multiple requests at once, and the server responds to them in whatever order it likes.
- The point of removing the FIFO queuing is that the server can start responding with simple files before the more expensive resources are calculated. Usually the HTML itself can take a while to be generated server-side, where as CSS and JS files are usually just served straight off disk.
In a FIFO model, the 200ms the client is waiting for the HTML to be generated is just wasted. You could be using that time to be downloading CSS or JS or images, etc.
- There's two options for server-initiated requests in SDPY. One where the server says "Since you requested this resource, you'll probably also want this, this, and this." (i.e. it sends links to the client with the related resources). Other other option is where it actually says, "Since you request this resources, here's these other resources you might be interested in as well."
In the first case, the client can begin processing those other files (e.g. checking it's local cache or actually making a request for them) before the original resource has completed downloading/parsing. In the second case, it could be that the original resource and the "sub-resource" (e.g. HTML file and attached CSS file) have similar caching rules, so if a client requests one it's likely that it'll request the other anyway.
- SDPY also has options for not including those kinds of things (e.g. User-Agent, Host, Accept-*) on every request. But even when you do that, compression still has benefits. Even once you've removed all the redundant data, compression will still help, so why wouldn't you?
- I agree there's certain kinds of content which don't benefit greatly from compression. But on almost all platforms, CPU power is much higher than network capacity. In fact, I can't think of a single platform where that's not the case...
- pipelining is still single-file request-response though. With SPDY, you can send multiple requests at once, and the server responds to them in whatever order it likes.
- The point of removing the FIFO queuing is that the server can start responding with simple files before the more expensive resources are calculated. Usually the HTML itself can take a while to be generated server-side, where as CSS and JS files are usually just served straight off disk.
In a FIFO model, the 200ms the client is waiting for the HTML to be generated is just wasted. You could be using that time to be downloading CSS or JS or images, etc.
- There's two options for server-initiated requests in SDPY. One where the server says "Since you requested this resource, you'll probably also want this, this, and this." (i.e. it sends links to the client with the related resources). Other other option is where it actually says, "Since you request this resources, here's these other resources you might be interested in as well."
In the first case, the client can begin processing those other files (e.g. checking it's local cache or actually making a request for them) before the original resource has completed downloading/parsing. In the second case, it could be that the original resource and the "sub-resource" (e.g. HTML file and attached CSS file) have similar caching rules, so if a client requests one it's likely that it'll request the other anyway.
- SDPY also has options for not including those kinds of things (e.g. User-Agent, Host, Accept-*) on every request. But even when you do that, compression still has benefits. Even once you've removed all the redundant data, compression will still help, so why wouldn't you?
- I agree there's certain kinds of content which don't benefit greatly from compression. But on almost all platforms, CPU power is much higher than network capacity. In fact, I can't think of a single platform where that's not the case...