The x/net/http2 scheduler has two implementations: a random scheduler and a priority scheduler. The random scheduler mimics the old scheduler used in go 1.7 and earlier. The priority scheduler uses the http2 priority tree to schedule writes. I have benchmarks showing that web pages load considerably faster with the priority scheduler than the random scheduler.

We opted not to change schedulers for go 1.8 to minimize churn and give the code a chance to bake. Going forward, I see no major reason why we shouldn't use the priority scheduler by default in net/http. My only concern is CPU usage. The priority scheduler has some operations that are O(n) in the worst case, where n is len(connection.openStreams). I don't believe it's possible to faithfully implement the http2 priority spec without an O(n) worst case, but I admittedly haven't given that question much thought. That said, I don't expect the worst case to occur often in practice, and even if the worst case does occur, n is capped to a small constant -- 250 by default, and we can lower this if needed. Given the measurable benefits on client-perceived page load time, I think it's worth turning on the priority scheduler by default. We can always roll back during the 1.9 beta phase if we get complaints.

We could also make the scheduler selectable via an environment variable.

Non-web servers, such as grpc, may want to continue using the random scheduler.

/cc @bradfitz, I would label this Go1.9early