Re: Cross Origin and Resource Timing

I'm only following this from afar but...

>From my perspective as someone who helps optimise page load times I'd
prefer a detailed breakdown of the timing for the third party
resources to be available via resource timing.

My reading of the current version of the spec indicates that this
information won't be available unless the origin allows it.

As we divide sites up over multiple hostnames, include more third
party resources etc., then  the Timing-Allow-Origin is going to grow
or just get set to *

Having read 4.5 Cross-origin Resources a few times there something I'm
not clear on:

If I want to include a script from google.com and expose it's timings
I need a HTTP header of Timing-Allow-Origin : google.com

Does this also then also expose the resource timings for the page to
any scripts loaded from google.com or will CORS prevent this?

Thanks

Andy



On 16 February 2012 17:43, Jatinder Mann <jmann@microsoft.com> wrote:
> Considering one is able to obtain this data in other ways, I’m not opposed
> to providing the total duration but not the detailed breakdown of a
> cross-origin resource. This will make sure that the timeline makes sense and
> this API doesn’t omit resources that the page does use. Thoughts from the
> working group?
>
>
>
> From: Alois Reitbauer [mailto:alois.reitbauer@dynatrace.com]
> Sent: Thursday, February 16, 2012 2:27 AM
> To: public-web-perf@w3.org
>
>
> Subject: RE: Cross Origin and Resource Timing
>
>
>
> I am convinced that if we do not get an overall timing for third party
> resources it has very hard to understand their performance impact on the
> page. Our analysis shows that a lot of today’s pages spend more than two
> thirds of their time with Third Party resources.
>
>
>
> Getting these timings is also possible today. It requires a couple of hacks;
>  but works. We implemented it for our own monitoring, would however prefer
> if there is a better way to do this.  Following the principle that we expose
> the same information that people get today this information therefore can be
> exposed without adding an additional security hole. It will just be easier
> to access it and collecting this information and have less effect on page
> performance as it might have today.
>
>
>
> // Alois
>
>
>
> From: Jatinder Mann [mailto:jmann@microsoft.com]
> Sent: Wednesday, February 15, 2012 8:54 PM
> To: Alois Reitbauer; public-web-perf@w3.org
> Subject: RE: Cross Origin and Resource Timing
>
>
>
> Initially, I had thought that we had zero’d out the respondEnd attribute in
> error in the cross-origin restrictions section and that our intention was to
> give durations for even cross-origin resources.
>
>
>
> However, while looking at the Resource Timing Processing Model in more
> detail, I see that we had added the following clause:
>
>
>
> If the last non-redirected fetch of the resource is not the same origin as
> the current document and the Timing-Allow-Origin HTTP response header does
> not apply, the user agent must set redirectStart, redirectEnd,
> domainLookupStart, domainLookupEnd, connectStart, connectEnd, requestStart,
> responseStart, responseEnd, and duration to zero and abort the remaining
> steps.
>
>
>
> Not only is the duration explicitly set to zero, but steps to include this
> resource in the buffer are skipped. I believe the motivation here was that
> cross-origin resources should be explicitly not included in the
> PerformanceResourceTiming buffer. However, if someone were to look at the
> entire performance timeline, they could deduce that the gap was due to a
> cross-origin resource.
>
>
>
> An alternate proposal could be to provide the end to end time (fetchStart to
> responseEnd), but zero out the individual attributes.
>
>
>
> Does the working group recall why we went with the former approach?
>
>
>
> Thanks,
>
> Jatinder
>
>
>
> From: Alois Reitbauer [mailto:alois.reitbauer@dynatrace.com]
> Sent: Wednesday, February 15, 2012 12:06 AM
> To: public-web-perf@w3.org
> Subject: Cross Origin and Resource Timing
>
>
>
> As far as I can remember the final decision was that for cross origin
> resources which do not have the allow origin header set no detailed timings
> but the total time to download the resources is shown. I checked again with
> the latest version of the spec and it says
>
>
>
> , these attributes must be set to zero: redirectStart, redirectEnd,
> domainLookupStart, domainLookupEnd, connectStart, connectEnd, requestStart,
> responseStart, and responseEnd.
>
>
>
> This would mean that one only gets the fetchStart time which means that we
> only know when the download started but not when it is finished.
>
>
>
> Did I miss anything here?
>
>
>
> // Alois

Received on Friday, 17 February 2012 16:21:51 UTC