- From: Zhiheng Wang <zhihengw@google.com>
- Date: Mon, 20 Feb 2012 11:26:15 +0800
- To: Nic Jansma <nic@nicj.net>
- Cc: Jatinder Mann <jmann@microsoft.com>, James Simonsen <simonjam@chromium.org>, Ricardo Oliveira <rvelosoo@gmail.com>, "Tony Gentilcore (tonyg@google.com)" <tonyg@google.com>, Alois Reitbauer <alois.reitbauer@dynatrace.com>, "public-web-perf@w3.org" <public-web-perf@w3.org>
- Message-ID: <CAA1TnvVrDNhcEyR=dFDVaHqVs76U1f_TDxqiEKns9AeWph4EHQ@mail.gmail.com>
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