- From: Benjamin Lerman <qsr@chromium.org>
- Date: Thu, 26 Sep 2013 14:43:18 +0200
- To: public-web-perf@w3.org
- Message-ID: <CAEpg0+mN2VzJ5poxHAbyUdcQRJR=VTweat4Xg-_AtxVdvh63yg@mail.gmail.com>
As of its current state, the Resource Priorities draft is targeting html elements. Another place where resource priorities can make sense is XMLHttpRequest (XHR). XHR also competes with other resources, so it can be useful to annotate low priority requests so that they could only be executed when all high priority requests have started. Moreover, even without other resources, letting some leeway to the UA for deciding when to start a request can be useful. For example, mobile devices can save power by batching network requests and, doing so, limit the time the radio is on. This could be done by adding an attribute to XMLHttpRequest: partial interface XMLHttpRequest { attribute unsigned long lazyLoadDelay; }; The default value would be 0. When lazyLoadDelay is 0, or if the request is synchronous, the behavior doesn't change. When lazyLoadDelay is greater or equals than 0, the browser must delay the request for at least the given delay (the value is in milliseconds). The guaranty are the same as the ones for setTimeout. The browser must consider those request to be of the same priority as a request for an element with the lazyload attribute and schedule the request the same way. An update to the attribute should be taken into account dynamically. In particular, setting the value to 0 should force the browser to start the request immediately as if lazyLoadDelay was 0 and send() was called. This would let the browser batch those requests with others and so, on a mobile device, prevent the radio to be started for those kinds of requests. -- Benjamin
Received on Friday, 27 September 2013 13:48:48 UTC