- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Tue, 13 Apr 2010 19:36:37 +0300
- To: Mike Belshe <mbelshe@google.com>
- CC: public-webapps@w3.org
Hi, this seems like a pretty useful, yet reasonable easily implementable feature. 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? -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 Tuesday, 13 April 2010 16:37:16 UTC