W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: XMLHttpRequest Priority Proposal

From: Mike Belshe <mbelshe@google.com>
Date: Wed, 14 Apr 2010 08:51:00 -0700
Message-ID: <l2jbccec9d81004140851g9d13646as496d5f66ca9c13a9@mail.gmail.com>
To: Olli@pettay.fi
Cc: public-webapps@w3.org
Wow, Olli -

You're fast!  This looks great - the demo is nice too!

mike


On Wed, Apr 14, 2010 at 3:32 AM, Olli Pettay <Olli.Pettay@helsinki.fi>wrote:

> 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 15:51:32 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:38 GMT