W3C home > Mailing lists > Public > public-web-perf@w3.org > September 2017

Minutes (was: Re: [9/25/17] webperf group call @ 10AM PST)

From: Xiaoqian Wu <xiaoqian@w3.org>
Date: Tue, 26 Sep 2017 13:38:20 +0800
To: public-web-perf <public-web-perf@w3.org>
Message-ID: <cac59c3eb7e77ab4e501ba6c0a6fa684@webmail.w3.org>
Hi,

The minutes of the 25 Sep 2017 WebPerf Group Call are available at:
https://www.w3.org/2017/09/25-webperf-minutes.html

Next meeting will be on 09 Oct 2017.

See also:

Web Perf WG Call

25 Sep 2017

Agenda

See also: IRC log

Attendees

Present
igrigorik, yoav, nolanlawson, NicJ, plh, xiaoqian, cvazac, philip, dale, 
Josh, todd
Regrets
Chair
igrigorik
Scribe
yoav
Contents

Topics
Server Timing feedback from TAG
User Timing L2 issues
PerfObserver
Triage Dale’s feedback on time origin + unload
Administrative / check-in
Summary of Action Items
Summary of Resolutions
Server Timing feedback from TAG

igrigorik: let's start with Server Timing

cvazac: We attempted to ship, then TAG review happened
... they brought up concerns about future extensibility, units and other 
use cases to enable full fledged server side tracing framework
... so made a proposal to make all parameters other than "name" named, 
so we can add more parameters in the future

<igrigorik> proposal: Server-Timing: name=foo; start=100; duration=0
<igrigorik> doh, sorry.. Server-Timing: foo; start=100; duration=0
cvazac: we want to use existing art to parse these headers. This looks 
very much like the Link header parsing, so we can reuse most of that 
code

igrigorik: so we agreed on not naming the "name", right?

cvazac: all for skipping "name="

igrigorik: it gives us an option to extend the format in the future, 
which is a good thing. How would it impact consumers, e.g. Chrome dev 
tools?

cvazac: we can change that. They are not very worried.

yoav: We previously talked to the devtools and talked about supporting 
both syntaxes for a while

igrigorik: then let's do the spec and impl changes and get Paul Irish to 
review

User Timing L2 issues

igrigorik: so, user timing
... we added a capability to reference named marks, never updated to 
cover NT2, and we throw exceptions in various non-consistent cases
... maybe we can just drop this whole thing?
... a bunch of shipping implementations, not necessarily consistent. Can 
we drop it? If we do, what are we missing?

todd: are we sure that we don't need that?
... we need telemetry on usage before discussing dropping it

igrigorik: what are the alternatives? It only works with NT1?

todd: The implementations work with part of NT2, we need to fix the spec

igrigorik: for NT3 when we'd support redirects, it'll get very messy

todd: We really need real usage metrics before discussing dropping it

igrigorik: if it's used in 0.1% what would that give us?

philip: Can we freeze the future to what's currently supported?
... If a used is using a marked name, it limits the strings we can use 
in the future

yoav: maybe a namespace for future entries?

igrigorik: We have a proposed model for referencing entries directly

nolanlawson: We can pass in the entry directly instead of strings that 
proxy them

igrigorik: are there 2 components? one is "mark" and the other is NT? 
How would you pass in NT entries?

todd: strings model is a key-value pair

igrigorik: we should support passing NT entries, not sure how to support 
that use case

nolanlawson: so we need to support passing in arbitrary timestamps

todd: the name you're passing in is just a pointer.
... so we can pass in timestamp and name as a replacement to the string 
model if we can get everyone to convert

philip: discussion from TTI definition where you don't know how TTI 
happened until it's passed
... so there's a use case for creating a user timing entry in the past

igrigorik: a few updates a) current exception behavior - we need to 
gather metrics and try to kill it

if there's usage - lock in the current strings and freeze it

in L3 we can try to return an entry object from mark and measure, 
supporting timestamps and events

todd: makes sense and probably a simple addition

igrigorik: nolan, would you guys be interested in driving that work?

nolanlawson: sure

igrigorik: custom perf entries kinda plays in the same space

maybe we need to merge concepts

philip: worthwhile to think about both at the same time

igrigorik: maybe implement user timing using custom entries

nolanlawson: is chrome already exposing custom metrics in dev tools?

philip: experimental implementation in the UI but not in JS

PerfObserver

igrigorik: PerfObserver
... interesting incidents a few weeks ago, large sites shipped PO code 
and hit problems with the exception behavior

longtasks PO was raising exceptions and it wasn't guarded for

joepack suggested to drop exceptions entirely

todd: example with the problems in being a late implementor

yoav: what's the feature detection story other than exceptions?

igrigorik: maybe calling observe can return the list of things that are 
observed?

todd: that may add a cost for feature detection

cvazac: There should be a single way to feature detect

igrigorik: so rough consensus to drop the exceptions. Maybe we can add 
console warnings
... how do we feature detect? Joe did not want an "isSupported" type of 
API

todd: specific interfaces checked exist on window, but not in PO

igrigorik: we previously talked about `supports` for both PO and TL. 
Does it make sense to expose several things?

todd: Firefox are rolling back PO because of PO feature detection

igrigorik: so remove exceptions, and create a direct array of supported 
types that PO supports

plh: should I make a PR to remove the exceptions and the test?

igrigorik: yes, plz!

cvazac: what about the console warning?

igrigorik: maybe add a note saying UA can do that
... is Dale around for time origin discussion?

Triage Dale’s feedback on time origin + unload

<igrigorik> 
https://github.com/w3c/web-platform-tests/pull/6241#issuecomment-331347123
Dale: this comes down to the wording that defines the time origin

diagram shows 2 potential points for time origin

the 1 implemented is not great

if you measure from an onunload event, implementations use the origin of 
the previous document

todd: in unload we have 2 time origins
... so the spec is ambiguous regarding what time origin should unload 
use

Dale: easier to test the implemented behavior than the spec behavior

if the spec is corrected to match current behavior, it's testable

cannot test the negative case, so can't measure you're not measuring 
using the wrong time origin

todd: so Dale will get in a more complex test and PR to update the spec

Administrative / check-in

igrigorik: Any updates on beacon tests?

todd: no

igrigorik: RequestIdleCallback - any updates?

plh: got it dropped off my list. Will take care of it

igrigorik: preload CR and discussion of a TAG review

xiaoqian: we should send a review request today and wait 2 weeks

yoav: let's coordinate reviews over email

igrigorik: October 9th for next meeting due to Akamai Edge

[End of minutes]

On 2017-09-23 04:19, Ilya Grigorik wrote:
> Hangout:
> https://hangouts.google.com/hangouts/_/chromium.org/webperf-wg [1]
> 
> Tentative
> agenda:https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit#heading=h.kplnsudwiv74
> [2]
> 
> If you have other topics you'd like to discuss, please feel free to
> add to the doc above.
> 
> Links:
> ------
> [1] https://hangouts.google.com/hangouts/_/chromium.org/webperf-wg
> [2]
> https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit#heading=h.kplnsudwiv74
Received on Tuesday, 26 September 2017 05:38:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 26 September 2017 05:38:19 UTC