> By the time the high priority written script is discovered
> and requested, there is a lot of data already in-flight on
> the connection for low priority resources later in the document.

Since this page uses a single H2 connection, this case of bufferbloat could be fixed by throttling either on the client (as Pat suggests in crbug/651538) or on the server. To verify, I loaded the same page in three modes in a replay server: H1 over https, H2, and H2 with bandwidth pacing (where the server paces writes to match the connection bandwidth; I didn't have access to a server with QUIC+BBR or I would have tried that directly). I loaded the page 10 times in each configuration. The 25/50/75 SpeedIndex percentiles are:

+---------+------+------+------+
| mode    | p25  | p50  | p75  |
+---------+------+------+------+
| H1      | 4021 | 4107 | 4198 |
| H2      | 3996 | 4016 | 4132 |
| H2paced | 3812 | 3846 | 3876 |
+---------+------+------+------+

The median WPT runs:
H1: https://www.webpagetest.org/result/161010_24_aa4c4364126c072f36c00e9a5b00d47d/
H2: https://www.webpagetest.org/result/161010_VZ_b3b9b1ab34c5f01d65b85555227d6006/
H2paced: https://www.webpagetest.org/result/161010_MB_075169447cd2c57ec914105523838d36/

The waterfalls show that the scripts are loaded much faster with H2paced than H2. In general, I think the "right" long-term solution to single-connection bufferbloat is to use better congestion control in the server, but since that's a ways off from large-scale deployment, I think it would make sense to revisit request throttling in Chrome for H2 connections.

> It might also be worth examining applying the other resource
> scheduling logic (delaying low priority requests) for cases
> where more than one connection is being used since HTTP/2
> priorities are only effective on a single connection.

This sounds like a good idea.

Hmmm.  My concern about that analysis is that it shows H2 without spacing as being slightly better than H1, which suggests that it's not running into the problems that Pat was seeing?

Adding Blink>Loader tag for ResourceScheduler involvement, but triage by the blink team is not needed.

IIUC, the problem Pat was seeing is scripts being loaded very slowly, as in this waterfall (the H2 example from crbug/651538):
https://www.webpagetest.org/result/160929_ZJ_d5b8777020444f1ab27c7bfeacc12e93/3/details/#waterfall_view_step1

Compare the load times of script.js in the above H2 waterfall to the following H1 waterfall (again from crbug/651538):
https://www.webpagetest.org/result/160929_Z7_1b6765c67b8534819e4b23438be34f77/2/details/#waterfall_view_step1

In comment #2 above, H1 and H2 duplicate the same behavior that Pat saw -- the scripts load much more slowly with H2 than with H1. H2paced makes the scripts load (almost) as fast as they do in H1. This is why I concluded that the main problem is bufferbloat.

I shouldn't have listed SpeedIndex for those runs since SpeedIndex isn't the important metric for this bug -- it's time-to-first-paint, which is entirely limited by the time to load all of the scripts. There are also two differences between my H1 and Pat's H1 that make a direct head-to-head comparison difficult:

1. Pat's H1 used http, while mine used https (via an http-over-https proxy). I used https to remove H1's 1-RTT connection-setup advantage over H2.

2. Pat's H1 used more concurrent requests than my H1. Maybe Chrome is more aggressive about creating concurrent connections when using http or when not using a proxy?

I don't think these differences change the basic conclusion: the scripts load slowly due to bufferbloat. I also like Pat's suggestion to throttle client requests, even with H2, due to potential bufferbloat problems.

Seems as much a QUIC issues as an H2 issue.  Don't see the QUIC team having issues with doing this, but seems like they should be informed.

> It might also be worth examining applying the other resource scheduling logic (delaying low priority requests) for cases where more than one connection is being used since HTTP/2 priorities are only effective on a single connection.

This is something we should definitely experiment with. This was discussed offline a while back. One of the suggestions was that we should experiment with throttling third-party H2 requests, where the host of the third-party request is different from the host of the main frame request.

Agreed that this affects QUIC too and makes sense to do. Let me know if QUIC team needs to do anything to support this effort.

As this is similar to issue 655585 (but different in that this refers to prioritization issues and not queuing delays) which I'm already working on I'll take it.