RE: Resource Timing

The design and approach of ResourceTiming is still nascent. Some of the key challenges we face are:

i.                     Efficient resource management and lifetime of the resource timing object, that is when to allocate and clean-up resource timing objects.

ii.                   Minimizing the performance degradation of collecting timing about resources.

iii.                  Privacy and security implications of cross-domain requests for the timing information.

We've been exploring various approaches like using the http header or the meta element to allow for "opt-in" scenarios to gather timing information. Particularly for cross-domain access of resource timing information we're also exploring various possibilities like CORS [1] and Web Messaging [2].

We'll need to investigate and tackle these issues and be cognizant about the trade-offs with each approach.

Cheers,
Anderson Quach
IE Program Manager

[1] http://www.w3.org/TR/cors/
[2] http://dev.w3.org/html5/postmsg/


From: public-web-perf-request@w3.org [mailto:public-web-perf-request@w3.org] On Behalf Of Zhiheng Wang
Sent: Tuesday, August 24, 2010 1:57 PM
To: Bryan McQuade
Cc: Jason Sobel; public-web-perf@w3.org
Subject: Re: Resource Timing

    In the example here, you can look into the DNS time and TCP time of the resource fetched from
otherdomain.com<http://otherdomain.com> and figure if the user has recently (or even currently) visit otherdomain.com<http://otherdomain.com>. And
we are saying that, this should happen only if otherdomain.com<http://otherdomain.com> allows it.

thanks,
Zhiheng
On Tue, Aug 24, 2010 at 1:50 PM, Bryan McQuade <bmcquade@google.com<mailto:bmcquade@google.com>> wrote:
This seems more restrictive than the same origin policy. IMO any
resource loaded by a document should be visible by that document by
default, regardless of where that resource came from.

If I have an HTML document at http://example.com/ that looks like:

<html>
<body>
<src src="http://otherdomain.com/foo.js"></script>
</body>
</html>

It seems unnecessary to hide the timing information about
http://otherdomain.com/foo.js from my page. I know full well that my
page is trying to load this resource, as it's explicitly declared in
my HTML. This goes for any resource loaded into my document.

Why do you think it is necessary to require the header for resources
loaded in the same document?

On Tue, Aug 24, 2010 at 4:36 PM, Zhiheng Wang <zhihengw@google.com<mailto:zhihengw@google.com>> wrote:
>    I actually did mean "HTML header". :-) HTTP header requires changes to
> the http server configure, which is not always
> feasible for developers.
> thanks,
> Zhiheng
>
> On Tue, Aug 24, 2010 at 1:25 PM, Jason Sobel <jsobel@facebook.com<mailto:jsobel@facebook.com>> wrote:
>>
>> I assume you mean an HTTP header? If so, that sounds totally reasonable.
>>
>> Thanks!
>>
>>
>>
>>               --jason
>>
>>
>>
>> From: Zhiheng Wang [mailto:zhihengw@google.com<mailto:zhihengw@google.com>]
>> Sent: Tuesday, August 24, 2010 1:21 PM
>> To: Jason Sobel
>> Cc: Bryan McQuade; public-web-perf@w3.org<mailto:public-web-perf@w3.org>
>> Subject: Re: Resource Timing
>>
>>
>>
>>    fbcdn.net<http://fbcdn.net> can set its html header, say "allow-timing-access", to allow
>> facebook.com<http://facebook.com> to access timing information on those resources
>>
>> served from it. That should answer your question?
>>
>>
>>
>> cheers,
>>
>> Zhiheng
>>
>> On Tue, Aug 24, 2010 at 12:37 PM, Jason Sobel <jsobel@facebook.com<mailto:jsobel@facebook.com>> wrote:
>>
>> The case I'm mostly worried about is where we (facebook.com<http://facebook.com>) host our
>> static resources on a different domain (fbcdn.net<http://fbcdn.net>). I'd like some way to
>> allow fbcdn.net<http://fbcdn.net> to "opt in" to giving timing information to facebook.com<http://facebook.com>. At
>> one point CORS (http://www.w3.org/TR/cors/) was mentioned as a possible
>> solution.
>>
>> I look forward to seeing what you come up with Zhiheng. Thanks!
>>
>>              --jason
>>
>> -----Original Message-----
>> From: Bryan McQuade [mailto:bmcquade@google.com<mailto:bmcquade@google.com>]
>> Sent: Tuesday, August 24, 2010 12:32 PM
>> To: Zhiheng Wang
>> Cc: Jason Sobel; public-web-perf@w3.org<mailto:public-web-perf@w3.org>
>> Subject: Re: Resource Timing
>>
>> Interesting. Can you expand on the meta header approach?
>>
>> I assume you are referring to a case where a child iframe is on a
>> different origin. In that case it would not be appropriate to leak the
>> timing info for the frame up to the parent. But it sounds like this
>> meta header might allow the child frame to give permission to leak the
>> info to the parent?
>>
>> On Tue, Aug 24, 2010 at 12:49 PM, Zhiheng Wang <zhihengw@google.com<mailto:zhihengw@google.com>>
>> wrote:
>> >     The immediate questions for ResourceTiming is how to maintain
>> > privacy
>> > while exposing those timing information.
>> > So far using meta header on top of the same origin policy seems to be
>> > the
>> > way to start. An update should be available
>> > later this week.
>> > cheers,
>> > Zhiheng
>> >
>> >
>> > On Mon, Aug 23, 2010 at 12:41 PM, Jason Sobel <jsobel@facebook.com<mailto:jsobel@facebook.com>>
>> > wrote:
>> >>
>> >> Hey all-
>> >>
>> >> Looks like you're making great progress on navigation timing -- very
>> >> exciting!
>> >>
>> >>
>> >>
>> >> Do you have any thoughts on polishing and implementing resource timing?
>> >> That data is very interesting to us at Facebook so I'm hoping it will
>> >> be
>> >> available in all the major browsers sooner rather than later.
>> >>
>> >>
>> >>
>> >> Thanks much!
>> >>
>> >>
>> >>
>> >>               --jason
>> >>
>> >>
>> >
>>
>>
>

Received on Tuesday, 24 August 2010 21:05:26 UTC