

Show HN: Dependency-based prioritization makes HTTP/2 much faster than SPDY - kazuho
http://blog.kazuhooku.com/2015/04/dependency-based-prioritization-makes.html

======
cbr
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
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.

------
supertruth
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
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
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
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
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
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.

