I assume this is HTTP/2 and not QUIC.  Could you please provide an about:net-internals or about:net-export log?  instructions:  https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details

Yes, it should be HTTP/2.
I have attached net-internals/export
Let me know if you need anything else.

Deleted: net-internals-log.json 1.7 MB

net-internals-log.json 1.7 MB View Download

Thank you for providing more feedback. Adding requester "mmenke@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The net-internals log does not contain any HTTP2_SESSION_RECV_PUSH_PROMISE events, meaning that Chrome did not receive any PUSH_PROMISE frames.  Is it a server configuration issue?  Do you have access to server-side debug logs to check if any PUSH_PROMISE frames were actually sent?

You are right, it is not a Server Push Event, but actually the requests has to be sent asynchronously. 

It is not my server, as you can see, it is an example of Brad Fitzpatrick from Google Golang. I've attached an image, which was taken from a Chrome 57.0.2987.133. The images are loaded asynchronously, in which the screenshot of Chrome 59.0.3067.0 looks more like it is always building 6 TCP connections, which results in much slower loading process.

Deleted: Screen Shot 2017-04-17 at 13.35.36.png 256 KB

	Screen Shot 2017-04-17 at 13.35.36.png 256 KB View Download

Thank you for providing more feedback. Adding requester "bnc@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Re #8: Thank you for your response.  Requests are held back by ResourceScheduler, but they should not be.  cc'ing relevant folks.

In net-internals, there is only one HTTP2_SESSION.  However, requests seem to be sent in bursts of six at a time.  The last HTTP2_SESSION_SEND_HEADERS event is for stream 3261, and has source_dependency 12093.  That is an HTTP_STREAM_JOB, with source_dependency 12092: an HTTP_STREAM_JOB_CONTROLLER, with source_depencendy 11591: a URL_REQUEST, which shows that the request has been delayed by more than four and a half seconds:

t= 352 [st=   0]   +DELEGATE_INFO  [dt=4633]
                    --> delegate_blocked_by = "ResourceScheduler"
t=4984 [st=4632]      RESOURCE_SCHEDULER_REQUEST_STARTED
                      --> trigger = "COMPLETION_POST_BODY"
t=4985 [st=4633]   -DELEGATE_INFO

RESOURCE_SCHEDULER_REQUEST_STARTED is logged in content::ResourceScheduler::Client::StartRequest().  So ResourceScheduler is the one holding back requests, though it really should not over an HTTP/2 connection.

That being said, I am not able to locally reproduce it with my 59.0.3067.0 (Official Build) dev (64-bit).

+jkarlin made H2 requests throttled as well for performance reasons so this is expected behavior afaik.

Can't explain why it is not reproducible for you. Still facing the problem.

Correct, this is expected behavior. Throttling in the manner above results in pages reaching time-to-first-contentful-paint and time-to-first-meaningful-paint considerably faster. 

Still, it does not explain why I have two completely different results in two different Chrome versions. Anyway,...

Ah, that's because the feature is just being launched. It's starting in canary but hasn't made its way to stable yet.