- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Wed, 14 Apr 2010 13:32:16 +0300
- 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 UTC