So browsers are trying to keep the pipe full. Wasted time in the critical path is wasted time. There's no other word for it. Being slightly wrong about priority is much worse than not issuing a network request with the channel would otherwise be empty.
-
Show this thread
-
Let that really sink in: the browser-side idea of priority is a decision made with incomplete information, under the gun, and once the request is sent, it's pretty much over-and-done with.
1 reply 1 retweet 1 likeShow this thread -
Contrast that with the baroque-AF priority system that the H/2 WG cooked up at the last minute: https://http2.github.io/http2-spec/#pri-depend … Earlier drafts used integer priorities (in a small range, IIRC). The final version, in contrast, assumes the client knows a LOT about outbound requests.
2 replies 0 retweets 0 likesShow this thread -
So you've got a server with lots of time (until it gets a flood of requests to handle), assuming a client that has full knowledge of the dependency graph...which as we've just discussed, is basically never the case.
1 reply 0 retweets 3 likesShow this thread -
Getting more information to construct a more accurate dependency graph would require more processing (and waiting) on the client side before issuing requests...which is dead air...which is bad. So client's don't actually wait. They take their initial guess about priority and run.
1 reply 0 retweets 1 likeShow this thread -
"But", I hear you saying, "the client can adjust priorities!": https://http2.github.io/http2-spec/#reprioritize … LAWLZ.
1 reply 0 retweets 0 likesShow this thread -
In practice, inbound requests dish off to some other thread. That work is likely I/O bound. That I/O, once started, isn't worth pausing or changing. You're better off getting the bytes into memory to be flushed ASAP with as little second guessing as possible.
1 reply 0 retweets 1 likeShow this thread -
High-performance H/2 servers will pretty much always drop subsequent PRIORITY frames on the floor and high-performance clients won't wait to generate them. H/2 priorities are a practical joke as far as I can tell. I presume
@mnot is getting the last laugh.4 replies 0 retweets 1 likeShow this thread -
Replying to @slightlylate
@mcmanusducksong still advocates for them, last I heard.@kazuho's H2O is one of the highest perf servers, and it implements fully. I don't know what it means to wait to gen PRIORITY - they can be sent anytime (read https://httpwg.org/specs/rfc7540.html#reprioritize …). And I'm not in this for the yuks...1 reply 0 retweets 1 like -
AFAICT, this is basically the the only place we ever try to modify priority of existing requests: https://cs.chromium.org/chromium/src/content/browser/download/download_request_core.cc?type=cs&sq=package:chromium&g=0&l=275 …
2 replies 0 retweets 0 likes
That said, I'm unsure how often this get used: https://cs.chromium.org/chromium/src/services/network/resource_scheduler.cc?type=cs&sq=package:chromium&g=0&l=1115 …
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.