Re: WebPerfWG call - Thursday March 12th 10am PST

Hey folks! :)

Minutes
<https://docs.google.com/document/d/e/2PACX-1vQ6a9X-_Ps-JSshPNyr2lP5BQaSEsQH-nZv_V4JreTOjFacHEo-8dtcZ6uxnKuR4sFPdGMGj4Ltk3nu/pub>
and recording <https://www.youtube.com/watch?v=p5LYCZDIUt0> from last
week's call are now available. Copying them here for safe keeping.

WebPerfWG call - March 12th 2020
Participants:

Dave Pifke, Michal Mocny, Steven Bougon, Nic Jansma, Gilles Dubuc, Yoav
Weiss, Nicolas Pena, Philippe Le Hegaret, Annie Sullivan
Next Meeting

   - March 26 at 10am PST


   - Yoav to fix calendar appointment which currently has it listed at 11am
   PST due to the difference between DST in Americas and Europe (Mar 8 vs. Mar
   29)

Event Timing Updates from Nicolas Pena

Presentation
<https://www.google.com/url?q=https://docs.google.com/presentation/d/1VFYkDaC59dn7cI-BHoCEYv6ZkSEmA33riZRee93KV8Y/edit%23slide%3Did.p&sa=D&ust=1584635372844000>

Nicolas: 2 API objectives:

   - Want to gather data on input delays (time to start processing)
   - Gathering data on sync input processing latency (how long it takes
   until next paint after event handlers have run)

… Non-objectives include:

   - measuring async work coming from event handler as that’s better done
   in User Timing
   - measuring 'continuous' events - hardware dependencies and browser
   differences on when they are dispatched, so don’t want to expose them
   - scroll performance - scrolls can be caused by a scrollbar so may be
   unrelated to input events. Scrolls are hard so should be decoupled.

Yoav: With regard to async performance, we discussed measuring how long the
paint took afterwards, right?

Nicolas: Guidance is to use UserTiming for measuring your async work, since
your JS will already be running in the event handler. That was the
conclusion in previous discussions. Also, it’s hard for the UA to keep
track of causality of async work.

… *continues presenting*

… First Input - always exposed: From key down, mouse down, pointer down +
pointer up, click

… Also expose "general input delay" from a list of non-continuous events
whose duration is > 100ms (104ms rounded)

Steven: If one of those events takes less than 104ms, we won't be notified?

Nicolas: Correct

Steven: For the gaming industry, would they want to have a lower threshold?

Nicolas: It's feasible we could let the threshold be variable pending
security + privacy review.  Only challenge is we support the buffered:
flag, which means we'd have to store the lowest possible threshold. Also
don’t want to make the threshold too low as that would be spammy

Steven: Makes sense as a default, but might be good to have an option

Yoav: For the buffered case where you care about faster clicks, you've
probably already setup the app and have registered your observers, so the
buffered could just deliver the default threshold, and we’d deliver values
with lower thresholds only when explicitly required

Nicolas: Possible, but might be confusing to developers.

Dave: For those that want to only track a higher threshold, it would be
easier since the buffer could just deliver those under the threshold

Nicolas: Yeah, we can add a parameter

… *continues presenting*

… What's exposed

   - First Input (always)
   - 'Slow' inputs when the rounded duration exceeds 104ms threshold
   - Should we add an eventTypes option? Probably yes, so developers can
   observe a subset of events they care about

Yoav: Is there an easy way to detect which types are supported for
observation?

Nicolas: Will make sure we have something available

   - For supported event types want to expose: total count, to help
   calculate overall percentage of slow inputs, etc.

… Chromium shipping First Input Timing

… Chrome intends to ship Event Counts as well as full Event Timing in near
future

… [goes over PerformanceEventTiming interface in slide deck]

Yoav: `name` is the event type rather than URL like other performance
entries, right?

Nicolas: Yeah.

Yoav: `cancelable` is a way to track passive events vs not, right? That
enables distinguishing events that have to run sync vs. not. Seems like
something we want to make people aware of. Mostly relevant for scroll
events, so maybe not so relevant. Worthwhile to think about developer
advice here.

Nicolas: Makes sense

... EventCounts interface will give you the number of events that have been
dispatched, per type

... For events that are not supported by the UA, they could be optional.
That would enable feature detection

Philippe: Why not a map object?

Nicolas: Not sure why. I’ll look into it

Steven: Other groups looking into user behaviors may be interested in a
number of clicks. Wondering if we can expose that?

Nicolas: Event counts would give you the total number of events

Nic: Event Counts mentioned that the counts would be updated
asynchronously, I would just want to make sure the counts are relatively
in-sync with when the PerformanceObserver is dispatched, so the EventTiming
entry is reflected in the EventCounts by then

Nicolas: Some UAs may filter unhandled events outside of the renderer
process, so the count would have to be asynchronous. But there should be
some guidance that if the performance entry is dispatched, the count also
includes it. Makes sense and sounds feasible.

Issue Triage - NavigationTimingBetter integration with ResourceTiming
<https://www.google.com/url?q=https://github.com/w3c/navigation-timing/issues/117&sa=D&ust=1584635372855000>

Nicolas: Spec language is confusing, as the NT spec (which uses same-origin for
exposing some times like DNS) links to the RT spec (which uses TAO for the
same times), plus additional spec confusion

Yoav: Mark as blocking for L2. Will go away in L3

Nicolas: Need to make sure that the checks make sense

Nic: In navigation timing, those entries are always exposed right?

Nicolas: Can have cross origin redirects for the navigation

Nic: Yeah, but it’s always exposing the last entry

Yoav: So for NavTiming, TAO on its own origin always passes.

… But seems reasonable to make sure someone goes over that and verifies
that the behavior is what we want it to be
Can hitting enter on address bar to same URL be considered a navigation of
type 'reload'?
<https://www.google.com/url?q=https://github.com/w3c/navigation-timing/issues/116&sa=D&ust=1584635372858000>

Yoav: WebKit folks had a few examples where it’s not a reload, e.g. when
navigation was made with a POST

Nicolas: Need to define reloads in terms of what the UA is doing, not user
actions. So this is blocked on HTML

Yoav: Agree. We can mark spec as blocking, pointing to "reload triggered
navigation", and open a HTML issue on better defining what that means.
Surface chunk network timing details
<https://www.google.com/url?q=https://github.com/w3c/navigation-timing/issues/123&sa=D&ust=1584635372859000>

Yoav: Useful addition, but seems like a feature request for Level 3

Nic: RUM customers haven't requested this yet, but could be useful

Yoav: This type of data is now being surfaced in WPT and used to expose bad
server behavior

Nic: More visibility would be useful.
What should transferSize, encodedBodySize and decodedBodySize in Navigation
+ Resource Timing represent for responses where a Service Worker is
involved?
<https://www.google.com/url?q=https://github.com/w3c/navigation-timing/issues/124&sa=D&ust=1584635372860000>

Current implementation on latest builds of a number of popular browsers
(Chrome, Chromium, Firefox, Edge, Samsung Internet) seem to allude to this
fact by simply reporting a "0" for all these parameters when a Service
Worker is involved in between

Nicolas: Do we have a sense of what those properties be with a SW? Or
should we talk about it with SW folks?

Yoav: Would be useful to talk about it in terms of SW use cases

.... From a security perspective, can a SW add TAO to a cross-origin
response? Can’t do that as it’s an opaque response. So that’s probably fine.

Yoav: Marked as Level 2 blocking because it seems like we need to answer
that question



On Wed, Mar 11, 2020 at 9:35 AM Yoav Weiss <yoav@yoav.ws> wrote:

> Hey all,
>
> Let's meet <https://meet.google.com/agz-fbji-spp> this Thursday to talk
> Web Performance!
> On the agenda
> <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.qp908m37glq0>,
> we have Event Timing updates, general status check on the group's related
> incubations, as well as issue triage.
>
> As always, the call will be recorded and posted online.
>
> See y'all there! :)
> Yoav
>