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

[minutes] 20110406 Web Performance WG Teleconference #27

From: Jatinder Mann <jmann@microsoft.com>
Date: Wed, 6 Apr 2011 21:10:59 +0000
To: "public-web-perf@w3.org" <public-web-perf@w3.org>
Message-ID: <EE4C13A1D11CFA49A58343DE361B0B04067EE64C@TK5EX14MBXC254.redmond.corp.microsoft.com>
Web Perf Teleconference 4/6/2011
06 Apr 2011

IRC log http://www.w3.org/2011/04/06-webperf-irc

Meeting Minutes: http://www.w3.org/2011/04/06-webperf-minutes.html

Attendees
Present 
Nic Jansma, Jatinder Mann, Christian, Karen Anderson, Zhiheng Wang, Tony G, James Simonsen 

Regrets 
Philippe Le Hegaret
Arvind Jain

Meeting Chair 
Jatinder Mann

Scribe 
Jatinder Mann 

Contents
Topics 
1. Discuss whether to expose NavigationStart for all cases, even when redirecting. 
2. Discuss changes made to the Resource timing spec. 
3. Discuss Navigation Timing Test Cases 
4. Including HTTP Status Code as a part of the RT spec. 
5. Other feedback on the Resource Timing spec 
6. User Timing 

Summary of Action Items 
ACTION-18 - Follow up on test coverage and propose new test cases. [on Zhiheng Wang - due 2011-04-13].
Review Security concerns regarding exposing NavigationStart [on Jatinder Mann - due 2011-04-13].
Review proposed combining of Navigation Timing and Resource Timing and provide feedback on thread [on Jatinder Mann - due 2011-04-13].
Feedback on User Timing spec [on everyone - due 2011-04-13].
--------------------------------------------------------------------------------

<scribe> scribe: Jatinder Mann

Discuss whether to expose NavigationStart for all cases, even when redirecting.
Jatinder: Options are to either keep the NavigationStart and RedirectStart zero'd out for redirect case (current approach, previously agreed on)
... Or show NavigationStart for all cases, or clear out NavigationStart and RedirectStart for cross-domain cases.

Zhiheng: Developers may want to use NavigationStart to monitor percieved latency due to cross-domain redirects.

Nic: Cases when you're coming from a different domain, doesn't seem like a compelling reason, because site owner can't do anything. But in the sub-domain case, the developer can make changes to improve things.

Zhiheng: People can already use cookies to determine starting of navigation. There are similar cases.
... Might not be a good example, but a developer could already estimate the NavigationStart time. They could use an iframe.

Nic: Navigating from another site, there is no way to get that information. My biggest concern is showing NavigationStart is the same as showing RedirectStart.

Jatinder: It's a trade off between a feature and security. We need to determine whether the feature is worth more or if the security concern is less of a concern.
... Let us follow up with our security experts and see if the security issue is really an issue.
... We can get back to the thread with this information. If it's not a threat, we can opt into the feature. If it is, we should find a solution that balances security with usability.

Zhiheng: Okay, sounds good. I will look up for old information on this topic.
... Once we have that information and security, we can discuss this more.

Discuss changes made to the Resource timing spec.
http://w3c-test.org/webperf/tests/submission/Microsoft/NavigationTiming/

Jatinder went through the changes made to the Resource Timing spec.

Folks will review the changes and give feedback on the mail thread.

Discuss Navigation Timing Test Cases
URL to test cases: http://w3c-test.org/webperf/tests/submission/Microsoft/NavigationTiming/

Tony: We'll review the test cases and respond in mail.

Nic: How are we going to manage test case changes when changes are made to the spec?

Zhiheng: If we change the spec, we should also run through the tests and see what things break.

Nic: Are there major areas that we should look to submit new test cases?

Action Zhiheng to follow up on test coverage and propose new test cases.

<trackbot> Created ACTION-18 - Follow up on test coverage and propose new test cases. [on Zhiheng Wang - due 2011-04-13].

Including HTTP Status Code as a part of the RT spec.
Nic: We spoke briefly about including the HTTP status code, what are the thoughts about bringing this in?

Zhiheng: What is the security concern of doing this?

Nic: We're only returning the last status code, so the concern may be mitigated.
... Not sure what developer scenarios would this impact.

Tony: For developers point of view, it may be useful to see the status codes. But we have stayed away from showing information in the cache. We would probably need to follow the cross-origin rules.
... The status codes can imply when you're in the cache.
... You can get this information from your server logs anyway. It may nice to get this, but if its going to be complicated...

Jatinder: What are all the scenarios this would enable?

Nic: We should decide whether or not this is a worthwhile feature. We may want to see if there are any consumers for this feature and consider it later. There will be cross-domain issues we'll need to solve.

We've decided to punt on this feature as there isn't a particularly convincing scenario that we can imagine. Considering there will be cross-domain complications that would need to be solved, we should only consider this feature if there is a particular ask for this.

Other feedback on the Resource Timing spec
Tony: Have you considered the James' proposal?

Jatinder: What are the benefits of that proposal? I don't think I understood the main difference.

Tony: The problem with the current approach is we seem to be recreating the DOM tree with the id attribute.

Nic: What if we didn't include the id attribute?
... We may want to clarify that the current API is not like a DOM API, by cutting the getResourceById and getResourceByType.

Tony: That's interesting. That may resolve some of the concern.
... What about extensibility? The current model requires updates to the namespaces, etc.

Nic: With our aggressive schedule, it may make sense not to consider major changes unless there is signifcant value.

Jatinder: Let us follow up and look at the proposal more carefully and give both pro and con feedback on the mail thread.

Tony: That seems like a more productive approach.

User Timing
Jatinder: Considering User Timing has the same deadlines as Resource Timing, let's spend some time next call discussing feedback on the User Timing spec. Please feel free to email the thread with any feedback on that spec.
Received on Wednesday, 6 April 2011 21:11:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:01:07 UTC