Hi Mike,

I wrote a wip patch for Gecko.
Test builds will be here:


On 4/13/10 8:36 PM, Mike Belshe wrote:
On Tue, Apr 13, 2010 at 9:36 AM, Olli Pettay <olli.pet...@helsinki.fi
<mailto:olli.pet...@helsinki.fi>> wrote:


Thanks for the comments.

    this seems like a pretty useful, yet reasonable easily implementable

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)



    On 4/13/10 7:13 PM, Mike Belshe wrote:


        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
        make it an easy choice to approve.

        I'm wondering if the XMLHttpRequest group would be interested in
        this on?


          XMLHttpRequest Priority Fetching

        Every performant web browser implementation today implements various
        heuristics for resource loading prioritization internally.  The
        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
        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.open(’GET’, ‘demo.cgi’);

        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()
        on the XMLHttpRequest object.  The priority set on the object at the
        time the applicaiton calls the XMLHttpRequest.send() method
        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
        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.

Reply via email to