Re: WebPerfWG call - Mar 16th @ 7am PT / 10am ET

The presentation recordings are also now available in the minutes:
AsyncContext <https://www.youtube.com/watch?v=yFB8xAMFXk8> and
PendingRequest <https://www.youtube.com/watch?v=Y1MY14y9Ztc>

On Fri, Mar 17, 2023 at 2:28 PM Nic Jansma <nic@nicj.net> wrote:

> Minutes are now available:
>
>     Linked to from our WebPerf WG Agenda document
> <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit#>
>     Published to the web-performance Github meetings page
> <https://w3c.github.io/web-performance/meetings/>
>     ... and copied below:
> Participants
>
>    - Chengzhong Wu, Fergal Daly, Ming-Ying Chung, Noam Helfman, Nic
>    Jansma, Yoav Weiss, Carine Bournez, Barry Pollard, Pat Meenan, Sia
>    Karamalegos, Annie Sullivan, Andrew Galloni, Beri Lee, Justin Ridgewell,
>    Michal Mocy, Scott Haseley, Sean Feng, Amiya Gupta, Alex Christensen, Alon
>    Kochba,
>
> Admin
>
>    - Next meeting: March 30, 2023 @ 11am EST / 8am PST
>    - TPAC 2023
>
>
>    - Sevilla, Spain, 11-15 September
>
> Minutes AsyncContext - Chengzhong & Justin (TC39)
>
>    - Chengzhong: Working on AsyncContext proposal
>    - ...
>    - ... Implicitly propagates values through callstacks
>    - ... Captures global context and in the returned callback
>    - ... Has a run() and get() methods, running get/set operations on the
>    instance
>    - ... run() runs a callback w/ value set in context
>    - ... get() method returns the value in the current context of the
>    instance
>    -
>    -
>    - ... Call it with different expected values and context values
>    - ... In this function we're waiting on a promise, and the context is
>    persisted across the async boundaries, even if it's being called in a sync
>    way
>    - ... Values in context are persistent across async continuations
>    - ... Helpful when we are tracing soft navigations
>    -
>    - ... Critical when HTML was updated, which operation initiated these
>    chains of interaction
>    - ... There can be also useful for transitive task attribution
>    - ... Like runtime schedules tasks w/ priorities, task priority
>    attribution is not transitive at the moment
>    -
>    - ... We can perform fetch and wait for the response, and the priority
>    can still be observed
>    - ... This can be useful for execution priorities and fetch
>    priorities, and even used in privacy protection propagation
>    -
>    - ... In OpenTelemetry, save their spans in AsyncContext and can
>    retrieve spans to see what started the interactions
>    - ... Cannot introduce new parameters to existing libraries, so they
>    can use AsyncContext to propagate their spans
>    -
>    -
>    - ... Propagation of spans via OpenTelemetry can utilize this
>    AsyncContext even for nested fetches
>    - ... Can help distinguish the initiator of the fetch call
>    - ... Seamless without user-code changes
>    - ... Generate spans as shown in the example
>    -
>    - ... User Request plus their detailed network timings
>    - ... OpenTelemetry support of Long Tasks Initiator
>    -
>    - ... Tracking Long Tasks effectively to see where it was spawned from
>    - ... Roughly equal to a new PerformanceObserver of LongTasks, but no
>    way to tell whether task function was called in a tracing span
>    - ... If integrated with AsyncContext, userland application monitoring
>    can tell the LongTask initiator in the PerformanceObserver callbacks
>    -
>    - ... Cannot tell exact initiator of the ResourceTiming entries
>    - ... Tagging with AsyncContext can help figure out the cause without
>    looking at just times
>    - Yoav: Thank you for outlining all of the use-cases
>    - ... For ResourceTiming, we have an open issue around adding more
>    initiator data for ResourceTiming.  We have initiatorType, we'd like to add
>    more data to the entry.
>    - ... For some of those things, it may be better to bake in that
>    attribution that you're looking for, rather than jumping through JavaScript
>    hoops to get it.
>    - ... I'd be interested to know if anyone collecting RUM in the room
>    find use-cases that they've tried to do
>    - Nic: This could help in a couple of things we’re doing - monitoring
>    soft navigation without additional information we’re looking for route
>    changes and observing changes on the page. But things can happen outside of
>    the user’s activity (e.g. timers). Those can extend the duration of time
>    that we’re looking at
>    - … user interactions and how they relate to resource load and long
>    tasks can make RUM more precise by keeping track of things that are the
>    “child of the click”
>    - Justin: the use case - you have running JS code but trying to
>    understand what spawned the JS code? You wouldn’t be able to inspect the
>    global state from outside the promise.
>    - … you would be able to know that whatever’s currently executing was
>    spawned from a user click
>    - … Inside the running code you’d be able to know the context, but if
>    you just have a callback, you can’t determine the context that spawned it
>    - Nic: As a RUM observer, we’d be treating the runtime as a black box.
>    I was imagining us listening to clicks on the page and mutation observers.
>    If these activities were happening, we could see the groups of async
>    contexts and group them by that
>    - Justin: we could expose it on the callback, so you’d be able to know
>    that this task was spawned from that context
>    - Nic: Would an observer also have access to the context in this
>    proposal?
>    - Justin: You would not be able to inspect the state inside the
>    callback, unless it’s running.
>    - … If the callback calls into your code, you’d be able to observe
>    state
>    - Nic: In the context of PerformanceObserver, would the context be
>    available?
>    - Justin: You’d be able to expose your own context on the performance
>    observer, but not get the context that spawned the entry
>    - Nic: As a RUM provider, we’re observing, not creating
>    - Justin: As a library you can create an async context, instrument
>    click events, and then inspect the state of your own asyncContext
>    - Chengzhong: OpenTelemetry does that and instruments entry points to
>    be able to inspect code
>    - Nic: I’d have to better understand it. If there are ways we can pay
>    attention to this without creating our own contexts, that’d be interesting.
>    - Michal: PerfObserver registers a single observer once. If you’re
>    creating new async contexts when new events fire, are they linked?
>    - Justin: You would instrument your events and call context.run with
>    the callback code. Then whenever that callback is called later, you’d know
>    which asyncContext was run
>    - …
>    - … Whenever the “done” event is detected, you’d be able to know which
>    value was placed in line 3
>    - Michal: PerfObserver is not part of that context though
>    - Chengzhong: We’d need a separate proposal for PerfObserver capture
>    that context
>    - Nic: Feedback?
>    - Chengzhong: https://github.com/tc39/proposal-async-context
>    <https://www.google.com/url?q=https://github.com/tc39/proposal-async-context&sa=D&source=editors&ust=1679063198848914&usg=AOvVaw1NBU9CsMV_SRt6G9H70rjL>
>
> PendingBeacon design questions
> <https://www.google.com/url?q=https://docs.google.com/presentation/d/1w_v2kn4RxDmGQ76HAHbuWpYMPj7XsHkYOILIkLs9ppY/edit%23slide%3Did.p&sa=D&source=editors&ust=1679063198849380&usg=AOvVaw2lzkT6Z0GUzpmePYF8OZfI> -
> Fergal & Ming-Ying
>
>    - Ming-Ying: Working on PendingBeacon
>    - ... Motivation is to have a more reliable way for beaconing
>    - ... Want to provide an alternative API
>    -
>    - ... Reliable mechanism for delaying request-sending until page
>    discard (unload/bfcache)
>    - ... Request needs to be kept alive until it's finished
>    -
>    - ... New PendingRequest, subclass of Fetch's Request
>    - ... Subset of Requests' fields updateable here
>    - ... pending state tells whether the request is still pending
>    - ... And provide a sendNow() method
>    - ... Transforms the PendingRequest object into a regular Fetch
>    Request object
>    - ... Setting sendAfterBeingBackgroundedTimeout
>    - Fergal: API is very similar to what we've been proposing before,
>    PendingBeacon.  We've moved away from an object that manages the whole
>    thing, to a Request that goes into Fetch.
>    - ... It's familiar to before, but transitioned to this
>    - ... The Explainer still describes the original one, this is more
>    recent
>    -
>    - Ming-Ying: Constructor takes only these fields.  Other like
>    keepAlive are not available.
>    -
>    - ...Examples here.  PendingRequest creation for when the page gets
>    discarded
>    -
>    - ... Example to sending PendingRequest immediately
>    - ... You can update the beacon data when it's still pending
>    - ... Cancel or abort a request
>    -
>    - ... After page hits 1 minute of hidden, it'll kick off the beacon
>    sending process
>    -
>    - ... More concrete example
>    -
>    - ... Would like feedback on the API shape
>    - Noam: If there's no backgrounded timeout, when does it get sent
>    (unload?)
>    - Ming-Ying: Basically unload, an "implicit" unload.  But browsers can
>    do more, i.e. crash recovery, etc.
>    - Fergal: There's no unload of a page in bfcache, there's no unload.
>    But we will send a beacon
>    - Noam: Not during the "unload" event but something similar
>    - Fergal: At document destruction
>    - Noam: Feedback on the API shape, I'm a little confused why going
>    with Subclassing, it shadows a lot of stuff from Request.  Changes the
>    meaning in many ways.  Is there an advantage?
>    - Ming-Ying: One reason is we want to use Fetch API
>    - ... We don't want user to be able to configure other fields
>    - Fergal: The previous proposal didn't do this at all, so we've had a
>    strong push from Apple to try to use the Fetch API
>    - ... It's possible to not subclass and to say Fetch would take X or Y
>    - Noam: Or a mix-in style where if Request has an AbortSignal it has a
>    Pending signal.  An extension rather than a subclass.
>    - ... Regular request but something else can happen with it
>    - ... A beforerequest callback kind of thing
>    - ... Subclassing gets confusing at times, with shadowing things
>    - Fergal: We'll consider that
>    - Noam: Happy to discuss offline too
>    - ... When I see shadows, I feel disoriented
>    - Ming-Ying: Take feedback and see if we can achieve our goal
>    - ... Don't want the regular Request here
>    - Fergal: Maybe not a subclass but an alternative
>    - Nic: started playing with PendingBeacon, which seemed ergonomic
>    enough, this one is also fine
>    - … Any differences in functionality?
>    - Fergal: achieves all the same things
>    - Ming-Ying: +custom headers, from fetch() integration
>    - Noam: Any use case for using GET with this? Of doing something with
>    the response?
>    - Fergal: This is for things that shouldn’t have a response. But if we
>    are going to resolve the response when the fetch happened, there’s a
>    question of what the response should be. Empty seems more consistent
>    - Ming-Ying: didn’t previously consider that approach it looks like
>    we’d get a response. Need to make it clear in the spec that using that
>    won’t get you a promise
>    - Fergal: Either never resolve or always resolve to empty. Unless
>    there’s a good reason to do otherwise
>    - Nic: the timeout parameter sounds like it’s not brought forward and
>    handled in userland?
>    - Ming-Ying: Can be done with setTimeout
>    - Nic: Looked like you could update the body of the object and that
>    was a stream. Does that have a benefit over the older method? Does the
>    stream allow us to do compression?
>    - Ming-Ying: Should support the same API as the old PendingBeacon, a
>    stream may not be appropriate
>    - Alex: Also had a question about the readable stream - how can we
>    enforce a 64KB limit of it’s a readable stream, unless we read the stream
>    right away
>    - Alex: Weird, usually it’s read as its sent
>    - Alex:  May say that if it’s a readable stream, we have to read it
>    right away
>    - Ming-Ying: maybe it shouldn’t be a readable stream
>    - Fergal: Limits are an interesting question. How do we handle this?
>    Can easily reach 64KB, but don’t want people racing into it.
>    - … Should we flush beacons early if we’re reaching the limit? This is
>    tricky
>    - Nic: Where should additional feedback go?
>    - Fergal: We can create an issue
>    - ... https://github.com/WICG/pending-beacon
>    <https://www.google.com/url?q=https://github.com/WICG/pending-beacon&sa=D&source=editors&ust=1679063198854486&usg=AOvVaw0sifOy58PLheJl04tcTiLR>
>
>    - Ming-Ying: comment on proposal
>
> LCP Entropy
>
>    - Ian: Looking at bpp for LCP consideration
>    - ... Ran an experiment at Chrome stable and found that the number of
>    origins that had good LCP changed in less than 1%
>    - … So want to start excluding LCP that’s less than 0.2 bpp
>    - Nic: Are you publishing this?
>    - Ian: Working on it
>
> - Nichttps://nicj.net/
> @NicJ
>
> On 3/15/2023 12:52 PM, Nic Jansma wrote:
>
> Hi everyone!
>
> On the agenda
> <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.osvewfb7hvdz>
> for our next call (Mar 16th @ 7am PT / 10am ET) we will discuss:
>
>    - PendingBeacon design questions
>    - AsyncContext
>
> Please note the earlier time-slot to accommodate our speakers.
> * <https://github.com/w3c/resource-timing/issues/304>* If you have
> additional items, please add them to the agenda
> <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.osvewfb7hvdz>
> .
>
> Join us <https://meet.google.com/agz-fbji-spp>!
>
> - Nichttps://nicj.net/
> @NicJ
>
>
>