4 ms·

> Bandwidth is cheap. and the speed of light is constant. http1 has issues accessing all available bandwidth, and speed of light ensures that with a limited ba

by f2f 12y ago

> Bandwidth is cheap. and the speed of light is constant. http1 has issues accessing all available bandwidth, and speed of light ensures that with a limited bandwidth your page load times will suffer. you don't go to web pages that take forever to load. nobody does. the bandwidth argument is not the argument you should be making. you should be making the argument that today's pages are bloated and we need to work on reducing page/image size. that is being worked on too. everybody willing to diff http1 and http2 should just take a look at this with a modern browser and imagine it in a standard site context (bigger images, many more site elements): https://http2.golang.org/gophertiles https://http2.golang.org/gophertiles http://http2.golang.org/gophertiles http://http2.golang.org/gophertiles

jacquesm 12y ago
I think you are replying to the wrong comment here, I did not make the argument that bandwidth was a major consideration, my point is that it isn't. Latency != bandwidth. Installing ghostery will do more for your page load times than http2 will.
- f2f 12y ago
  > Latency != bandwidth. yes, and you're conflating the two.
  - jacquesm 12y ago
    From kjksf's comment above: "That's a lot of http connections which adds up to a lot of bandwidth and time savings." I was only addressing the 'bandwidth' part. The latency bit (which is partially addressed by running multiple concurrent connections via a single socket) is a different issue, for which we also already have multiple solutions (for one, stop making a few hundred requests for a page).
    - dcsommer 12y ago
      > for one, stop making a few hundred requests for a page Telling the world "you're doing it wrong" is not a pragmatic solution. HTTP/2 exists to improve the web as it exists today. In this, it demonstrably succeeds. For the same reason Javascript will remain the assembly language of the web, so too will HTTP/1.1 semantics likely persist forever. It's not because it's what we want but because there is no (yet) known transition away from it. HTTP/2 doesn't replace HTTP/1.1. It just deprecates a horrible wire format and adds some other features.
- youngtaff 12y ago
  > Latency != bandwidth No, but latency has a linear relationship with throughput Test at page at 1Mbps thorough 10Mbps and 25ms RTT and watch how small the performance gains are above 5Mbps, then do the same with 10 to 200ms RTT and 10Mbps and watch performance dive.

by f2f 12y ago

jacquesm 12y ago

I think you are replying to the wrong comment here, I did not make the argument that bandwidth was a major consideration, my point is that it isn't. Latency != bandwidth. Installing ghostery will do more for your page load times than http2 will.

f2f 12y ago
> Latency != bandwidth. yes, and you're conflating the two.
- jacquesm 12y ago
  From kjksf's comment above: "That's a lot of http connections which adds up to a lot of bandwidth and time savings." I was only addressing the 'bandwidth' part. The latency bit (which is partially addressed by running multiple concurrent connections via a single socket) is a different issue, for which we also already have multiple solutions (for one, stop making a few hundred requests for a page).
  - dcsommer 12y ago
    > for one, stop making a few hundred requests for a page Telling the world "you're doing it wrong" is not a pragmatic solution. HTTP/2 exists to improve the web as it exists today. In this, it demonstrably succeeds. For the same reason Javascript will remain the assembly language of the web, so too will HTTP/1.1 semantics likely persist forever. It's not because it's what we want but because there is no (yet) known transition away from it. HTTP/2 doesn't replace HTTP/1.1. It just deprecates a horrible wire format and adds some other features.
youngtaff 12y ago
> Latency != bandwidth No, but latency has a linear relationship with throughput Test at page at 1Mbps thorough 10Mbps and 25ms RTT and watch how small the performance gains are above 5Mbps, then do the same with 10 to 200ms RTT and 10Mbps and watch performance dive.