There is a proposal to add setPriority to XMLHttpRequest. I think it makes sense, and would be easy to implement, AFAIK. I do quickly a prototype implementation and a demo.
nsISupportsPriority in http channels doesn't seem to work quite the way I was hoping :/
Or perhaps the problem is in my test
and my network connection is pretty fast
Actually, the wip works just fine. http://mozilla.pettay.fi/xhr_upload/xhr_demo_with_priority.html Start ~10 XHR, only 6 of them will start loading immediately. Then the next ones will start based on priority.
By default don't change the priority.
Attachment #438800 - Attachment is obsolete: true
I'm not yet sure whether this all should somehow take account priorities in different tabs. Should background tab's "CRITICAL" be less critical than in foreground tab. Perhaps that kind of thing could be optimized later if needed.
Attachment #438963 - Attachment description: v2 → wip, v2
Cross-linking the WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=43400 Hopefully the IDLs will match up.
And because the feature isn't specified properly anywhere, moz and webkit prefixes should be used with constants and method.
I'll upload a new patch with prefixes.
Though, I'm not at all sure what version of the draft spec to implement. I don't quite like using strings for the priority.
Hi, For our WebGL application, we stream down hundreds of individual assets to load a scene. Some of these assets (skeletons, meshes, low-res textures) are far more important than others (high-res textures). In addition, some objects in a 3D scene are more important than others. Your own 3D character is more important than others. The room is more important than props in the room. In our native applications, we have the ability to prioritize network traffic appropriately, but on the web, we don't. Being able to prioritize XMLHttpRequest would be a large improvement to our customer experience. Thanks, Chad
It sounds like WebSockets might work better for you, and have your own prioritization on top of the API. That certainly would reduce the overhead of http.
We actually want HTTP so we can leverage CDNs, Varnish, and the browser's cache. All of our 3D assets are indexed by hash and thus infinitely cacheable, so, while pushing data with WebSockets might be an improvement on the initial load, it doesn't help at all for subsequent loads. HTTP + priority would be perfect for this use case.
I wrote a blog post describing the use case and poor customer experience that results from not having a priority hint: http://chadaustin.me/2014/08/web-platform-limitations-xmlhttprequest-priority/
Component: DOM → DOM: Core & HTML
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.