- From: Nic Jansma <nic@nicj.net>
- Date: Mon, 29 Nov 2021 13:17:20 -0500
- To: public-web-perf <public-web-perf@w3.org>
- Message-ID: <CAALun4tX-py-pwu3yedq9sw8Gtx4+m9gB8Fg7bO2uQBWtWd5uQ@mail.gmail.com>
Minutes <https://docs.google.com/document/d/14UOTu1EZQg5GyfvyiVXOnF49SL4cD3AHdmp9tSAvstI/edit?usp=sharing> and recordings are now available, and published to Github <https://github.com/w3c/web-performance/tree/gh-pages/meetings>. Recordings: - Interaction count recording video <https://www.youtube.com/watch?v=YtulAGmOooI> Minutes and summaries copied additionally below: --- Participants 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 Minutes - 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 <https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/298&sa=D&source=editors&ust=1638213049231000&usg=AOvVaw1w2KKn9QrayaiYv8HDsHPc> Summary - 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 https://github.com/w3c/resource-timing/issues/298 <https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/298&sa=D&source=editors&ust=1638213049231000&usg=AOvVaw1w2KKn9QrayaiYv8HDsHPc> Minutes - 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 scenarios. - … 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 observable. - 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 timed. - 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: https://www.youtube.com/watch?v=YtulAGmOooI <https://www.google.com/url?q=https://www.youtube.com/watch?v%3DYtulAGmOooI&sa=D&source=editors&ust=1638213049238000&usg=AOvVaw0tJFTbBbHVrspdB0sTqfH8> Summary - 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. https://github.com/WICG/event-timing/issues/111 <https://www.google.com/url?q=https://github.com/WICG/event-timing/issues/111&sa=D&source=editors&ust=1638213049238000&usg=AOvVaw1kVWi5zXX6i6sPtiBa5bH1> was filed to get more feedback, bikeshed the naming, and track the spec work required. Minutes - 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 entries - … 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 specified? - 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 - https://github.com/WICG/event-timing/issues/111 - … 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 interactionID - ====== - Ian: No time to discuss cross-frame performance timeline <https://www.google.com/url?q=https://docs.google.com/document/u/1/d/1LbXafcZMHagLReSkEkjhQdOIzeA9RS8_2e0_g5QLgY0/edit?resourcekey%3D0-n9hTSQXGoyboIssA4wSGGw&sa=D&source=editors&ust=1638213049246000&usg=AOvVaw3IOIyODNkbBwxvTy9iTdA2> but please look at the doc by the next call. Misc - Nic: One note, we’re now asking for speakers to summarize discussion, similar to TPAC minutes, to make it easier to share quick notes - Nichttp://nicj.net/ @NicJ On Wed, Nov 17, 2021 at 1:10 PM Nic Jansma <nic@nicj.net> wrote: > Hi everyone! > > On the agenda > <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.osvewfb7hvdz> > 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 > <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.osvewfb7hvdz> > . > > Join us <https://meet.google.com/agz-fbji-spp>! > > The presentations will be recorded and published online afterwards. > > See you soon! > > - Nichttps://nicj.net/ > @NicJ > >
Received on Monday, 29 November 2021 18:17:47 UTC