- From: Nic Jansma <nic@nicj.net>
- Date: Wed, 24 Feb 2021 15:44:41 -0500
- To: public-web-perf <public-web-perf@w3.org>
- Message-ID: <CAALun4voc4eog5R_Qcz_Z1VMAfXEy99h4jQYKCjdqetXjDf1mA@mail.gmail.com>
Minutes below. Archive is at https://w3c.github.io/web-performance/meetings/ Participants Ishan Anand, Ben De kosnik, Nicolas, Annie, Michelle, Noam H, Michal, Giacomi, Gilles, Carine, Nic, Yoav MinutesLayout Shift Normalization <https://www.google.com/url?q=https://docs.google.com/presentation/d/1eIcBXcFaXzdHbwrtFLozvgESAPlxDJY1Xkky7-qeDLI/edit%23slide%3Did.p&sa=D&source=editors&ust=1614202759793000&usg=AOvVaw2iQWew0ld3bjVq0-ELMjeJ> - Annie Sullivan - Annie: Layout instability is not changing - … We have a metric called cumulative Layout Shift - … Concerns about the fact it grows unbounded, causing frustration - … Tried 200 strategies to improve that - One of the a sliding window, that’s updating over time - … session window which is grouping layout shifts and stops when there’s a gap - … Gap of a second was best - … Looking at the max window, both by summing and averaging them - … Performed well in initial tests - … Implemented and tried it out - … All strategies reduced correlation with time spent, which is good - … Accomplishing goals - … Found that 300ms window was too short to capture related layout shifts - … So was looking for max over session window and max over sliding window - … Would it make sense to rename the metric? - … Thoughts on different strategies? - Benjamin: Can you clarify the 5 seconds limit? Is there specific content that goes over? - Annie: infinite scroller that janks on each scroll - that can create small shifts that go over 5 seconds - Michal: Other common examples are layout inducing animations, or interval driven page updates - Annie: We saw poorly animated “scores” popping in, which over times those scores popping in aren’t getting worse. - Nic: For the session window, the layout shifts in the window would be summed? How will you aggregate? - Annie: Max - Nic: So the worst experience - Annie: When we looked at statistics, the 75th percentile or median experience, ti’s hard for the developer to reason about - … Only high percentiles correlated with bad user experience, and describing the interpolation would be confusing - Nic: Similar to the sliding window, you’re finding the worst 1 second? Easy to reason about - Michal: Rare situations where a large sliding window would capture the global maximum, but how timings are setup, session would always do the same. Sessions have a variable amount of time. Is a fixed slice important or not? That’s the semantic difference - Nic: Better browser supports that group user experience or action, you could group these by UX - Ishan: Read the blog post with a lot of interest. A lot of customers are e-commerce. Interested in the flow eCommerce - … Going back and forth can be fast in SPA - … Prefer session windows. Concern that if users go between pages quickly, you can group unrelated CLS. So don’t like uncapped windows. - … Concerned about users leaving the window open for a long time. Especially if there’s background work. - … and the last thing, wasn’t clear if the layout shift would be attributed to the URL of the initial page or to the URL of the SPA nav - Annie: Initial URL - Ishan: Logically scrolled through multiple pages, but we keep extending the sense of session - Michal: One way would be to adjust the gap to of the session window to be the same size as the hadRecentInput threshold - Benjamin: I think that what you’re proposing is different from CLS so would appreciate a new name. Feels different. - Nic: A lot of different types of tools and services reporting CLS. Agree that it feels different enough that it would make sense to rename BFCache reporting - Navigation IDs <https://www.google.com/url?q=https://docs.google.com/presentation/d/1snPIu2GJ_JO7esJ_3YmOAiXC_g4PeQW3jclYx1u3Qzs/edit?usp%3Dsharing&sa=D&source=editors&ust=1614202759798000&usg=AOvVaw0lAkOhob5uKabZRG4jrVVG> - Yoav: We want to align metrics with user-experience, including BFCache navigation - … Fire new entries rather than override old entries - … Single time origin for all navigation - … Fire new NavigationTiming entries (with new type) - … Should be web compatible to do so - .... Also fire new PaintTiming entries - … How do we correlate those PT with NT entries? - … Had previously suggested we use .time, but Ryosuke suggested this would be sufficient (for overlapping navigations) - … New NavigationID on PerformanceEntry - … Will incrementally increase each new navigation the document goes through - … Work well for BFCache now, as well as other types in the future (soft navigation), would work well with proposed App History API - … Spec changes: navigationID to PerformanceEntry, and counter to Document initialized to 0 - … Increment on BFCache navigation - … Simply initialize navigationID to document - … (example using PerformanceTimeline) - … Does this make general sense? - Noam: Navigation would be an increasing number, and not also surface the type? - Yoav: The ID would be treated as a pointer to the NavigationTiming entry - Benjamin: Good way to disambiguate, could be used for Soft Navs - … Curious about backwards compatibility - Yoav: NavigationID without BFCache navs would be just 0 all the time. - … Don’t think content is looking at random properties and if it finds them, it breaks. - … Are you suggesting forward-compatibility issues I’m missing? - Benjamin: Maybe it’s just an education thing and telling people what the numbers are - Nic: We’re not using PerformanceTimeline as much, but the example itself using it, maybe there are some cases where people want to get things by navigation ID - … For a really long running page like Gmail you want to get things by ID - Yoav: For an SPA I was thinking you’d have a PO and the callback could choose to segregate by ID - … RE: Do we want a getEntriesByID() -- this is a pattern from before we had filters, don’t see we need to add a dedicated API - Noam: We may want the ability to clear the previous entries - Yoav: Problem with shared buffers (like ResourceTiming) is that when multiple third parties are involved they can stomp on each other - … PO allows you to register when you want things and unregister when you don’t - Nicolas: There may be more memory used filtering in JavaScript than what the browser could do - Yoav: Looking at the internal Chrome implementation I don’t think it’d be that more efficient, for getEntriesByName() it’s not significantly different from getting all and filtering in JavaScript. But we can discuss - Nicolas: For the observer pattern, would you want to limit to a specific navigationID? - … i.e. if you want to listen after a BFCache nav and use buffered:true and only get the current BFCache navigation - Yoav: Maybe worthwhile to wait until we have people who use it in the field - Noam: Instead of the getEntries() API, could we expose it as a map of .navigations[n] - Yoav: With performance.getEntriesByType(“navigation”), you could then index - … Oh but if you want to get all entries based on that ID - Noam: API would be a direct lookup on that - Yoav: I’d like to wait until we have implementation experience and see what’s the best way to split - Nic: I do like this, navigationID is forward looking and could be used for SPA navigation in the future - Michal: Speaking of forward looking, fundamentally this is about segmenting perf entries based on their logical grouping. In the past, Benjamin talked about slicing based on visibility or whatever - Nicolas: I’m not sure we want to be able to segment based on everything - Michal: Got it, so everything needs a navigationID but not everything needs those other attribution - Yoav: I suspect some of this would be filtering done on the server or in the client anyway - … Worry about lots of custom filtering machinery when we already have JavaScript that can do the slicing and dicing - Nicolas: The question is do we want to expose a new FCP when you first become visible. - Michal: I don’t know if we’d ever expose paint. But for LayoutShifts I’d be interested in knowing if there was a long idle period. - Yoav: VisibilityObservers will give you better ways of getting that information retroactively - Michal: Navigation entries give you the ability to slice the data. By that argument, this is a convenience thing. It is future proof. - Yoav: If we were to consider in the future background and forwarding is a new thing, we could consider resetting the ID in those cases - … AI: Suggested next steps: Create various PRs on specs related to that (PerformanceTimeline, HTML, PaintTiming at least). Send them over to the list for greater scrutiny. - … Bikeshedding on the PerformanceTimeline PR if interested. - Benjamin: If we have monotonically increasing IDs, isn’t the largest the one that could be visible and if it’s not the largest it’s definitely not visible? - Yoav: Users could theoretically click on the back button then switch to a new tab. This whole BFCache navigation could be invisible for most of its time. - … Missing concrete examples of what we’d want to expose in those visibility sessions. Agree in principal it’s an interesting idea to explore, but I’m not sure what to do with it right now. - Benjamin: That’s fine, anything we can do to improve clarification on visibility would be worthwhile. Like the fact it might be able to discard a whole bunch of “what is visible”, and if we could get that as a bonus let’s take it https://github.com/WICG/element-timing/issues/54 <https://www.google.com/url?q=https://github.com/WICG/element-timing/issues/54&sa=D&source=editors&ust=1614202759805000&usg=AOvVaw33ZXWxjOrjMIgScjz5_Jby> - Yoav: Right now for ElementTiming we expose loadTime - … And renderTime for image, for all of the bytes of the image when rendered - … JPEG-XL folks who are finalizing a format that is progressive would like to expose more than the final time, since it doesn’t show JPEG-XL images show something to the user earlier compared to other formats like AVIF - … Jon is suggesting having multiple stages where we don’t only expose final render time but also the dimensions, placeholder paint/blur hash, preview paint, “good enough”, then final image - … Suggesting adding that to ElementTiming - … From my perspective, it’s interesting information but not sure what people would do with that - Noam: For evaluating how long it takes for someone to see a gesture, especially on slower connections - Nicolas: Is the image actually loading before the spinner - Yoav: What is this defined for animations, is it the first frame? - Nicolas: I don’t think we do a great job for animations - Noam: If it an app that has multiple thumbnails and then it shows the full image somewhere, it may not have the high-resolution image in memory yet - Yoav: But in those cases the thumbnail would be a separate image, and when you clicked it would open the full image - Nicolas: I think this would only be for progressive images - Patrick: There’s a weird line where baseline images also draw incrementally - … Separating incremental painting for baseline images from progressive images - … Almost want an event where the entire area is updated - … But I could see, there’s a few companies where they use regular JPEG with custom scans, and the first image is a greyscale and add the color afterwards. - … In those cases they’d want to know when each scan completes - Yoav: Instead of multiple defined entries, these are all the times when scans happened - Michelle: I’m from Pinterest, we have a custom metric called PinToWaitTime and includes load and rendering time of all images in viewport -- has 60% quality of progressive jpegs. We just want to identify a point where our quality threshold has been met - Nicolas: So we’d need to expose for each scan the quality? - Patrick: I’m not sure, just the number of scans and that’s up to whose serving the image - Nicolas: I’m not sure if every browser will paint the same amount - Patrick: If you do a percentage based on the number of scans or quality - Yoav: Or number of bits? - Patrick: I don’t think number of bits will tell you - Yoav: Giacomo on chat says this could be useful for LCP - … I think LCP’s semantics are aligned more with “good enough” paint - ... One of the goals is to be a single number rather than an array of scan - … Separate issue related to LCP where we converged on “good enough” for its semantics - Benjamin: Isn’t this an extended version of PaintTiming applied per-element - … First Paint is placeholder paint, etc - Yoav: You’re saying there are parallels between those milestones and the full-page render - Yoav: Asking for use-cases to comment on the issue, stating how they’d use this. Patrick maybe you want to have a more flexible structure related to scans? - Nichttp://nicj.net/ @NicJ On Wed, Feb 17, 2021 at 9:34 AM 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 February 18th @ 10am PT / 1pm ET) we will > discuss: > > - Layout Shift Normalization > - workerStart issues with NavigationTiming > <https://github.com/w3c/navigation-timing/issues/128> > - Element Timing: Image rendering stages: finer granularity > <https://github.com/WICG/element-timing/issues/54> > - HR Time: timeOrigin is not clamped > <https://github.com/w3c/hr-time/issues/105> > > 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 meeting will be recorded and published online afterwards. > > See you soon! > > - Nichttps://nicj.net/ > @NicJ > >
Received on Wednesday, 24 February 2021 20:45:10 UTC