|
|
|
|
|
by Ono-Sendai
3625 days ago
|
|
I agree that the case of 1 large 2MB image and a small 1KB file is a good case for multiplexing. What annoys me somewhat is that HTTP2.0 was basically sold on the back of such demonstrations as 'load 256 identical images'. In that case a proper implementation of HTTP 1.1 with keepalive/pipelining would be just as fast (or even slightly faster due to avoiding multiplexing overhead) as HTTP 2.0. I think it's pretty pathetic that people can't implement this properly, and I find it worrying that the solution to not being able to implement a protocol properly is to replace it with a more complex protocol. |
|
Which means that if and when we come up with something better, we can deprecate HTTP/2 support, and support only HTTP/next + HTTP/1.1. This helps avoid legacy cruft.
Google did that for SPDY with Chrome - it's no longer supported.
While I'm not convinced that a proper implementation of HTTP 1.1 would actually be just as fast as HTTP 2.0, if you are right, there will be data to show it, and it's not too late for us to change the ecosystem based on that data.