W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: XMLHttpRequest Priority Proposal

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Wed, 14 Apr 2010 13:32:16 +0300
Message-ID: <4BC599B0.5050007@helsinki.fi>
To: Mike Belshe <mbelshe@google.com>
CC: public-webapps@w3.org
Hi Mike,

FYI,
I wrote a wip patch for Gecko.
https://bugzilla.mozilla.org/show_bug.cgi?id=559092
Test builds will be here:
https://build.mozilla.org/tryserver-builds/opettay@mozilla.com-xhr_priority/



-Olli

On 4/13/10 8:36 PM, Mike Belshe wrote:
> On Tue, Apr 13, 2010 at 9:36 AM, Olli Pettay <Olli.Pettay@helsinki.fi
> <mailto:Olli.Pettay@helsinki.fi>> wrote:
>
>     Hi,
>
>
> Thanks for the comments.
>
>     this seems like a pretty useful, yet reasonable easily implementable
>     feature.
>
>
> Good to hear.
>
>     I'd add 5th value "NORMAL", which would be the default value.
>
>        const unsigned short CRITICAL = 0;
>        const unsigned short HIGH = 1;
>        const unsigned short NORMAL = 2
>        const unsigned short LOW = 3;
>        const unsigned short LOWEST = 4;
>
>     Not sure if we need all the values, or would
>     HIGH, NORMAL, LOW be enough?
>
>
>
>   I'm not fussy about what priorities are exposed or what we call them -
> so long as they are relatively few in number to avoid unnecessary
> complexity.  (e.g. 3-5 priority buckets seems fine)
>
> Mike
>
>
>
>     -Olli
>
>
>
>     On 4/13/10 7:13 PM, Mike Belshe wrote:
>
>         Hi,
>
>         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 approve.
>
>         I'm wondering if the XMLHttpRequest group would be interested in
>         taking
>         this on?
>
>         Thanks,
>         Mike
>
>
>           XMLHttpRequest Priority Fetching
>
>         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:
>         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.setPriority(HIGH);
>         client.open(’GET’, ‘demo.cgi’);
>         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 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 load.
>
>         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.
>
>
>
Received on Wednesday, 14 April 2010 10:32:57 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:38 GMT