3 ms·

h2 is better than that.. each request carries a priority, so the server can stop sending one resource and start sending another higher priority one if it become

h2 is better than that.. each request carries a priority, so the server can stop sending one resource and start sending another higher priority one if it becomes available. It can even do this interleaving based on actual data available to send not just the request queue - so things like CPU and IO time on one high-priority resource don't become blockers to using the bandwidth for a lower-pri resource that is ready to go. Obviously that requires a decent server implementation that uses smallish sending chunks and doesn't over buffer. So the browser should not reorder requests and hold some back (they all do play those games in h1) with h2 - it should just set the pri/dep flags well to give the server (which is going to do the sending) maximum information. The real HOL problem with h2 involves TCP loss recovery. Its a fairly minor issue though in practice.

nly 11y ago
I serve Wordpress over SPDY 3.1 all the time. Not sure if that's close enough to HTTP/2 to be comparable, but I don't see how HTTP/2s capabilities will solve the following problem: And that is I still need to wait 100-200ms for PHP to spit out HTML from index.php, 100ms for the client to receive it, and another 100ms for a list of prioritised requests for dependent resources to come back. How is that not a "real HOL problem"? If you treat a request as referring to a bundle of resources rather than a single response then you can solve all that by allowing the client to send a lot more metadata about its current view of the whole package. This frees up the web server to respond with logo.png, funkystyle.css and bloated.js, or a freshness response, while we wait for PHP The only way a user-agent can solve this under HTTP/2 is to request a bunch of related resources it knows it needed the last time, at a low priority, and hope they are either needed, or unneeded but unchanged (as to not waste bandwidth). And you know, a pipelined HTTP/1.1 client can do this just fine by prefacing its primary request with a bunch of If-Modified-Since requests. And sure, you can build a webserver that can parse HTML out of PHP and do HTTP/2 PUSH, but again that's a waste of bandwidth if I have these resources cached. That's why I think it's time to move away from a simple request, response and cache model and start thinking in terms of bundle synchronisation and dependencies.

nly 11y ago

I serve Wordpress over SPDY 3.1 all the time. Not sure if that's close enough to HTTP/2 to be comparable, but I don't see how HTTP/2s capabilities will solve the following problem: And that is I still need to wait 100-200ms for PHP to spit out HTML from index.php, 100ms for the client to receive it, and another 100ms for a list of prioritised requests for dependent resources to come back. How is that not a "real HOL problem"? If you treat a request as referring to a bundle of resources rather than a single response then you can solve all that by allowing the client to send a lot more metadata about its current view of the whole package. This frees up the web server to respond with logo.png, funkystyle.css and bloated.js, or a freshness response, while we wait for PHP The only way a user-agent can solve this under HTTP/2 is to request a bunch of related resources it knows it needed the last time, at a low priority, and hope they are either needed, or unneeded but unchanged (as to not waste bandwidth). And you know, a pipelined HTTP/1.1 client can do this just fine by prefacing its primary request with a bunch of If-Modified-Since requests. And sure, you can build a webserver that can parse HTML out of PHP and do HTTP/2 PUSH, but again that's a waste of bandwidth if I have these resources cached. That's why I think it's time to move away from a simple request, response and cache model and start thinking in terms of bundle synchronisation and dependencies.