Got asked about this (a short thread): https://twitter.com/EWErikWitt/status/1027603512203640832 …
/cc @EWErikWitt @igrigorik @yoavweiss @jaffathecake
Browsers process network fetches roughly in the order they're made aware that they're going to need to issue them. We go to great lengths to find out when we're going to need bits and bobs; we even go so far to implement crazy parser hacks to "read ahead" to find resources faster
-
-
@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.
Show 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.
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).
Show 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.
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.
Show 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.
Show 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.
Show 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.
Show this thread -
"But", I hear you saying, "the client can adjust priorities!": https://http2.github.io/http2-spec/#reprioritize … LAWLZ.
Show 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.
Show this thread
End of conversation
New conversation -
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.