- From: Mike Belshe <mbelshe@google.com>
- Date: Wed, 14 Apr 2010 08:51:00 -0700
- To: Olli@pettay.fi
- Cc: public-webapps@w3.org
- Message-ID: <l2jbccec9d81004140851g9d13646as496d5f66ca9c13a9@mail.gmail.com>
Wow, Olli -
You're fast! This looks great - the demo is nice too!
mike
On Wed, Apr 14, 2010 at 3:32 AM, Olli Pettay <Olli.Pettay@helsinki.fi>wrote:
> 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 15:51:32 UTC