Re: Cross Origin and Resource Timing

   Thanks for the catch, Nic. Both places are changed accordingly.

cheers,
Zhiheng

On Sun, Feb 19, 2012 at 2:30 AM, Nic Jansma <nic@nicj.net> wrote:

>  I think the Processing Model needs to be updated as well.  In addition
> to not zero'ing out responseEnd and duration, it should say "and go to step
> 20" instead of "and abort the following steps" so the resource ends up in
> the buffer.
>
> - Nic
>
>
> On 2/18/2012 5:23 AM, Zhiheng Wang wrote:
>
>    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
>>
>>
>>
>>
>>
>
>

Received on Monday, 20 February 2012 03:26:45 UTC