W3C home > Mailing lists > Public > public-web-perf@w3.org > April 2011

Re: [minutes] 20110413 Web Performance WG Teleconference #28

From: Zhiheng Wang <zhihengw@google.com>
Date: Wed, 20 Apr 2011 10:46:07 -0700
Message-ID: <BANLkTin933RaVyt4RvE4XbUPxWc5kJ4Ocw@mail.gmail.com>
To: Jatinder Mann <jmann@microsoft.com>
Cc: "public-web-perf@w3.org" <public-web-perf@w3.org>
   Per Action Item #4, the spec now includes some discussion about the
monotonic clock:

https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html#mono-clock

<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html#mono-clock>
 Please check it out and we can discuss in today's meeting.

cheers,
Zhiheng

On Wed, Apr 20, 2011 at 10:10 AM, Jatinder Mann <jmann@microsoft.com> wrote:

> Web Perf Teleconference 4/13/2011
>
> IRC log http://www.w3.org/2011/04/13-webperf-irc
>
> Meeting Minutes: http://www.w3.org/2011/04/13-webperf-minutes.html
>
> Attendees
> Present
> Karen, Nic, Zhiheng, Christian
>
> Regrets
> Jatinder Mann
> Jason Weber
>
> Scribe
> Karen Anderson
>
> Contents
> Topics
> 1.  NavigationTiming Test updates
> 2.  NavigationTiming navigationStart in cross-origin redirected navigations
> 3.  NavigationTiming wall-clock time
> 4.  Feedback on 4/5 updates to Resource Timing
> 5.  Feedback on Unified Timing Proposal
> 6.  Discussion on User Timing
> 7.  Any other business
>
> Summary of Action Items
>  [NEW] ACTION: Karen to update the page reload test to update the timings
> [recorded in http://www.w3.org/2011/04/13-webperf-minutes.html#action03]
> [NEW] ACTION: Tony to investigate tests around no previous document
> scenarios [recorded in
> http://www.w3.org/2011/04/13-webperf-minutes.html#action02]
> [NEW] ACTION: Zhiheng to investigate tests around persistent connections
> [recorded in http://www.w3.org/2011/04/13-webperf-minutes.html#action01]
> [NEW] ACTION: Zhiheng to update the spec to include details on how the Nav
> Start should be implmented and how web devs should measure deltas [recorded
> in http://www.w3.org/2011/04/13-webperf-minutes.html#action04]
>
>
> --------------------------------------------------------------------------------
>
> <trackbot> Date: 13 April 2011
>
> <Karen_> Meeting: Web Perf Teleconference 4/13/2011
>
> <Karen_> scribe: Karen Anderson
>
> <Karen_> ScribeNick:Karen
>
> <Christian> also arvind is here
>
> <Karen_> agenda:this
>
> <plh> hi folks, I'm off site this afternoon and can't be on the phone for
> this hour
>
> <plh> sorry about that
>
> <Karen_> move to agenda 1
>
> <Karen_> Zhiheng: there might be other navigation scenarios that we should
> cover with testing
>
> <Karen_> Zhiheng: Some of these tests might be corner, but we should think
> about them more
>
> <Karen_> Nic: some to think about would be around persistent connections
>
> <Karen_> Nic: we do still need to add a check to the server redirect test
> to verify the origin server
>
> <Karen_> Tony: Caching is not enforced on all UAs so this might be
> difficult
>
> <Karen_> Tony: we might be able to fake this by adding pauses to the
> networking phases, or adding time in the load event
>
> <Karen_> Nic: That sounds like a good idea. This is also similar to the
> test around the previous unload if there wasn't one
>
> <Karen_> Zhiheng: We need to have tests for all of the MUST criteria of the
> spec.
>
> <Karen_> Zhiheng: Would should have a log of tests that we don't have so
> there is a record of what might be missing, or we need to make those
> sections non-normative
>
> <Karen_> Zhiheng: it's preferable to have the tests instead of changing the
> spec requirements
>
> <Karen_> Nic: We agree
>
> <Karen_> Tony: We should ask Philippe about this
>
> <Karen_> Tony: Looks like we are missing previous document tests and page
> reload
>
> <Karen_> ACTION: Zhiheng to investigate tests around persistent connections
> [recorded in http://www.w3.org/2011/04/13-webperf-minutes.html#action01]
>
> <trackbot> Created ACTION-19 - Investigate tests around persistent
> connections [on Zhiheng Wang - due 2011-04-20].
>
> <Karen_> ACTION: Tony to investigate tests around no previous document
> scenarios [recorded in
> http://www.w3.org/2011/04/13-webperf-minutes.html#action02]
>
> <trackbot> Created ACTION-20 - Investigate tests around no previous
> document scenarios [on Tony Gentilcore - due 2011-04-20].
>
> <Karen_> ACTION: Karen to update the page reload test to update the timings
> [recorded in http://www.w3.org/2011/04/13-webperf-minutes.html#action03]
>
> <trackbot> Created ACTION-21 - Update the page reload test to update the
> timings [on Karen Anderson - due 2011-04-20].
>
> <Karen_> Nic: Should we wait to add the navigationStart verification until
> after we settle that?
>
> <Karen_> Nic: We haven't been able to get a full security review around the
> navigationStart issue as people have been OOF at Mix
>
> <Karen_> move to agenda 2
>
> <Karen_> Zhiheng: I don't think we would be adding additional sec or IP
> data by allowing NavStart
>
> <Karen_> Nic: Does your sec team have no or little concern?
>
> <Karen_> Zhiheng: 2 things, this can already be done; having the timing
> here doesn't make any attacks any easier
>
> <Karen_> Christian: by not exposing this info then we can't actually
> measure the most basic nav scenario
>
> <Christian> that was arvind
>
> <Karen_> Arvind: Let's wait until MS can have the review and we can discuss
> more then
>
> <Karen_> Nic: we should be able to do this before next week
>
> <Karen_> move to agenda 3
>
> <Karen_> Nic: it was brought up the issue that if the user changes the
> system clock then the subsequent timings are not in relation to the nav
> start time
>
> <Karen_> Tony: We should have timings that play well with Date objects
>
> <Karen_> Nic: IE implements the timing so that it is all relevant
>
> <Karen_> Tony: the spec does have the recommendation to use UTC to support
> this
>
> <Karen_> Zhiheng: what is the time skew?
>
> <Karen_> Nic: the resolution of the Date object is not consistent which is
> one reason why there could be a skew
>
> <Karen_> Nic: it could be beneficial to have a note in the spec to outline
> this difference as a warning to web devs
>
> <Karen_> James: should we make it more explicit that the timings have
> different starting points
>
> <Karen_> Nic: no complaints here
>
> <Karen_> Zhiheng: don't think it's an issue with the spec currently and
> there isn't a strong dependency on the date object
>
> <Karen_> Zhiheng: we shouldn't change the spec, but instead make a
> recommendation on the correct implementation
>
> <Karen_> ACTION: Zhiheng to update the spec to include details on how the
> Nav Start should be implmented and how web devs should measure deltas
> [recorded in http://www.w3.org/2011/04/13-webperf-minutes.html#action04]
>
> <trackbot> Created ACTION-22 - Update the spec to include details on how
> the Nav Start should be implmented and how web devs should measure deltas
> [on Zhiheng Wang - due 2011-04-20].
>
> <Karen_> move to agenda 4
>
> <Karen_> Nic: there were a few spec updates
>
> <Karen_> Tony: waiting to hear more about the unified proposal first before
> feedback on the 4/5 updates
>
> <Karen_> move to agenda 5
>
> <Karen_> Tony: the motivation is too simplify the timings so that additions
> could be added at any time and not just these, to make this more future
> proof
>
> <Karen_> Tony: this also makes it so that it is not on by default
>
> <Karen_> Tony: different types of logs, app log and resource log. user is
> overloaded...anyway, start recording resource timings in that log,
> everything that hits the network goes into this log
>
> <Karen_> Tony: you can stop or clear the log at any time. There are methods
> to get the data out of the log. It's similar to how it's speced now, but
> they've realized that there isn't really movement that they can land right
> now. So looking for something to tie it all together with the DOM, etc
>
> <Karen_> Nic: It does reduce the functionality (good or bad) such as the
> initiator type, ids, or measures. But maybe this is good or bad...need to
> think it over
>
> <Karen_> Nic: we do want to have something that is future proof. it might
> make it hard to extend in the future such as widgets for example and if you
> only wanted to blue widgets
>
> <Karen_> Nic: it does give a more simplified view, but what if we had the
> current design and then the unified proposal is moved more to a script
> library
>
> <Karen_> Tony: Does this mean that we don't need multiple ways to access
> the data? Explain what you mean by different view of things.
>
> <Karen_> Nic: Assume we implement as speced today, the unified proposal
> could utilize the underlying data and then simplify the view, meaning a
> facade over what is really being stored
>
> <Karen_> Tony: I think that's true, but let me think about it more. Part of
> it is picking how the API should look and what should that view expose. We
> are shooting to capture the same underlying data
>
> <Karen_> Tony: the one contentious thing is whether to tie into the DOM. It
> could be a layered implementation and maybe it should. The question is how
> would this ultimately look.
>
> <Karen_> Tony: It seems that MS is worried that the unification is limiting
> to future exposure. The design should be something that will scale and I
> would be interested in a use-case to help support that.
>
> <Karen_> Nic: Pretend that we didn't implement NT, could that have fit into
> this? Some of it wouldn't like the redirect count and type. There could be
> others.
>
> <Karen_> we all agree that we want a design that will fit what we are
> working on today and what could come down the road.
>
> <Karen_> Tony: are UT and RT at a point that MS feels that we could land
> right now. We don't feel that way currently.
>
> <Karen_> Nic: No, we aren't at 99%, if you asked us a month back...no we
> weren't ready to implement. But now, we think we are making good progress
> and we aren't quite ready to implement yet due to ongoing updates and open
> issues, but maybe 70% confidence
>
> <Karen_> Nic: there isn't anything blocking us from implementation
> currently, but we would like to know what would block others from starting
> to implement now
>
> <Karen_> Nic: Over the last month we have been making good progress, do you
> agree?
>
> <Karen_> Zhiheng: I like the unifcation proposal, concern over RT is what
> we are going to expose. We don't have a good solution yet for xorigin, but
> agree that we are making good progress so far.
>
> <Karen_> Zhiheng: it is not the top priority to have the unification
> proposal nailed and instead figure out the details on the inclusion list. We
> should still think about the unification, but prioritze accordingly.
>
> <Karen_> Nic: agreed, we want to think about it, but not lose momentum on
> the RT details
>
> <Karen_> Tony: let's all look over the proposal and give feedback next
> week. The problem is tricky and hopefully it will trigger some other ideas
> from everyone to get to a great solution
>
> <Karen_> Nic: We still need to wait for Jatinder to be back to discuss
> deeper, but it's a great conversation piece for identifying holes in our
> current design
>
> <Karen_> Zhiheng: The spec should stay in Candidate Recommendation for now
> given the open issues.
>
> <Karen_> We didn't get to agenda 6 around UT.
>
> <Karen_> rragent, make log public
>
> <Karen_> rragent, draft minutes
>
> Summary of Action Items
> [NEW] ACTION: Karen to update the page reload test to update the timings
> [recorded in http://www.w3.org/2011/04/13-webperf-minutes.html#action03]
> [NEW] ACTION: Tony to investigate tests around no previous document
> scenarios [recorded in
> http://www.w3.org/2011/04/13-webperf-minutes.html#action02]
> [NEW] ACTION: Zhiheng to investigate tests around persistent connections
> [recorded in http://www.w3.org/2011/04/13-webperf-minutes.html#action01]
> [NEW] ACTION: Zhiheng to update the spec to include details on how the Nav
> Start should be implmented and how web devs should measure deltas [recorded
> in http://www.w3.org/2011/04/13-webperf-minutes.html#action04]
>
>
>
Received on Wednesday, 20 April 2011 17:46:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:30 UTC