3 ms·

Show HN: Dependency-based prioritization makes HTTP/2 much faster than SPDY

67 points by kazuho 11y ago

supertruth 11y ago
Seems like there is still a significant amount of initial latency by waiting for the first-byte of the HTML before making the subsequent requests for the dependent resources. To actually minimize latency the server should understand what resources the HTML file is dependent on, and eagerly send those in addition to the request resource. i.e. client: send me index.html and dependent resources server: here is index.html, along with other initial resources you didn't ask for but will need This avoids the latency of the second round-trip time to ask for dependent resources. Does anyone know if HTTP/2 allows for a scheme like this?
- gregory144 11y ago
  That is one of the main advantages of HTTP2 - it's called server push. When the server receives a request, it can send the headers for the requested resource plus the headers for as many related resources as it wants. The client can choose to either disable this, or reject pushed streams when it receives their headers.
burgreblast 11y ago
I'm not sure I'm reaching the same conclusion. - Chrome is taking 618ms to load / vs 412 ms on FF. - FF loads all the .css & .js at 320ms as well as first 8 imgs - CH loads all the .css & .js at ~600ms as well as first 8 imgs Before chalking up the advantage to dependency-based prioritization (which may be a good thing-I don't know) I would first explain why fetching "/" is so much slower on chrome.
- kazuho 11y ago
  As described in note 5, "the network chart of Chrome includes a 0.2 second block before initianting the TCP connection, which has been subtracted from the numbers written in this blog text". That explains the differences of the numbers on the charts you pointed out.
  - burgreblast 11y ago
    Thanks, I missed that. Might be worth re-running the tests without the block so the graphs can line up better and we don't need to subtract the 200ms? As you well know, implications of latency or packet loss are hard to extrapolate on real-world rendering.
    - kazuho 11y ago
      Unfortunately the block was always found on the test machine. The test was conducted using a VM running running on a host on which the web browsers were run, so there were no noise or packet loss; the results were reproducible.
cbr 11y ago
Are your timings based off of a single run each for Firefox and Chrome? The web is a very noisy place; to get good timing data you need to run many tests. WebPageTest (www.webpagetest.org) can be a good way to do this. (I work on PageSpeed, and we need to run tests like this often.)
- kazuho 11y ago
  Thank you for the suggestion. In case of the benchmark, I run the server as a VM instance on the client machine so that the results would be reproducible (with network latency added by `tc qdisc` command). PS. PageSpeed is a really nice service; and I agree that it is a useful tool for evaluating the speed in the real-world.

67 points by kazuho 11y ago

Seems like there is still a significant amount of initial latency by waiting for the first-byte of the HTML before making the subsequent requests for the dependent resources. To actually minimize latency the server should understand what resources the HTML file is dependent on, and eagerly send those in addition to the request resource. i.e. client: send me index.html and dependent resources server: here is index.html, along with other initial resources you didn't ask for but will need This avoids the latency of the second round-trip time to ask for dependent resources. Does anyone know if HTTP/2 allows for a scheme like this?

gregory144 11y ago
That is one of the main advantages of HTTP2 - it's called server push. When the server receives a request, it can send the headers for the requested resource plus the headers for as many related resources as it wants. The client can choose to either disable this, or reject pushed streams when it receives their headers.

burgreblast 11y ago

I'm not sure I'm reaching the same conclusion. - Chrome is taking 618ms to load / vs 412 ms on FF. - FF loads all the .css & .js at 320ms as well as first 8 imgs - CH loads all the .css & .js at ~600ms as well as first 8 imgs Before chalking up the advantage to dependency-based prioritization (which may be a good thing-I don't know) I would first explain why fetching "/" is so much slower on chrome.

kazuho 11y ago
As described in note 5, "the network chart of Chrome includes a 0.2 second block before initianting the TCP connection, which has been subtracted from the numbers written in this blog text". That explains the differences of the numbers on the charts you pointed out.
- burgreblast 11y ago
  Thanks, I missed that. Might be worth re-running the tests without the block so the graphs can line up better and we don't need to subtract the 200ms? As you well know, implications of latency or packet loss are hard to extrapolate on real-world rendering.
  - kazuho 11y ago
    Unfortunately the block was always found on the test machine. The test was conducted using a VM running running on a host on which the web browsers were run, so there were no noise or packet loss; the results were reproducible.

cbr 11y ago

Are your timings based off of a single run each for Firefox and Chrome? The web is a very noisy place; to get good timing data you need to run many tests. WebPageTest (www.webpagetest.org) can be a good way to do this. (I work on PageSpeed, and we need to run tests like this often.)

kazuho 11y ago
Thank you for the suggestion. In case of the benchmark, I run the server as a VM instance on the client machine so that the results would be reproducible (with network latency added by `tc qdisc` command). PS. PageSpeed is a really nice service; and I agree that it is a useful tool for evaluating the speed in the real-world.