Re: WebPerfWG call - November 18th 2021 @ 10am PT

and recordings are now available, and published to Github


   - Interaction count recording video

Minutes and summaries copied additionally below:



Nic Jansma, Dan Shappie, Ian Clelland, Sean Feng, Carine, Steven Bougon,
Annie Sullivan, Philip Walton, Michal Mocny, Nicolas Pena Moreno, Noam
Rosenthal, Yoav Weiss, Benjamin de kosnik

   - Nic: Next call - December 2nd?
   - … Maybe the last call for the year, but we can decide that later
   - … Otherwise, wanted to show a poll I’d be sharing on the mailing list
   - … Potential options to move the meetings earlier.
   - Ian: Quick question - is there a timezone the meetings are based in?
   May matter when moving to daylight savings
   - Nic: Notes on TPAC - we cleaned up the minutes, uploaded videos
   - … We’ll share out the minutes and push to GH soon. Waiting on a few
   small pieces of summaries to happen, tagged folks on email.

Icons RT entries

   - Questions about favicons and their ResourceTiming entries, as favicon
   behavior is not standardized and each User Agent handles them differently
   - Icons may need to be double-keyed cached to avoid information leakage
   - Discussion will continue at


   - Noam: This is about icons and their RT entries. Was going through the
   Fetch and HTML integration, and seeing how things get fetched, and saw that
   favicons were not specified, and had different behaviors in different
   - … Up until now favicons were not observable to the document. There’s
   no onload nor other event that’s observable to the web.
   - … Resource Timing makes them web observable, and in practice they need
   to be double-keyed cached, to avoid leaking information.
   - … So the metrics forces behavior change because it’s making it web
   - Yoav: We need to split cache anyway, as it’s observable to the origin
   - Dan: What about SWs?
   - Noam: SWs are typically same origin
   - … Double keyed caching solves it, but it can reduce performance for
   popular favicons
   - Yoav: Is that a common case?
   - Noam: The framing question: “should RT be the way in which things
   become web exposed?” There should be some guideline around that. There may
   be another implication
   - … The actual exposure was never discussed
   - Michal: Say we wanted to expose favicons to RT, would we need to first
   expose it elsewhere?
   - … Concern is valid, but sometimes things only need to be exposed to RT
   - Noam: That’s fine as long as there’s a discussion
   - … In Safari it’s exposed but has a different initiator
   - … Should be link, but “other” and “icon”
   - Michal: Is there a use case for this mostly to know how large they
   are? Someone did a research on how large they are
   - … Should we expose just the size?
   - Noam: Only expose for same origin
   - Dan: How do resource hints impact favicons? Seems like they should
   have the same caching mechanism as everything else
   - Noam: Not sure what their CSP protections are. They are not exactly
   fetched the same way as other resources. More a hint to the browser that it
   should update the UI
   - Nicolas: You said they are not fetched, so how does that work?
   - Noam: Fetched but not in the spec sense. Unrelated to the document
   - Michal: metadata that the browser can use
   - Nicolas: In order to use TAO, etc, we need it to be tied to Fetch, so
   maybe we should fix the Fetch integration
   - Noam: TAO adds it to the document today. It wasn’t tied before it was
   - Michal: Wondering if there are other analogies. When there are many
   icons, which get fetched?
   - Nic: Do modern browsers still fetch the well-known favicon. Is that
   still a thing?
   - Noam: They do
   - … Somebody probably fetches the link tag for the AMP page version, but
   not sure
   - We can keep things as they are and file bugs on double key caching
   - … Or make RT entries for icons same origin only
   - Nic: Isn’t the cross-origin case protected by TAO?
   - Noam: When cached it’s not there
   - Yoav: But that’s different from other RT entries
   - Noam: It’s a browser resource not a document resource. But that could
   force browsers to eliminate icon entries or change the cache
   - Michal: Back to the unintended consequences of this exposure
   - Benjamin: Should try to avoid that if possible. Would be good to
   qualify if they are document or browser
   - Yoav: Case for cross-origin favicons is a niche case
   - Dan: Do you think that it doesn’t happen a lot, or not significant
   - Yoav: Not happen frequently
   - Dan: For WIX, default favicon comes from wix domain, so cross-origin
   - Yoav: Ideally we should figure out what’s exposed, expose same way we
   do other resources, and not have a boolean whether they are cached or not
   - ... Double-keying them will have implications on sites with
   cross-origin favicons
   - … At the same time they’re not part of the page content
   - Dan: From my perspective, I don’t think favicon has performance
   implications for how people experience websites
   - … Only if they’re huge and consume bandwidth
   - … Hope that’s fairly rare
   - … Don’t see double-keyed caching as significant performance concern
   - … Recommendation is that they should be double-key cached
   - Yoav: Let’s continue discussion on issue

Exposing interaction counts to web developers (npm)Recording:

   - We currently expose interactionIds in order for developers to group
   the entries of distinct events that correspond to the same user
   interaction: keydown, keyup, input for keypress, and pointerdown,
   pointerup, click for tag or drag.
   - But it is currently not possible to accurately know the number of
   interactions (per our definition) which have occurred on the page. This is
   required to compute several metrics, such as average or median.
   - npm@ presented 5 possible solutions for this problem. The crowd
   favorite was solution 2, which was exposing InteractionCounts with the
   number of user interactions (total or of each type) in the page so far,
   similar to the currently spec’d EventCounts.
   filed to get more feedback, bikeshed the naming, and track the spec work


   - Nicolas: Going to chat about exposing the number of interactions to
   web developers
   - … Want to enable computing input latency metrics
   - … Useful for analytics providers, that need to rely on heuristics
   - … What is an interaction?
   - … Have composition events so <TODO>
   - … Otherwise, taps (down or up) and drag (initial and release)
   - … Some events can happen far apart from each other, so it can be hard
   to correlate events to an interaction, so we introduced interaction ID
   - … When the entry doesn’t correspond to an interaction, the ID is zero
   - … Reached a problem: even though developers can correlate
   interactions, they can’t know how many of those happened on the page
   - … A problem if you want to calculate average, median, percentile
   - … We don’t know because the observer is not exposing all the events,
   as it has a minimal duration filter
   - … Makes it hard to know about fast interactions
   - … Potential solutions:
   - … (1) Extending eventCounts
   - … Can add a new key in the map for “interaction”, or multiple for a
   few interaction types
   - … The difference here is that eventCounts are a different thing, and
   we’d be cramming different things into the same map
   - … (2) InteractionCounts
   - … Create a new map that only contains interactions (either a global
   key for interactions, or a key per type)
   - … (3) If we think developers won’t care about the different types, we
   can just have a single integer, exposed in interactionCount
   - … Saves us a map, but the same for web developers
   - … (4) Allow durationThreshold to be 0. Currently it’s minimum 16ms, so
   faster events can’t surface it
   - … Maybe we can just allow developers to see faster events?
   - … It could become expensive, as developers would run callbacks, but
   ones that developers not care about because they are interested in another
   entry type
   - … May need a filter in the observer itself, to reduce that cost
   - … (5) expose all entries with interactionID, and exempt them from the
   duration threshold
   - … That could be confusing
   - … Thoughts?
   - Nic: Quick take - I like the simplicity of solution (2) from a
   developer’s perspective. (4) and (5) also give you their timestamps, which
   would be novel
   - Nicolas: Great points
   - Dan: Wouldn’t it have memory usage implications if we fire entries?
   - Nicolas: Could be if developers store information based on those
   - … Otherwise, the entries are exposed to the observer, to not stored
   unless the developer wants to keep them around
   - … Dunno how common it would be. But the entries shouldn’t be massive
   - Philip: Like solution (2). Question - are the interaction types
   - Nicolas: We specified how to compute interaction ID, so easy to split
   them out into keyboard. Tap/drag is harder, can try to use click as a
   proxy, but that’s not always true.
   - … needs more thought
   - .. but can say that any move makes a tap into a drag.
   - … If we went with it, we’d specify it
   - … Needs some bikeshedding
   - Philip: Was thinking that we can pass the event name, and get the
   interactions that included it? But that may complicate things
   - Michal: Would we reach buffer limits more often?
   - Nicolas: Only if we’d buffer them. Right now we only buffer 100+
   entries. There’s no way to buffer faster entries.
   - … You could use an observer with a smaller duration. Faster earlier
   entries won’t be buffered.
   - … If we’d want this, we’d need to buffer them
   - … That’s a blocker for the entry exposure solutions, because we can’t
   buffer them?
   - Sean: Currently only increase interactionID, rather than just increase
   it by 1. What’s the reason for that. Can’t we just use it for enumeration?
   - Nicolas: We can definitely change it to start with 1 and increment by 1
   - … But you can have a page with fast interactions at the end, which
   won’t be seen by the observer.
   - … It’d be the last number of the slow interaction
   - … So even if we dropped the random number, it won’t solve the problem
   - Sean: Why can’t we increase it for the fast ones?
   - Nicolas: we can but they won’t be exposed. You’d need a slow one with
   an interaction ID set
   - Nic: Is there an issue to gather comments on this?
   - Nicolas: Good idea. I’ll check and if there isn’t I’ll ping with
   the issue
   - … Sounds like most votes are for solution (2), so leaning towards that
   - … Also needs ideas on naming for key press interactions
   - Michal: Orthogonal question - The name “interactions” is kinda new
   - … What if you have an event handler and access to the event object
   - … Is it possible you would want to convert the event object to
   interactionID (or performance entry) so you can look up it’s event timing--
   or, all interactions of that type?
   - Nicolas: NoamH asked for this in the past to correlate event handlers
   with event timing entries.
   - … By the time an event is running we don’t necessarily know it’s part
   of an interaction, so that can be tricky.
   - … e.g. For a pointer down while you scroll, you won’t get an
   - ======
   - Ian: No time to discuss cross-frame performance timeline
   please look at the doc by the next call.


   - Nic: One note, we’re now asking for speakers to summarize discussion,
   similar to TPAC minutes, to make it easier to share quick notes

- Nic

On Wed, Nov 17, 2021 at 1:10 PM Nic Jansma <> wrote:

> Hi everyone!
> On the agenda
> <>
> for our next call (Thursday November 18th @ 10am PT / 1pm ET) we will
> discuss:
>    - ResourceTiming - Icon RT entries
>    - Exposing interaction counts to web developers (npm)
>    - Cross-frame performance timeline proposal (iclelland)
>    - Element Timing discussion (TPAC followup)* (if enough time)*
>    - Layout Instability - Chrome Implementation Lessons (TPAC followup)*
>    (if enough time)*
> Plus any other issues you want to talk about. If you additional items,
> please add to the agenda
> <>
> .
> Join us <>!
> The presentations will be recorded and published online afterwards.
> See you soon!
> - Nic
> @NicJ

Received on Monday, 29 November 2021 18:17:47 UTC