W3C home > Mailing lists > Public > public-web-perf@w3.org > September 2013

[ResourcePriorities] Lazy XMLHttpRequest

From: Benjamin Lerman <qsr@chromium.org>
Date: Thu, 26 Sep 2013 14:43:18 +0200
Message-ID: <CAEpg0+mN2VzJ5poxHAbyUdcQRJR=VTweat4Xg-_AtxVdvh63yg@mail.gmail.com>
To: public-web-perf@w3.org
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:36 UTC