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****
>>
>>
>