Add priorities to XMLHttpRequest

Assigned to



9 years ago
2 months ago


(Reporter: smaug, Assigned: smaug)


Firefox Tracking Flags

(Not tracked)



(1 attachment, 1 obsolete attachment)

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.

Start ~10 XHR, only 6 of them will start loading immediately.
Then the next ones will start based on priority.
Created attachment 438963 [details] [diff] [review]
wip, v2

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

Comment 8

9 years ago
Cross-linking the WebKit bug:

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.

Comment 12

5 years ago

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.

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.

Comment 14

5 years ago
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.

Comment 15

4 years ago
I wrote a blog post describing the use case and poor customer experience that results from not having a priority hint:
You need to log in before you can comment on or make changes to this bug.