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?
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.
- 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.
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.
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.
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.
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.)
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.
8 comments
[ 0.22 ms ] story [ 31.2 ms ] threadTo 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.
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?- 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.
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.
(I work on PageSpeed, and we need to run tests like this often.)
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.