Re: XMLHttpRequest Priority Proposal

On Tue, Apr 13, 2010 at 9:36 AM, Olli Pettay <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.
>>
>
>