Re: WebPerfWG call - May 7th @ 8am PT / 11am ET

and recording <> from last week's call are now

Copy of minutes:

Gilles Dubuc, Yoav Weiss, Nic Jansma, Michal Mocny, Benjamin De Kosnik,
Nicolas Pena, Marcus Armstrong, Annie Sullivan, Philippe Le Hegaret, Philip

Next Call

   - Tues May 19th @ 10am PST / 1pm EST

DiscussionsEventTiming Updates

   - Nicolas: Added a method that looks at the dictionary of the .observe()
   call and if there’s a duration threshold, and smaller delays than the
   threshold aren’t sent to the observer.
   - … Also, there’s no way to determine which entries to add to the buffer
   in PerformanceTimeline.
   - … On the last call we talked about adding only entries with a duration
   over a hundred, even though we support observing entries of 16ms or more.
   - … Maybe we can hack “should add entry” and make it also about the
   performance timeline only.
   - Nic: So the buffer would have a different threshold?
   - Nicolas: We can do that or accumulate everything.
   - Yoav: Buffering “everything” runs a risk accumulating entries for
   every single input event, of bloating memory.  Where if it’s just for
   “slow” events, it’s not as big of a deal.
   - Nicolas: True, but there is also a buffer limit.
   - Nic: I would want to make sure it’s called out in the spec that the
   .observe() and PerformanceTimeline have different thresholds for what shows
   - Nicolas: Worried it would be confusing with the buffered entries
   having a different threshold.
   - … The default for duration would be the slow entries, and duration
   threshold enables you to get more than that.
   - Nic: Just to restate what you said: So only buffer events at 100ms and
   that would be the default, but the observer can go below that using the
   duration threshold?
   - Nicolas: Yeah. Interested in feedback about this threshold, and
   general feedback about EventTiming would be good, because Chrome is
   interested in shipping it.
   - Nic: From Akamai’s perspective, hoping to collect data to supplement
   existing polyfill.
   - Nicolas: Would be great to compare polyfill to native implementation.
   - Nic: We should have that data, so can verify that at some point.
   - Nicolas: How do you verify that there’s a handler at the beginning of
   the page load?
   - Nic: That’s one of the downsides with our polyfill right now, is we
   - Nicolas: I’d expect native times (especially for event processing
   time) to be larger.
   - Nic: We’re telling customers we’re expecting differences.
   - Yoav: Any other API feedback?
   - Steven: Looks good, we’ll use it.
   - Nicolas: User input in general doesn’t occur early on, so most entries
   won’t be buffered, so buffering only the slow ones shouldn’t have a huge

Resource Timing


   - Transition Level 2 to CR
   - Nic: Tracking to get to CR
   - … List of issues needed for Level 2
   - … List of open test bugs
   - AI: Yoav to update


   - Register TAO as Permanent Message Header Field Name
   - Nic: Register TAO headers once we hit PR
   - … Can’t make progress yet, so skipping


   - Be a bit more explicit about which subresources are to be ignored from
   - Nic: What do we do about grandchildren resources.
   - Yoav: How to describe everything in that dependency tree should be
   invisible?  Without having to describe a dependency tree
   - … I need to figure out language, it might be hand-wavy, but we can
   then wait for when CSS integrates with fetch to be able to better describe
   it (i.e. the ancestry relationship in fetch).
   - … As long as CSS is not integrated into fetch, no point in even going
   that route because it won’t help us here
   - Nic: So hand-wavey text for now?
   - Yoav: I think that’s the best we can do
   - ... We’ll also need tests, I don’t think any implementation follows

   - Nic: Besides those L2 issues, we have some tests
   need to be addressed
   - Yoav: I’ll take an action item to re-look at where tests are
   - Nic: Next are untriaged issues, let’s find a milestone for them

   - Pass realm when creating PerformanceResourceTiming
   - Nicolas: Unclear what’s the right answer, can wait for Fetch
   integration. Not high priority
   - .... Fetch integration would be Level 3
   - Yoav: I don’t think a change here is highly observable or likely to
   affect the API shape, we just need to properly define it and it would be
   hard to do that before Fetch integration.
   - … So it can wait


   - Provide a TAO-bypass for Navigation timing
   - Nic: NavTiming entries are not gated by TAO while RT is. Mostly an
   editorial change
   - Yoav: Some timestamps are related to current document (e.g. current
   pages’ DNS / TCP).
   - … Things that concern the document being fetched, so are always
   same-origin (to itself)
   - … But there are other timestamps related to the unload of the previous
   page (e.g. unloadEventStart) that shouldn’t be TAO bound but just
   same-origin bound
   - … We had discussed all of these at the latest Face-to-Face and so
   don’t need to be clarified but just editorial changes
   - ... Make sure these changes are tested

   - Nic: 3x issues from PING
   - Yoav: Let’s dive into each individually

   - Yoav: nextHopProtocol is exposing unique information that the visitor
   is behind
   - ... Could expose if user is behind a proxy, or VPN or has Anti-Virus
   - … Many things that can change that first hop
   - ... nextHopProtocol is not TAO bound, and maybe it should be? But that
   could be tangential to this question
   - Nicolas: Are we OK with exposing VPN/Proxy usage or do we need to
   re-evaluate the attribute
   - Yoav: My thinking is that it doesn’t expose anything specific -- it
   says “supports H2” or “not H2” etc, and these are all things that are
   already somewhat observable, e.g. very clear request patterns (from
   ResourceTiming) where you can tell the difference between H1 and H2
   - ... My claim is this information is already exposed
   - ... Proxies that are privacy-aware could support H2/H3, and try to
   mirror the origin
   - Nic: Proxy would have a hard time knowing origin protocol until client
   already connected with their preferred protocol
   - Yoav: Good point.  Generally, we think this is a consideration we took
   into account when we shipped nextHopProtocol.
   - Benjamin: We’re concerned about this, PING pointed out a valid issue
   - Nicolas: Could you clarify how this information is already exposed
   - Yoav: If you look at multiple connections to the same host, and you
   have connect time for only the first one, and the rest seemingly use the
   connection.  For H1 you’d expect up to 6 total connections with distinct
   timings.  Where H2 is not.
   - … For H2 vs H3 the differences are more subtle and it could be a bit
   harder.  For H1 vs H2 it’s easy to write a script that finds that
   - ... Not sure what the real privacy benefits would be
   - ... Will run it by Chrome and Google privacy folks to get their take
   - Benjamin: What are the risks to doing what they ask, i.e. what is the
   harm in conceding to their request
   - Yoav: Harm of removing nextHopProtocol: Won’t be able to easily
   segment the impact of underlying protocol rollouts on traffic.  H1 to H2
   rollout is not done.  Properties are making that transition and they want
   to prove to themselves that it’s a worthy one and this allows them to
   measure that. H2 to H3 allows them to switch some percent of their
   protocol, and measure the differences.
   - … When we shipped nextHopProtocol, we didn’t have ServerTiming.  Can
   this be exposed via that?
   - Nic: From Akamai’s perspective and its customers, it has been
   invaluable. For rollouts, our customers can segment and measure their
   - … As well as internally, when we’re deploying new protocols at Akamai,
   we can measure the impact.
   - .... If it can be done with server timing? ST can come from multiple
   hops, where we’re mostly interested in last hop.
   - Yoav: One problem is that Server-Timing is set at the application
   layer, done independently to the layer making the decision on the
   protocol.  It would require the network layer mark the protocol to the
   application layer who would mark it via Server-Timing headers going down
   - AI: Yoav to talk to privacy folks to see if the user impact is
   meaningful and Nic/Yoav to talk to ops folks to see if ST can be a

   - There are two other related one around TAO, but we’ll talk about these
   at a later date


Page Visibility / Paint Timing issues


   - Log if a page was ever visible
   - Nicolas: Two options for determining if a page was visible before
   - … You can listen to event handler to get state changes but that
   doesn’t work for later-loading scripts
   - … First option is to have a flag on events that notes if the page was
   hidden previously
   - … Second option is to have an observer so you can see the entire state
   of page visibility changes
   - … Developers on public-webperf mailing list generally preferred the
   second option, Page Vis Observer (PVO), but there is some feedback in
   Github issue around discoverability that this could be important
   - Philip: Issue is more about discoverability that would have to know
   that Page Visibility affects Paint Timing.  Could be easier for developers
   to discover this if it was on the entry
   - ... We see many cases on the internet where people are not checking
   this case (that visibility affected the paint timing entry)
   - … Having something as simple as possible would be ideal.
   - ... The other concern I have is if the PVO is async and the Paint
   Timing Observer (PTO) is async you need to wait a bit to check both of
   them. So it’s a little bit awkward.
   - ... My thought is that we should do both -- PVO is useful, but a flag
   is also useful.  “The user thinks maybe you shouldn’t trust this entry
   because X,Y,Z”.  There are many possible reasons in the future why having
   it on the entry may be useful
   - Yoav: PVO will give us a full picture of how impacted the resource is,
   and give developers the option to still count the experience, or segment
   it.  Visibility is possibly not the only thing that would cause tainting.
   Having both is a matter of resources and but both seems valuable
   - Nicolas: Right now we would only have one tainted reason (background)
   -- we’re not ready to have other interoperable reasons for tainted
   - Philip: Do we need a reason, versus just a boolean?
   - Nicolas: Github issue requests there’s a string reason instead of just
   a boolean
   - Yoav: In the future we may have other reasons that affect events.
   E.g. during a Long Task.  Right now it’s mostly related to visibility, but
   in the future may find additional events that impact entry types.
   - Philip: Layout Shifts has a flag that mentions input happened recently
   - Nic: We may then want to have an array of tainted reasons.  Starts
   going down a rabbit hole a little bit.
   - Nicolas: Initially it could be an array as empty [] or single string
   - Yoav: For example, segmenting between visibility-related or if Dev
   Tools was open
   - Nic: If we do say just “tained” boolean, users will always immediately
   want to know “why”.  Maybe they do want it, maybe not, but without more
   details they might not know.
   - Yoav: ResourceTiming: Dev Tools was open and Network Throttling was
   - … Maybe we don’t want to enumerate all the tainting reasons right now
   - Nic: Next steps?
   - … Broad support for PageVisibility Observer. Go forward with that.
   - … Maybe we continue the discussion for the tainted attribute on the
   - Nicolas: See the value but can add complexity

On Tue, May 5, 2020 at 1:57 PM Nic Jansma <> wrote:

> Hi everyone!
> Join us <> this week to talk about
> Event Timing, Page Visibility and Resource Timing.
> *NOTE*: this week's time has moved 2 hours earlier than normal: May 7th @
> 8am PT / 11am ET
> On the agenda
> <>,
> we have:
> * - Event Timing updates *
> * - Page Visibility -
> <> *
> * - Resource Timing -
> <> -
> <> -
> <> -
> <> -
> <> -
> <> -
> <> -
> <> *
> If you have any additional items you'd like to discuss, please add to the
> agenda
> <>
> .
> The meeting will be recorded and published online afterwards.
> See you soon!
> - Nic Jansma
> @nicj

Received on Wednesday, 13 May 2020 18:19:02 UTC