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

Re: [minutes] 20110302 Web Performance WG

From: Zhiheng Wang <zhihengw@google.com>
Date: Tue, 8 Mar 2011 17:07:21 -0800
Message-ID: <AANLkTikVRAHb6EeYeKRaohvuhwJKZT+vC9psCNCfd-om@mail.gmail.com>
To: Anderson Quach <aquach@microsoft.com>
Cc: public-web-perf <public-web-perf@w3.org>
On Wed, Mar 2, 2011 at 12:16 PM, Anderson Quach <aquach@microsoft.com>wrote:

>  Web Performance Working Group 02 Mar 2011
>
> See also: IRC log <http://www.w3.org/2011/03/02-webperf-irc>
> Minutes
>
> http://www.w3.org/2011/03/02-webperf-minutes.html
> Attendees
>
> *Present *
>
> *[Microsoft], +1.650.253.aaaa, +1.650.450.aabb, +1.650.214.aacc,
> +1.650.214.aadd, +1.650.704.aaee, AndersonQuach, ArvindJain, Zhiheng,
> KarenAnderson, JasonWeber, TonyG, JamesSimonsen, JatinderMann *
>
> *Regrets *
>
> *Chair *
>
> *ArvindJain, JasonWeber *
>
> *Scribe *
>
> *AndersonQuach *
> Contents
>
>    - Topics <http://www.w3.org/2011/03/02-webperf-minutes.html#agenda>
>       1. Review the proposed changes to the charter<http://www.w3.org/2011/03/02-webperf-minutes.html#item01>
>       2. Navigation timing<http://www.w3.org/2011/03/02-webperf-minutes.html#item02>
>       3. User Timing<http://www.w3.org/2011/03/02-webperf-minutes.html#item03>
>       4. Resource Timing<http://www.w3.org/2011/03/02-webperf-minutes.html#item04>
>       5. Summary<http://www.w3.org/2011/03/02-webperf-minutes.html#item05>
>
>                   i.            Anderson will update the
> test_navigation_timing_order tests according to the feedback.
>
>                ii.            Anderson will update the User Timing spec to
> include the updated measures and marks as discussed: above the fold, fully
> visible and time to user action.
>
>               iii.            Zhiheng will update the resource timing to
> reflect the latest discussions on the Event Log.
>
     I've updated the working draft of
ResourceTiming<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html>to
reflect some of our discussions in this conf call
   * removing the collector interface in favor of the event logs style
storage,
   * consolidate the resource types in both versions and move the stuff
around.

     There are still some obvious loose end I can see right now and I will
give it another run tonight.

>               iv.            All, to think about how to bring cohesion to
> the Navigation, Resource and User timing interfaces.
>
>                v.            All, to think about how to enable ‘session’
> timings, that is a collection of individual navigation timings, whether it
> is with the use of existing platform functionality like DOM Storage or
> indexed db.
>
>
>  ------------------------------
>
> *Review the proposed changes to the charter*
>
> http://www.w3.org/2011/02/webperf.html
>
> *AndersonQuach:* Are there additional deliverables?
>
> *ArvindJain:* No, this has been set to review. I will send an email to
> request for additional items. I don't have any additional things myself.
>
> *AndersonQuach:* Do we have editors?
>
> *JasonWeber:* I know that Microsoft is willing to help be co-editor with
> each of the specs.
>
> *Navigation timing*
>
> *AndersonQuach:* No additional tests for this week, Microsoft is in the
> process of being updated.
> ... If there is no work around are we okay with a manual back_forward?
>
> *TonyG:* If there is no workaround I'm okay with a manual test.
>
> *User Timing*
>
> move to agenda 2
>
> rrsagenda move to agenda 2
>
> rrsagent move to agenda 2
>
> http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/UserTiming/Overview.html
>
> *AndersonQuach:* to be added, an updated return type to getMarks and the
> addition of the measures interface
> ... What's the guidance for Fully Visible and Fully Interactive?
>
> *TonyG:* One pattern I see is that UI is visible but handlers are not
> hooked up.
> ... For example, Google calendar and Google search they stub out that
> behavior.
>
> *Zhiheng:* We have a couple of things like above the fold and fully
> loaded. Those are the potential marks we can add. What kind of best practice
> can we follow-up with this draft.
>
> *TonyG:* The way i'm looking at these, is an analytic script would be to
> look at what's in marks and measures to look specifically for items to
> report back. Any other mark or measure people will have to treat as a black
> box.
>
> *KarenAnderson:* Is there value in having measures to be DOM specific?
>
> *Zhiheng:* I propose two additional standard marks, Above the fold time
> Google services attempt to measure this. Time to User action, how long after
> a page load that a user will interact with the page.
>
> *AndersonQuach:* Zhiheng can you provide a brief 1-2 sentence on these two
> standard marks, Above the fold and Time to User action.
>
    The updated version seems to have the following added. Thanks, Anderson.

     const string MARK_ABOVE_THE_FOLD = "aboveTheFold";
     const string MARK_TIME_TO_USER_ACTION = "timeToUserAction";

    MARK_ABOVE_THE_FOLD: this is the time to show all the contents within
the viewing window. This is a POI because users would generally consider the
page
is done loading given no visible change after this time. Most of the
existing implementations of this measurement are approximation though.

    MARK_TIME_TO_USER_ACTION: this is the time of the first user action upon
the page during a navigation, such as scroll or click. This could be used as
another
indication that the user considers the page ready to operate.


cheers,
Zhiheng


> *TonyG:* Should user action be in navigation timing?
>
> *JasonWeber:* There are two intepretations, first when the page can be
> interacted with and second when the user actually interacted with the page.
>
> *TonyG:* What if I want to do a measure, and navigationStart and
> navigationStart is zeroed out?
>
> *AndersonQuach:* I'm okay with zero or an exception thrown.
>
> *JasonWeber:* For common practice, zero may be better as exceptions may
> lead to more complicated code.
>
> *TonyG:* I'm okay with zeros.
>
> *JasonWeber:* Perhaps we can return undefined.
>
> *Zhiheng:* I agree, zero might be some valid value in some cases.
>
> *TonyG:* When you call measure, it will create a mark and measure. Mark
> there is no problem.
>
> *AndersonQuach:* I will capture all these caveats into the spec.
>
> *Resource Timing*
>
> move to agenda 3
>
> *AndersonQuach:* Tony and James have you gotten feedback with Resource
> Timing?
>
> *JamesSimonsen:* No.
>
> *TonyG:* We're amicable about the event log. However we should consider
> off by default.
>
> *JasonWeber:* I think that's a valid concern. Do you have a projection of
> what those resource costs would be in Chrome.
>
> *TonyG:* In terms of raw data, it's the same in IE. It depends on the
> estimates, on the resources on a page.
>
> *JasonWeber:* There's the working set resources which we estimated that
> impact. There's the alloc patterns we don't believe have an impact to
> performance. There's the CPU and contention, we already have the data it's
> easy for us to store that data. We don't expect contention and low CPU
> usage.
> ... If this is an arch concern for Webkit and Firefox and influence the off
> by default and on by default conversation. We look at it today and don't see
> the resource concern. If you have projections about slowing down Webkit and
> Chrome that can help us steer this discussion.
>
> *JamesSimonsen:* Arch from the Chrome side, I don't see an issue. On a
> mobile browser, these become a concern.
>
> *JasonWeber:* IE is in the same position. IE on mobile is excited to get
> access to this data.
>
> *TonyG:* One thought, agree on the event log approach, can be enabled or
> disabled by default. It's recommended enabled by default. We have methods in
> the interface start-stop tracking of resources. Implement the interface so
> it's there. Experiment with enable by default.
>
> *JasonWeber:* Ya.
> ... That sounds like the right approach.
>
> *Zhiheng:* That makes sense too.
> ... How can we enable / disable, the web-site opt-in.
>
> *TonyG:* Ya, the website opts in, but does not allow for retro-active
> analysis. JavaScript method, http header or meta tag.
>
> *KarenAnderson:* Is there concern of disclosure?
>
> *TonyG:* For sure there are privacy concerns. We can't expose timings for
> resources on other domains. We have to work through.
>
> *AndersonQuach:* Jason Sobel has been requesting for a blessed way of
> access cross-domain timings.
>
> *TonyG:* Do we want to have Resource Timing and User Timing in the same
> structure?
>
> *AndersonQuach:* Can you clarify?
>
> *TonyG:* Was wondering if we can tie all the logs together.
> ... Is there a way to efficiently bring back all the data when a
> web-developer wants navigation, resource and user timing altogether.
>
> *AndersonQuach:* Two thoughts, Resources timing can be filtered by type
> and User Timing may be larger than navigation timing to separate the data
> serializing.
>
> *JamesSimonsen:* Can user timing and resource timing be different types?
>
> *AndersonQuach:* We could have getTimings versus getMarks
>
> *Zhiheng:* User Timing, would love to have a way to pass user timing
> across navigations.
> ... It's a minor value add, especially being able to time across
> navigations.
>
> *AndersonQuach:* Are the scenarios like log-on or cross page scenarios.
>
> *Zhiheng:* That's already achievable by using storage solutions.
> ... Bring this up to get some feedback.
>
> *AndersonQuach:* This is something we're actively mitigating with
> cross-domain accesses.
>
> *Summary*
>
> i. Anderson will update the test_navigation_timing_order tests according to
> the feedback.
>
> ii. Anderson will update the User Timing spec to include the updated
> measures and marks as discussed: above the fold, fully visible and time to
> user action.
>
> iii. Zhiheng will update the resource timing to reflect the latest
> discussions on the Event Log.
>
> iv. All, to think about how to bring cohesion to the Navigation, Resource
> and User timing interfaces.
>
> v. All, to think about how to enable ‘session’ timings, that is a
> collection of individual navigation timings, whether it is with the use of
> existing platform functionality like DOM Storage or indexed db.
>
>
>
Received on Wednesday, 9 March 2011 01:07:52 UTC

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