Wednesday, April 14th, 2010

XMLHttpRequest Priority Proposal

Category: XmlHttpRequest

<>p>Mike Belshe of Google Chrome and SPDY posted on a proposal for XMLHttpRequest Priority:

Every performant web browser implementation today implements various heuristics for resource loading prioritization internally. The notion is simple, that loading some resources, such as images, are less performance critical than loading other resources, such as
external style sheets. By implementing basic priorities, browsers achieve substantially better performance loading web pages. Today, however, web applications have no way of giving hints to the browser about what may be high or low priority.

Because complex applications heavily rely on resource loading by way of XmlHttpRequest, we propose a simple, backward compatible, and optional mechanism whereby application developers can hint to a browser how to load a XmlHttpRequest.

Proposed API:

javascript
< view plain text >
  1. interface XMLHttpRequest {
  2.  // XMLHttpRequest Priorities.
  3.  const unsigned short CRITICAL = 0;
  4.  const unsigned short HIGH = 1;
  5.  const unsigned short LOW = 2;
  6.  const unsigned short LOWEST = 3;
  7.  
  8.  // Set the load priority for this request.
  9.  void setPriority(unsigned short priority);
  10. }

Example Usage:

javascript
< view plain text >
  1. var client = new XMLHttprequest;
  2. client.setPriority(HIGH);
  3. client.open(’GET’, ‘demo.cgi’);
  4. client.send();

Description:

When a new XMLHttpRequest object is created, it contains a notion of
priority. Browsers which schedule resource fetches may optionally use this
priority to determine in which order resources are fetched.

4 priorities are provided. By keeping the number of different priorities
small, we keep browser and XMLHttpRequest priority implementations simple.

By default, all XMLHttpRequest objects have a priority ‘LOW’.

Applications may alter the priority by calling the setPriority() method on
the XMLHttpRequest object. The priority set on the object at the time the
application calls the XMLHttpRequest.send() method determines the priority
the browser should use when fetching this resource. Calling setPriority()
after the send() method will have no effect on the priority of the resource
load.

This is interesting timing, as at the Mozilla Caching Summit the notion of priorities came up several times. Maybe there is a way to have a higher level resource priority setting that would allow you to tell the browser more about the pieces of content. That way, if purging the cache say, the core JS for your application could stay even if the video on the page is purged.

What do you think?

Related Content:

Posted by Dion Almaer at 6:41 am
9 Comments

++++-
4.2 rating from 17 votes

9 Comments »

Comments feed TrackBack URI

It doesn’t make much sense as long as there is NO queue managing the connections. For example, FF allows for 4 simultaneous requests to be made to a server (kudos here to IE8 which provides the value in the variable “window.maxConnectionsPerServer”), and anything beyond that will fail silently, without even giving the user a notice. Create 8 XmlHttpRequests and fire them all up and inspect FB to see what happens.
For now, using queues and priorities is something which is entirely done in userland code, see the ExtJS library for example, Doug Hendricks introduced a priority system for XMLHttpRequests, and I myself offer an override for queuing concurrent connections.
How do other libraries solve these issues?

Comment by ThorstenSuckow — April 14, 2010

Perhaps go even further and allow for full Queue management (e.g. modifying priority after initiation). Or perhaps that is better done one level up from the browser in a framework.

Comment by Tonto — April 14, 2010

Does it honestly make any difference? If 10 web pages in your browser all send a request at HIGH priority, it still falls to the implementation to sort it out. Plus, since this is an Async request, what difference will it make in time when most requests already take under 200ms to execute?

Comment by TNO — April 14, 2010

I’m using XHR only for RPC calls, not for loading large blocks of script (those I load with script tags appended to the head). So, for me it doesn’t actually matter whether we get this feature.

Comment by Joeri — April 14, 2010

Prioritising Ajax requests makes a lot of sense but it will take some time to become standard… in the meantime, perhaps someone might fancy writing a jQuery plugin to handle queueing & prioritisation of Ajax requests? ;)

Comment by MarcusT — April 14, 2010

In real world apps, is there really that much contention amongst XHRs? I haven’t seen that. Doing this for XHRs in addition to all other resources is a cool idea. I wouldn’t want that to affect caching (everyone would give all their resources the highest priority), but I would like to see that used as hints by the browser to affect download order.

Comment by souders — April 14, 2010

This general sense of this feature is easy enough to simulate at the JavaScript level it people are interested (Tontos comment and yes with queue and request management) In Ajax: The Complete Reference (mostly Chapter 6) we implemented a priority queue as well as sequence enforcing in our example library. You can fool around with the priority queue here – http://ajaxref.com/ch6/requestqueueexplorer.html We only had three states though not sure why four is actually needed practically I guess for some “do it when you can” request? The motivation for this type of feature is clear to me XHRs aren’t really robust app layer communication and if you move to do Ajax of any complex way with ordering, dependency, etc. it is kind of a must. The lack of interest until recently in such features speaks volumes to what is actually being used for still – back channel, unmonitored requests, with no dependencies or sequence requirements. Most Ajax I am still seeing is really post-back 2.0, just done behind the scenes with minimal page update, still quite cool, but from a networking point of view still pretty simple.

Oh per the first commenter, do other libraries handle network things…really? Timeouts and in a few cases retries just landed like a year or so ago in most. The fact that ExtJS has queues is great! I know, when I wrote my book I had ZERO desire to implement any of this stuff to demonstrate but at the time no library had more than the most minimalistic form of request creation. The idea still is somewhat to shield users from this and the UI components is what is selling library adoption not the plumbing. But if plumbing is maturing now that’s great, a solid foundation is really needed.

Comment by ThomasAPowell — April 14, 2010

@ThomasAPowell
The question was more if other libraries consider queueing, taking the limited amount of concurrent connections into account.
It’s strange to me that everyone’s speaking and doing Ajax, but then again missing fundamentals regarding losing connections, timeouts etc. I have seen large applications where people wondered where their connection went when the user fires up a lot of communication with the server.

Comment by ThorstenSuckow — April 14, 2010

What is XMLHttprequest;?
Is HIGH a global identifier?

Comment by dhtmlkitchen — April 16, 2010

Leave a comment

You must be logged in to post a comment.