Re: WebPerfWG call - February 18th 2021 @ 10am PST

Minutes below.  Archive is at


Ishan Anand, Ben De kosnik, Nicolas, Annie, Michelle, Noam H, Michal,
Giacomi, Gilles, Carine, Nic, Yoav
MinutesLayout Shift Normalization
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
   - … So was looking for max over session window and max over sliding
   - … 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

   - Yoav: We want to align metrics with user-experience, including BFCache
   - … 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
   - … 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
   - 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
   - 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
   - Noam: Instead of the getEntries() API, could we expose it as a map of
   - Yoav: With performance.getEntriesByType(“navigation”), you could then
   - … 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

   - Yoav: Right now for ElementTiming we expose loadTime
   - … And renderTime for image, for all of the bytes of the image when
   - … 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
   - … 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
   - 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
   - … Separating incremental painting for baseline images from progressive
   - … 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
   - … 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
   - … Separate issue related to LCP where we converged on “good enough”
   for its semantics
   - Benjamin: Isn’t this an extended version of PaintTiming applied
   - … 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?

- Nic

On Wed, Feb 17, 2021 at 9:34 AM Nic Jansma <> wrote:

> Hi everyone!
> On the agenda
> <>
> for our next call (Thursday February 18th @ 10am PT / 1pm ET) we will
> discuss:
>    - Layout Shift Normalization
>    - workerStart issues with NavigationTiming
>    <>
>    - Element Timing: Image rendering stages: finer granularity
>    <>
>    - HR Time: timeOrigin is not clamped
>    <>
> Plus any other issues you want to talk about. If you additional items,
> please add to the agenda
> <>
> .
> Join us <>!
> The meeting will be recorded and published online afterwards.
> See you soon!
> - Nic
> @NicJ

Received on Wednesday, 24 February 2021 20:45:10 UTC