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.
-
-
So what's happening in
@EWErikWitt's post is a cruel combination: 1.) HTML has serially failed to define a meaningful priority scheme (yes, I'm grumpy about it) 2.) H/2 priorities aren't passed because it's "magic" info as a result 3.) fetch() is in the XHR slow bucket
Show this thread -
's post should be titled "Service Workers show how broken HTML and H/2 priorities are". We can do some magic in the limited case he outlines where the source `Request` hasn't been touched, but honestly, we shouldn't.
Show this thread -
Instead, we should be exposing a real, integer-range-based, priority system. No, browsers won't magically agree on these weights. Yes, network stack will sometimes need to reorder anyway, but how is that worse than the status quo?
Show this thread -
The infuriating part of this is the condescension from the H/2 and network stack community. The fear that web developers will "just make everything high priority; then what?" is both real, true, and useless.
Show this thread -
We'll always need to intervene as the user's agent, but so long as JS is part of the platform, developers could *already* do whatevs; it might just have been the long way 'round.
Show this thread -
So it's worth flagging this effect, worth being upset, and perhaps even worth calling out all the folks who work on Chrome that haven't fixed it. But the problem isn't the implementation. It's harder and worse than that. It's a fundamental lack of respect for web developers.
Show this thread -
Taking control of the network shouldn't mean always getting down-ranked in priority. This sort of magic needs to be in developer hands: https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/loader/fetch/resource_fetcher.cc?l=124 …
Show this thread
End of conversation
New conversation -
-
-
@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... -
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 …
- 1 more reply
New conversation -
-
-
Don‘t know if you include Apache in that list. But PRIORITY always affects outgoing bandwidth allocation in httpd. Request scheduling in the server is unaffected after processing has started, eg only reorders the queue. I assume nghttpd behaves similar.
Thanks. 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.