Re: Cross Origin and Resource Timing

   Done.

cheers,
Zhiheng

On Sat, Feb 18, 2012 at 1:16 AM, Jatinder Mann <jmann@microsoft.com> wrote:

>  I think we are all in agreement. Please update the Resource Timing spec.*
> ***
>
> ** **
>
> Thanks,****
>
> Jatinder****
>
> ** **
>
> *From:* Zhiheng Wang [mailto:zhihengw@google.com]
> *Sent:* Thursday, February 16, 2012 11:24 PM
> *To:* James Simonsen
> *Cc:* Jatinder Mann; Ricardo Oliveira; Tony Gentilcore (tonyg@google.com);
> Alois Reitbauer; public-web-perf@w3.org
>
> *Subject:* Re: Cross Origin and Resource Timing****
>
> ** **
>
>    I think the consensus of the WG was to keep the starting and ending
> time just like we discuss here. The text in the****
>
> draft is some left-over from previous revisions: we used to have
> "fetchEnd" in the x-origin case so zeroing out responseEnd****
>
> is fine. But later we removed fetchEnd from the spec... ****
>
> ** **
>
>    If no objection, I will fix the the text and keep the value of
> responseEnd.****
>
> ** **
>
> cheers,****
>
> Zhiheng****
>
> On Fri, Feb 17, 2012 at 7:18 AM, James Simonsen <simonjam@chromium.org>
> wrote:****
>
> I don't remember deciding to zero everything out. I'll have to dig through
> the archives I guess. Can we use source control to see when these changes
> went in?****
>
> ** **
>
> My recollection and intent was to have startTime and duration available,
> since you can basically get those with Javascript timestamps. All of the
> other details would be zero. That should at least make them useful on the
> timeline, but without exposing anything that couldn't be seen before.****
>
> ** **
>
> James****
>
> ** **
>
> On Thu, Feb 16, 2012 at 10:02 AM, Jatinder Mann <jmann@microsoft.com>
> wrote:****
>
> Adding James, Tony and Zhiheng, since they were involved in the initial
> discussions. ****
>
>  ****
>
> If we want to give the total duration for cross origin resources, we would
> update the processing model to not zero out responseEnd and include the
> resource in the PerformanceResourceTiming buffer. StartTime is already
> defined for cross origin resources in the processing model.****
>
>  ****
>
> Jatinder****
>
>  ****
>
> *From:* Ricardo Oliveira [mailto:rvelosoo@gmail.com]
> *Sent:* Thursday, February 16, 2012 9:52 AM
> *To:* Jatinder Mann
> *Cc:* Alois Reitbauer; public-web-perf@w3.org
> *Subject:* Re: Cross Origin and Resource Timing****
>
>  ****
>
> I thought that was agreed already... Alois question is about how to get
> the total time since the final timestamps are all zeroed****
>
>  ****
>
> Cheers****
>
>  ****
>
> --Ricardo ****
>
> Thousandeyes.com****
>
>  ****
>
>  ****
>
>  ****
>
>
> Sent from my iPhone****
>
>
> On Feb 16, 2012, at 9:43 AM, 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<http://www.w3.org/TR/html5/fetching-resources.html#fetch>of the resource is not the same origin as the current document and the
> Timing-Allow-Origin<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html#timing-allow-origin>HTTP response header does not apply, the user agent must set
> redirectStart<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html#redirect-start>,
> redirectEnd<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html#redirect-end>,
> domainLookupStart<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html#domainlookup-start>,
> domainLookupEnd<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html#domainlookup-end>,
> connectStart<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html#connect-start>,
> connectEnd<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html#connect-end>,
> requestStart<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html#request-start>,
> responseStart<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html#response-start>,
> responseEnd<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html#response-end>,
> and duration<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html#duration-attribute>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<http://w3c-test.org/webperf/specs/ResourceTiming/#redirect-start>,
> redirectEnd<http://w3c-test.org/webperf/specs/ResourceTiming/#redirect-end>,
> domainLookupStart<http://w3c-test.org/webperf/specs/ResourceTiming/#domainlookup-start>,
> domainLookupEnd<http://w3c-test.org/webperf/specs/ResourceTiming/#domainlookup-end>,
> connectStart<http://w3c-test.org/webperf/specs/ResourceTiming/#connect-start>,
> connectEnd <http://w3c-test.org/webperf/specs/ResourceTiming/#connect-end>,
> requestStart<http://w3c-test.org/webperf/specs/ResourceTiming/#request-start>,
> responseStart<http://w3c-test.org/webperf/specs/ResourceTiming/#response-start>,
> and responseEnd<http://w3c-test.org/webperf/specs/ResourceTiming/#response-end>
> .****
>
>  ****
>
> 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****
>
>    ** **
>
> ** **
>