@igrigorik's post from '13 goes into some of the details on this: https://plus.google.com/+IlyaGrigorik/posts/8AwRUE7wqAE …
-
Show this thread
-
So browsers read stream sof bytes coming in and try to locate things that will correspond to network resources and request them early. This is happening in the critical path of page load without full information about the resulting DOM, CSS OM, or even what's in the viewport.
1 reply 0 retweets 0 likesShow this thread -
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.
1 reply 0 retweets 0 likesShow 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
Back to this point, I think that's the logical answer. If we imagine H/2 streams as being per-document groups, we only need to express priority at one level within those groups and expose that range to web developers via attributes and `fetch`.
/cc @yoavweiss
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.