- 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