I'm a developer on the chrome team, and also working on SPDY.

Others here at Google have requested that we expose some of the
priority-based resource loading mechanics to applications so that
applications can hint to the browser more information about which resources
are critical and which are not.  Some of the Google Apps teams have already
implemented their own, manual priority-based resource fetchers, and our maps
team saw a huge latency reduction as a result of doing so.  Internally to
chromium and webkit, resource loading is also priority-aware today.
 Finally, in SPDY, we've observed good improvements by exposing priorities
all the way across the protocol.  We believe exposing priority on the XHR
object may benefit many applications manage their resource loads.

Here is a quick writeup of one proposal which we think would work in
browsers.  We believe it is backward compatible with existing XHR, and can
be optionally implemented.  It also leaves a fair amount of the tuning at
the discretion of the browser, so it does not create a long-term liability
in the browser.  We hope that these considerations make it an easy choice to

I'm wondering if the XMLHttpRequest group would be interested in taking this


XMLHttpRequest Priority FetchingEvery 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

Proposed API:
interface XMLHttpRequest {
 // XMLHttpRequest Priorities.
 const unsigned short CRITICAL = 0;
 const unsigned short HIGH = 1;
 const unsigned short LOW = 2;
 const unsigned short LOWEST = 3;

 // Set the load priority for this request.
 void setPriority(unsigned short priority);

Example Usage:
var client = new XMLHttprequest;
client.open(’GET’, ‘demo.cgi’);

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
applicaiton 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

Browsers are not required to support the priority requested by applications,
and may ignore it altogether.  However, browsers are encouraged to support
the requested priority order.  The following is a description of one
possible prioritization policy:
  CRITICAL resources are loaded first.  When CRITICAL resources are in
progress, requests for HIGH/MEDIUM/LOW resources are deferred until all
CRITICAL resources have finished.
  HIGH/MEDIUM/LOW resources are loaded in that order.  When no CRITICAL
resources are in progress, HIGH/MEDIUM/LOW resources will be loaded with
HIGH priority first.  The browser does not need to wait until higher
priority resources have finished fetching before it starts a request for a
lower priority resource, although it may chose to do so.

Existing Implementations:
Google is currently using resource prioritization techniques in its Google
Maps application, internally to the Google Chrome browser, and also as a
part of the SPDY protocol.

Reply via email to