Because networks aren't perfectly fast, outbound requests go into a queue. The way Chrome prioritizes those requests is based on a bunch of heuristics. Did it come from a blocking script? High priority! XHR? Low priority. Etc., etc.
-
Show this thread
-
Remember: HTML doesn't actually define a priority system, so this is all an exercise to the implementer and browsers do simulated annealing to come to roughly-good heuristics (historically, based on bogus benchmarks, but we're doing better now; thanks for asking).
1 reply 0 retweets 1 likeShow this thread -
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.
1 reply 0 retweets 0 likesShow 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 -
Replying to @slightlylate
The driving feature of the priority scheme is the ability to manage independent sets of priorities on the same stream (which cannot be done with a small int). These sets could be tabs, they could be users (in a proxy), etc.. the google engs who drove the design understood this.
1 reply 0 retweets 0 likes -
Replying to @mcmanusducksong
My feedback to them at the time was the same as now: cool, but beyond one level of dependency, how will this ever be sane or useful by a webdevs?
1 reply 0 retweets 0 likes -
Replying to @slightlylate
it may be the case that webdevs use something simpler and protocol stacks map those into roots reflecting webdev scope. Or maybe webdevs standardize classifications instead of pri - which can also be mapped along the lines of firefox. no reason web view has to be the same.
2 replies 0 retweets 2 likes -
Replying to @mcmanusducksong @slightlylate
mostly I'm annoyed you took a pot shot at mark rather than assuming we're all in this together to build a better internet. That's how I remember it. Especially galling when your proximate complaint is about a technology your own google teammates promoted hard.
1 reply 0 retweets 0 likes -
Replying to @mcmanusducksong
It was meant as a joke; done poorly. Apologies for that and to
@mnot. That said, the critique stands. The protocol is over-complex beyond one level of dependency. Also, I frequently disagree with my colleagues (and many other people) on a great many things.1 reply 0 retweets 0 likes
An instance of this is my deep, near-decade-long frustration that the Powers That Be in HTML (largely Googlers) have failed to prioritize creating a functional priority level scheme for HTML and to make `async` and `defer` attributes universally respected across types
-
-
That was the primary ding in the thread; that HTML is even more broken than H/2 in this regard. I'll try to be more clear in the future. And, again, apologies to
@mnot.0 replies 0 retweets 1 likeThanks. Twitter will use this to make your timeline better. UndoUndo
-
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.