[minutes] 20110309 Web Performance WG

Web Performance Working Group Teleconference
09 Mar 2011

See also: IRC log<http://www.w3.org/2011/03/09-webperf-irc>

Attendees
Present
Anderson, Arvind, JamesSimonsen, JasonWeber, Jatinder, KarenAnd, Nic, Tonyg, Zhiheng, plh
Regrets
Chair
Arvind
Scribe
Jatinder
Contents

  *   Topics<http://www.w3.org/2011/03/09-webperf-minutes.html#agenda>
     *   Tests for Navigation Timing to review<http://www.w3.org/2011/03/09-webperf-minutes.html#item01>
  *   Summary of Action Items<http://www.w3.org/2011/03/09-webperf-minutes.html#ActionSummary>

i.              Arvind will send e-mail about details a face-to-face meeting to discuss the additions to the charter proposal.

ii.             Anderson will validate the Back-Forward test and move to the approved folder and update proposed tests.

iii.            Anderson will update the User Timing propose with the ability to use built in marks as described in Navigation Timing.

iv.           Homework for all, propose when resource timings should be collected.

________________________________

<trackbot> Date: 09 March 2011

<scribe> Meeting: Web Perf WG

Scribe+ Jatinder Mann

Philippe: Charter is on schedule.

Zhiheng: Do we have editors in place for all the specs?
... We may want to organize another face to face meeting.

Arvind: Agree that we need a face to face to decide the format.

Anderson: That is a fantastic idea. Do one relatively soon, with video conferencing so Cameron can also join.
... We are definitely open to hosting the face to face in Redmond, since the last one we had was in Google.

Tony: There is a lot of forward momentum on these and we should discuss the high level overlaps before we get down too far.

Arvind: Let me take an action item to determine the location and time of the face to face meeting.

Philippe: Are we going to send email to the group? To kick off the discussion.

Arvind: Yes.

Philippe: In the email we should also ask if we want a new teleconference time.

Arvind: I will both send an email to decide the time for the face to face and determine the new teleconference time.
... I think sometime around 1pm PST would be good for teleconference time.
... That takes care of agenda #1.

Anderson: I will coordinate with Jason to organize the face to face

Move to agenda 2
Tests for Navigation Timing to review

Anderson: I will batch all the submissions up after this meeting and will move it over to the approved folder.
... Are there any additional tests?

<tonyg> http://w3c-test.org/webperf/tests/submission/Google/NavigationTiming/test_document_open.htm

Nic: We're looking at it right now.

Anderson: Where does it throw access is denied?
... We will look at this after the call.
... Let's move on to Agenda 3.

Philippe: Regarding Navigation timing, I sent email asking about dependencies. Is there any clarification on that?

Anderson: From my knowledge, as long as we have a conforming IDL and we're also using the readystate from HTML document. Those are the only two that come to mind

Phillipe: For WebIDL, I'm not sure there is a solution.

Zhiheng: I don't see much problem on this one for now.

Anderson: So we're on track for the 11th to publish?

Phillipe: No. I will do my best to try to be on track.

Anderson: Let's get started with Resource Timing (Agenda 3)

<zhiheng> http://test.w3.org/webperf/specs/ResourceTiming/

Anderson: Please walk us through the deltas.

Zhiheng: One of the most important one is that we removed the resource timing connector.

Anderson: One thing we wanted to discuss, the behavior of enabled vs. disabled

Zhiheng: Those would go into the privacy issue.
... getResourceTimeByLocation - I think ByType would be more useful.

Anderson: The ability to access an element by all its different monikers. Elements on a page are not unique (multiple img elements with the same id). We wanted to come up with the most flexible way to access a resource.

Zhiheng: We can just edit to getResourceTimeByType.

Anderson: The diff looks good. Are we ready to discuss the details of the timing per element?

Zhiheng: I think for the interfaces we can start discussing them.

Anderson: The model we had discussed last time was safe by default.

Zhiheng: My main question is how do we cross domain as a control

Anderson: Still major issue to deal with.

Zhiheng: In terms of interfaces, do you have any suggestions or ideas?

Tony: I don't understand allowedDomains
... Let's say a resource is used multiple times by the same or different elements - would there be multiple copies?

Nic: I would say it's unique for resource fetched from the network.

Zhiheng: In terms of the privacy, if we don't allow the cross-domain access, we only provide the start and ending timing. That is already available today.

Nic: We would be reporting resources from the cache.
... How would that be exposed? For the first resource that asked for it?
... Is it reported for each element or is it only reported once?

Zhiheng: The first one is from the network, the last one is from the cache.
... That's a good point though.

Nic: I think it can be kind of tricky. Browsers today if the same resources are used from the page, we don't go get it from the network.

Tony: If there is a 1x1 pixel gif. If I use it a 100 times on the page, do I have it a 100 times?

Karen: This is where getElementByID is useful.

Nic: In the list of all the things downloaded from the page would we show it multiple times?

Zhiheng: Thats what the current job is assuming.

Karen: Pretend like we have a 100 times and we are JSONing them all back, it becomes interesting to know how the DOM starts getting downloaded. Imagine parsers being different per user agents. Several variations.

Nic: Taking a step back, the goal for resource timing is to try to get something like the Network Inspectors. Do we agree that that is kind of the goal?

Tony: That is what I've had in mind here.

Nic: The browsers would not display the img element over and over again if it was displayed.
... We should probably be more explict about which resources should be in the list.

Anderson: It's a valid question: the latency between fetching from the cache and displaying the retroactive waterfall display in the network inspector.
... It's interesting to consider how we would normalize cache access.

Zhiheng: If we consider each element a subdocument, I'm trying to make it consistent with the navigation timing.
... Like we found in navigation timing, it's not always possible to get the exact timing of the resource going to the wire.

Nic: As soon as we start exposing the fact that we get from the cache, we are exposing the user's browsing history.
... We don'tw ant to make it easier for an attacker to determine which resources have already been loaded.

Anderson: We store the timings for only those that we have downloaded. This allows inline defining for images. If we start thinking about accessing resources locally, we would need to bring in the ability of accessing inline resources. That goes beyong what we had initialy thought about. That would reduce a lot of the traffic - minimize the noisyness of having using a resource 100 times.
... Simplicity, privacy, and consistency would be the goal.

Zhiheng: Not sure how this would add to the privacy concern here.
... Everything that can be done by this API can already be done by the webpage.

Nic: You are right in the fact that a page could determine this. One of the concerns could be to not explicitly expose we are getting this from the cache.
... As long as expose the same level of granularity. It can be deduced that a resource was downloaded from the cache.
... Goal would be to not give any higher precision whether something was in the cache or not. In the case of going to a page and looking at the resources, if anything is downloadable resource, we would put it in there.
... Not sure how to precisely describe this in the spec.

Zhiheng: I understand. This kind of filtering may be confusing to the user.

Nic: In the case of 1x1 gif used a 100 times case, the browser would use a in memory cache to reuse this. I don't suggest that all several 100 be included in the cache, only the initial request?

Anderson: Tony, James, any comments on the approach that we capture timing for the downloadable? Anything that was in memory cache, we don't necessarily have timing information for.

Tony: The difference between the memory cache and the disk cache would be confusing for the user.
... We should think about here is what the page downloaded rather than downloadable.

Anderson: Downloaded instead of downloadable?

Tony: Perhaps. Reduces confusion about memory and disk cache.

Nic: The worry here is that it gives higher precision to if resources weren't in the cache.

Tony: I forgot what the privacy concern was.

Nic: For example, you can build an attacker page that includes a bank logo.

Tony: We want to report anything that is cross origin.

Nic: We wouldn't be providing anything we just saying fetchStart and loadEnd. Not including it from the list would say for sure it was. Not sure how important this is.

Tony: I see, makes sense.

Zhiheng: Example is there is a page, and I want to see if the user has visited a bank page. I can still get that information. If I don't see the timing in the resource timing interface, I can assume that this is the cache.

Nic: Correct, if we didn't include things into the cache.

Zhiheng: They can still guess if a user ever visited a page.

Nic: They can get that today. There is a higher precision if we're saying that if its not cached, we'll put it in the cache. I know its not a huge difference, but its a stronger indication that its in the cache.

Zhiheng: If you posted a request but you don't see a timing in the buffer, you can see this also.

Anderson: Good point.

Tony: Maybe we should only expose timing for same origin.

Anderson: I know this is where Jason would step in and say he would like cross domain origin.

Tony: I think he's interested in the additional details.

Anderson: Certainly, adds more pressure for us to come up with a solution for cross domain access.

Karen: Even same origin, this issue is important. The tracking of a user's browsing history is important privacy concern. Say on a banking site, you put a resources for checking, saving account - one could deduce what kind of user is on the page. Now you're dealing with a tracking of a user.

Nic: If you own the domain, you own everything on it. You own the server technology.

Karen: You could theoritically do this through sessions, but now you know through the JSON session, you know it's one user.

Tony: Sounds like the big homework for this week will be figuring out when things should go into the event log.

Zhiheng: Yes, agree.

Anderson: Alright then, let's follow up with the various proposals of accessing resources and where we would log. The when and where question.
... Hard stop at 10?

Zhiheng: I can stay.

Arvind: I will leave.

regret: Arvind

Anderson: Let's move to User Timing

http://test.w3.org/webperf/specs/UserTiming/

Anderson: Some points I wanted to raise. Let's first go over deltas.

First set of changes was that the marks were added and three additional measure apis were added.

Anderson: One thing I wanted to note was that the difference between the user timing and resource timing, is that the marks/data is not generated by the UA, but rather developed by the developer.

Tony: Right.

Anderson: I should add that you can measure from a user agent mark. Like a navigation start.

Zhiheng: Sounds good.

Tony: We are getting kicked out from our room.

Zhiheng: Navigation start lives in a different namespace.

Anderson: If a UA supplied mark name, we recommend throwing an exception - make it read only and don't store the time stamp.