- From: Jatinder Mann <jmann@microsoft.com>
- Date: Thu, 5 May 2011 00:59:53 +0000
- To: "public-web-perf@w3.org" <public-web-perf@w3.org>
- Message-ID: <EE4C13A1D11CFA49A58343DE361B0B0406834342@TK5EX14MBXC252.redmond.corp.microsoft.>
Thank you for meeting on the call today. I have given the meeting summary below: 1. Discussed Resource Timing and User Timing Proposed changes We discussed and agreed to the following changes to the spec: - Removed "id" attribute and getResourceTimingsByID method from Resource Timing spec We all agreed to removing the attribute and method from the spec, as the "id" attribute doesn't always make sense for some resources like CSS or plugin sub-resources, it is a snapshot at a given time which may change, it may not be unique and it's not consistent with the other timing specs. - Keep measure methods in the User Timings spec but explore ways to improve the API in the User Timing spec We agreed that were was value in having a standardized method to get timing measurement between marks. However, there was some concern that the measure API could be more better defined with respect to the marks concept. Tony and James will follow up with some suggested updates to the measures API. - Keep "type" attribute, but remove getResourceTimingsByType method from Resource Timing spec We agreed that there is value in keeping the type data in the timing array, if the user would like to pivot between resource initiator types. The example given was if one was to pull video and image snapshot data from a news server but all the URLs had the same format and weren't known prior, and the web developer was interested in viewing only one type of resource, the type information would be useful. We did agree that the getResourceTimingsByType accessor method may not be needed, as a developer can sort through the array themselves. - Keep Resource Timing to be on by default, however, reduce the maximum number of resources captured from 1000 We agree that there is significant value in keeping the Resource Timing feature turned on by default. The example case is if an analytics library wants to use Resource Timing for an existing site, the site owner doesn't need to update their site to turn on Resource Timing. We, however, agreed that the default maximum number of resources should be reduced from 1000. If a site needs more, they can always increase the buffer. I am to analyze data and recommend a smaller default buffer size. 2. Reviewed the Resource Timing Processing Model updates We agreed with the processing model in principle. A few updates were suggested that I am to fix: o Cut fetchEnd as it is redundant with responseEnd and is not consistent with Navigation Timing o The processing model should be clear the secureConnectionStart is optional 3. Reviewed the Page Visibility updates We discussed and agreed to the following changes to the spec: - Window, rather than Navigator, to implement WindowVisibility interface We agreed that Navigator wasn't the right place for this interface. We are concerned there might be collisions with the 'visible' attribute name and user variables, as window is the global namespace for scripts. I am to follow up and check how common the following names are used and suggest a new name: window.visible, document.visible, window.pageVisible and document.pageVisible. - Event name changed to visibilitychange We agreed that the event name should be visibilitychange. We also discussed whether we shouldn't allow onvisibilitychange support. I am to follow up with the implications. - Visibility definitions generalized We agreed that new generic visibility definitions were better suited than the specific definitions. - Visibility states reduced We agreed that one preview state was better than the initial two states. James raised the issue of whether we need a PAGE_OTHER constant; I am to follow up to see the historic reasons for doing this and whether it is still applicable. - Examples updated We agreed that the new examples were better. 4. Reviewed the RequestAnimationFrame spec We agreed that we need to have some verbiage in the spec to describe the callback rate should match the refresh rate of the display and that a maximum callback defined to avoid benchmark abuse. James was also going to update the spec folder from AnimationRequestFrame to RequestAnimationFrame before the incorrect name became popular. We had the following action items from this meeting: - Tony Gentilcore and James Simonsen: to follow up with a proposal to make the measure API more coherent with the marks concept. - Jatinder Mann: Analyze data to see what the recommended buffer size should be. - Jatinder Mann: Update RT processing model to cut fetchEnd and make clear that secureConnectionStart is optional - Jatinder Mann: To analyze data to see which of the following names to use for PageVisibility: window.visible, document.visible, window.pageVisible and document.pageVisible - Jatinder Mann: Implications of not supporting onvisibilitychange. - Jatinder Mann: To follow up and see if PAGE_OTHER is required. - James Robinson: To update the spec folder to RequestAnimationFrame. The meeting minutes are given below: Web Perf Teleconference 5/04/2011 IRC log: http://www.w3.org/2011/05/04-webperf-irc Meeting Minutes: http://www.w3.org/2011/05/04-webperf-minutes.html Attendees Present Cameron McCormack, Jatinder Mann, James Robinson, Zhiheng Wang, Arvind Jain, Tony Gentilcore, James Simonsen, Christian Biesinger, Nic Jansma, Jason Weber Meeting Chair Jatinder Mann Regrets Karen Anderson Scribe Jatinder Mann Agenda 1. Feedback and discussion on proposed updates to Resource and User Timing. 2. Feedback and discussion on Resource Timing Processing Model. 3. Any other business. 4. Feedback and discussion on updates to Page Visibility spec. 5. Feedback and discussion on updates to AnimationRequestFrame spec. 6. Any other business. Topics Feedback and discussion on Resource Timing Processing Model. Feedback and discussion on updates to Page Visibility spec. Feedback and discussion on updates to AnimationRequestFrame spec. Summary of Action Items Created ACTION-25 - Analyse data to see what the recommended buffer size should be. [on Jatinder Mann - due 2011-05-11]. ACTION-26 - Check whether to name the API window.visible, document.visible, window.pageVisible and document.pagVisible. [on Jatinder Mann - due 2011-05-11] -------------------------------------------------------------------------------- <scribe> scribe: Jatinder Mann move to agenda 1 - http://lists.w3.org/Archives/Public/public-web-perf/2011May/0046.html - Zhiheng: Want to keep measures, just want it to be more coherent with mark and measures. Measures is important because it gives a standard interface. Zhiheng: Follow up with Tony and James to see if they can propose a way to make measure and marks work better together. Jatinder: The "type" attribute and getResourceTimingsByType method provide users with a simple way to roughly sort their resource timing data by the initiator types. As some initiators, like XHR and Script, can load additional resources, it is useful and practical for web developers to sort their resources by the type of initiator. The initiator type will not change over time. The "type" attribute doesn't suffer from the problems of the "id" attribute a Christian: Agree. Tony: What type in particular would you want to look at? Jatinder: An example would be if you are pulling video and images resources from a news site, the URLs would typically look the same. Here pulling by Type is useful. We have agreed to keep the type data in the array, but remove the getResourceTimingsByType accessor. Jatinder: Do not want to require Resource Timing to be explicitly enabled by web developers. ... Our joint analysis, http://lists.w3.org/Archives/Public/public-web-perf/2010Dec/0024.html, had shown that the impact of keeping Resource Timing enabled is negligible. The average number of resources per page is 42 and the 90th percentile is 145. The benefit of having Resource Timing enabled by default will mean that web pages using analytics libraries will have to make no explicit change to use Resource Timing. Otherwise, all analytic library users w ... Resource timing. ... We agree that the Resource Timing should be on by default, however, the maximum number of resources captured by default should be reduced from 1000 to a smaller number. Action Jatinder to analyse data to see what the recommended buffer size should be. <trackbot> Created ACTION-25 - Analyse data to see what the recommended buffer size should be. [on Jatinder Mann - due 2011-05-11]. move to next agenda Feedback and discussion on Resource Timing Processing Model. http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html#processing-model Jatinder: Let's review the Processing Model. James: Let's remove fetchEnd or responseEnd from the timing, as they are redundant. Jatinder: Let's be consistent with Navigation Timing and cut fetchEnd. Tony: The processing model doesn't seem to have the cross-origin details that navigation timing has. James: I prefer resourceStart rather than resourceFetchStart. Jatinder: Agreed. Chrisitian: The processing model should be clear that secureConnectionStart is optional. move to next agenda Feedback and discussion on updates to Page Visibility spec. <jamesr> hmm <jamesr> i think zakim thinks i am TabAtkins <jamesr> yeah he must use the same phone <jamesr> that'll mess him up on the next CSS call :) http://lists.w3.org/Archives/Public/public-web-perf/2011May/0045.html Action Jatinder to check whether to name the API window.visible, document.visible, window.pageVisible and document.pagVisible. <trackbot> Created ACTION-26 - Check whether to name the API window.visible, document.visible, window.pageVisible and document.pagVisible. [on Jatinder Mann - due 2011-05-11]. Jatinder: Changes I made: Window rather than Navigator implements WindowVisibility interface. ... updated the event name to visibilitychange.I have also specified that this event can only be registered using addEventListener on window; this implies that this event can't be exposed using onvisibilitychange. Cameron: Let's see if we can follow up and see what the value is for keeping onvisibilitychange. Jatinder: I have generalized the definitions of visibility from my previous very specific cases. I have defined page visibility as the visibility state of the Document contained by the top level browsing context. ... I have combined the two preview states to a single PAGE_PREVIEW state. Per Alex's initial email on page visibility, he had shown interest in a page preview state: http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0175.html. JamesR: What's the value of having PAGE_OTHER? Jatinder: Will follow up and see if there was a historical reason for having a reserved constant. ... I have updated the example section with more description and an updated example. The updated example is a skeleton case of throttling checking for email when not visible. Let me know if you have any better examples in mind. move to next agenda Feedback and discussion on updates to AnimationRequestFrame spec. Jatinder: I understand that a browser may not be able to guarantee that a callback will occur. We should attempt to specify match the number of callbacks with the refresh rate of the display. JamesR: Will update the spec to cover the callback rate.
Received on Thursday, 5 May 2011 01:00:28 UTC