Re: XMLHttpRequest Priority Proposal
On Tue, Aug 3, 2010 at 5:45 AM, Anne van Kesteren wrote: > On Thu, 03 Jun 2010 17:37:05 +0200, Mike Belshe > wrote: > >> Here is an updated doc: >> >> https://docs.google.com/a/google.com/document/pub?id=1TcKtHi-XUVKXj9erQkkBXdidnG78lhK04D-2lh4O51Y >> > > Can you make this publicly available? Now it requires a google.comaccount. > Sorry about that. I've given up on google docs. I have no idea how to effectively share documents from it. I've moved the specification to here instead: http://www.belshe.com/test/xmlhttprequest.priorities.html <http://www.belshe.com/test/xmlhttprequest.priorities.html> > > > Should this also throw an INVALID_STATE_ERR exception just like timeout and > withCredentials do? See > > http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#the-timeout-attribute > > for details on those attributes. > Ok. > > > What prompted me to look at this again was a bug in WebKit I was added to. > I briefly looked through the patch there but the networking layer was doing > nothing at all with the field. (Well, it was not changed by this patch.) Is > this really something that is useful prior to the deployment of SPDY? And > are we sure SPDY is going to use something like this and that it will be > useful then? > The Google Maps team has used this technique quite effectively, seeing some pages reduce latency by ~70%. They have to fully schedule all resources manually, however, as they get no help from the browser today. > > I suppose we can always remove the property later, but it seems rather > experimental at this stage, so I am not sure whether I should add it. I think it gives developers a good way to manage complex applications, and it is pretty simple. Mike > > > > -- > Anne van Kesteren > http://annevankesteren.nl/ >
Re: XMLHttpRequest Priority Proposal
Correct. Sorry. Here is an updated doc: https://docs.google.com/a/google.com/document/pub?id=1TcKtHi-XUVKXj9erQkkBXdidnG78lhK04D-2lh4O51Y Mike On Thu, Jun 3, 2010 at 2:11 AM, timeless wrote: > On Wed, Jun 2, 2010 at 10:11 PM, Mike Belshe wrote: > > Changes: > >* changed the setPriority() method to be an attribute "priority" > > > 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() > > Presumably you intend to change these instances of 'setPriority()' to > reference setting the attribute? >
Re: XMLHttpRequest Priority Proposal
Finally cycling back on this.
Based on feedback from Olli and Anne, I have revised the spec.
Changes:
* changed the setPriority() method to be an attribute "priority"
* made priority be a string rather than a number
* inserted the "NORMAL" priority as the default XHR priority
Here is the updated doc.
Olli has implemented a patch (for the old spec) already:
https://bugzilla.mozilla.org/show_bug.cgi?id=559092
We'll be working on a Chromium/Webkit one shortly.
Mike
XMLHttpRequest Priority FetchingEvery 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 {
// Set the load priority for this request.
// The priority must be set before calling send().
// Valid priorities are:
// “CRITICAL”, “HIGH”, “NORMAL”, “LOW”, “LOWEST”
attribute string priority;
}
Example Usage:
var client = new XMLHttprequest;
client.priority = “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.
5 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 “NORMAL”.
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-LOWEST resources are deferred until all CRITICAL
resources have finished.
HIGH-LOWEST resources are loaded in that order. When no CRITICAL
resources are in progress, HIGH-LOWEST 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.
On Sun, Apr 18, 2010 at 10:37 PM, Anne van Kesteren wrote:
> On Fri, 16 Apr 2010 18:03:08 +0900, Mike Belshe
> wrote:
>
>> On Fri, Apr 16, 2010 at 1:37 AM, Anne van Kesteren
>> wrote:
>>
>>> I didn't actually propose an error condition and I'll note that your
>>> setPriority() proposal didn't handle errors either. E.g. what happens
>>> when I pass 20 as argument?
>>>
>>
>> Fair enough. :-)
>>
>> What I wanted was an enum, but I don't believe there is a way to do enums,
>> right?
>>
>
> Not currently, no.
>
>
>
> I think easiest would be to just ignore the setting as e.g. lineCap and
>>> lineJoin on the canvas 2D API do. Then errors are gracefully handled and
>>> by
>>> checking what priority is after setting you can see whether the
>>> implementation supports the feature.
>>>
>>
>> I'd take whatever people like most. Personally, I don't like using
>> strings for enums, but I can live with it.
>>
>> So you're proposing something like:
>>
>> var my_priority = "HGIH";
>> xhr.priority = my_priority;
>> if (xhr.priority != my_priority) {
>> // we detected an error
>> }
>>
>
> Yeah. Basically using strings makes it easier to extend the API going
> forward as numbers start clashing pretty soon.
>
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>
Re: XMLHttpRequest Priority Proposal
On Fri, Apr 16, 2010 at 1:37 AM, Anne van Kesteren wrote:
> On Fri, 16 Apr 2010 17:30:04 +0900, Mike Belshe
> wrote:
>
>> On Thu, Apr 15, 2010 at 11:00 PM, Anne van Kesteren > >wrote:
>>
>>> Other than that I wonder if we should maybe simply use string values to
>>>
>>> make it easier to extend this if we ever need to.
>>>
>>
>> The thing I don't like about that is the error condition of what happens
>> when someone sets it to "HIHG" (misspelled).
>>
>
> I didn't actually propose an error condition and I'll note that your
> setPriority() proposal didn't handle errors either. E.g. what happens when I
> pass 20 as argument?
>
Fair enough. :-)
What I wanted was an enum, but I don't believe there is a way to do enums,
right?
>
> I think easiest would be to just ignore the setting as e.g. lineCap and
> lineJoin on the canvas 2D API do. Then errors are gracefully handled and by
> checking what priority is after setting you can see whether the
> implementation supports the feature.
I'd take whatever people like most. Personally, I don't like using strings
for enums, but I can live with it.
So you're proposing something like:
var my_priority = "HGIH";
xhr.priority = my_priority;
if (xhr.priority != my_priority) {
// we detected an error
}
Mike
>
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>
Re: XMLHttpRequest Priority Proposal
On Thu, Apr 15, 2010 at 11:00 PM, Anne van Kesteren wrote: > On Wed, 14 Apr 2010 01:13:46 +0900, Mike Belshe > wrote: > >> // Set the load priority for this request. >> void setPriority(unsigned short priority); >> > > Any reason this is not an attribute named priority? > That is fine with me. > Other than that I wonder if we should maybe simply use string values to > make it easier to extend this if we ever need to. > The thing I don't like about that is the error condition of what happens when someone sets it to "HIHG" (misspelled). Thanks, Mike > > > -- > Anne van Kesteren > http://annevankesteren.nl/ >
Re: XMLHttpRequest Priority Proposal
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 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/opet...@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 > <mailto:olli.pet...@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.
>>
Re: XMLHttpRequest Priority Proposal
On Tue, Apr 13, 2010 at 9:36 AM, Olli Pettay 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
XMLHttpRequest Priority Proposal
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 FetchingEvery 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.
Stopwatch interval timer
For debugging performance in Chrome we wrote a high-res stopwatch API.
Specifically, we needed to measure sub-millisecond times. Currently there
is no mechanism for a javascript application to access fine-grained timers.
Is there any interest in standardizing something like this?
Here is the basic API we're using. We are not wed to this API, but we like
it because it is functional, minimalist, and easy to use. Feedback welcome.
function Interval() {
// Starts the interval timer
// If already started, restarts the start time.
this.start = function() {}
// Stops the interval timer.
// If the timer has not been started, has no effect
// If the timer has already been stopped, resets the stop time to now.
this.stop = function() {}
// Get the measured interval in microseconds.
// If the timer was started, but not stopped, gets the time since it was
started.
// Otherwise returns the difference between the stop and start times.
this.microseconds = function() {}
}
Thanks,
Mike
Mike Belshe
mbel...@google.com
