Participants

Nic Jansma, Philip Tellis, Mike Henniger, Yoav Weiss, Annie Sullivan, Guohui Deng, Giacomo Zecchini, Sean Feng, Abishek Ghosh, Andy Luhrs, Benjamin De Kosnik, Michal Mocny, Carine Bournez, Joone Hur, Bas Schouten

Admin

Next Call - Feb 26 (Move to Wednesday) 8am PST / 11am EST

Yoav to change meeting invite to correspond to that

Call times - should we reconsider??

Do we have more participation in earlier or later slots at all?

We need some RCM (Real Caller Monitoring)

Minutes

Add intersectionRect from ElementTiming to LCP - Michal Mocny

Michal: issue filed (LCP#127)
… there’s an intersectionRect that Element Timing exposes and you can use this to build your own HUD to see where the element fired
… many sites use LCP rather than Element Timing, but the intersectionRect is not actually exposed on LCP
… Played with snippets on that front, but the spec starts by computing the intersectionRect, convert it to size and only expose size
… Found an issue from 6 years ago where the ElementTiming algo doesn’t do the opposite and doesn’t represent the size of the image
… For LCP the thing that defines what is largest is a combination of a few factors.
… so there’s some discrepancy here
… ET only reports the rect and LCP only exposes the size
… But the specs are very similar and there’s no significant reason for this.
… looks like ET has naturalWidth and naturalHeight which is presumably the size % the intersection rect
… I doubt anyone would have a problem with fixing the inconsistency, but curious how this data is used in the field. Is this a missing feature?
Benjamin: We noticed this. We’d love to be able to compute where the outline of the LCP element is. Not enough data to do that now
Bas: found this out two weeks ago.
Michal: would it be surprising if we have both the size and the intersectionRect and the sizes didn’t necessarily match?
Michal: So let’s do that! I’ll follow up with naturalWidth and height
Philip: we use natural width and height to tell if images were scaled to all images in general. We get it from the image object itself
Benjamin: but after the fact without a DOM tree, this is harder
Michal: intersectionRect gives you where the element was on the screen, which may change.
… for consistency, I hear demand for exposing intersectionRect on LCP
… less sure we need size on ElementTiming
Benjamin: enthusiastic about this
Michal: had some reports about ElementTiming where content is below the fold
… For LCP it’s a bit more clear cut as scrolling stops it
… I’ll run some quick tests

Expose Performance interface to AudioWorklet

Yoav: Not complicated
... Performance interface is defined in hr-time for historical reasons
... Expose interface to AudioWorklets, so they can use performance.now() and .timeOrigin to capture metrics inside of an AudioWorklet
... Seems like a harmless addition
... Any objections?
... My main question, is what's special about AudioWorklet
... Will this list get longer over time?
Bas: Will this get expanded to all worklets?
Yoav: Don't know worklets well enough
... Is there an exposed Worklet, is that valid IDL, or does each Worklet have its own?
... Seems harmless
Bas: Bit of work to implement
Yoav: On Chromium side it's audio folks pushing, so they'd do implementation
Bas: I can ask audio team
... Got feedback, it would be useful, one of the folks on our audio team was part of requesting it
... Question is whether it's gated on isolation, there are security concerns if it is not
Yoav: Yes it would be, that's how hr-time is defined, would be interesting to think how on the PR
... Right now it's taking cross-origin property is coming from a TODO object, not sure how that is on Worklets

Interop

Barry: INP and LCP are meant to be interopable across all browser by end of year
... Thank you for Firefox and Safari people supporting this
Bas: I think there'll be some discussions around LCP implementations
... Considering it's in Interop, I don't know if we want to focus solely on places where it doesn't pass tests?
... If all we want to make sure is all tests as defined in Interop?
... Or to take opportunity to fix discrepancies that aren't covered by tests
Michal: In the past, being selected by Interop meant existing specs and tests were solid enough
... But in my opinion that's not that fruitful, we should do what's fruitful
... If this is the year to spend more attention to fix gaps to make it what we want it to be, the earlier the better
... If you notice obvious discrepancies on things being tested, we should start there
Bas: Interesting to see Webkit's implementation, and seeing whether theirs matches more closely to Chrome or Gecko, or a whole new set of discrepancies
... Depends on how well we spec'd this
Barry: Absolutely, and we should use this forum
... Interop primarily driven around web platform tests (WPTs)
... Let's try to avoid disagreeing on what tests are important
Michal: Might be going into weeds, but spec update for PaintTiming-Mixin, Chromium has an experiment
... Cleans up some differences in presentation time vs display time
... Noam made some updates to tests, but not sure if LCP is updated for all of these things
... Maybe limit to subtests that are interop-able
... Not sure if all tests are updated
... Interop situation is better than ever in terms of possibilities
Yoav: Ideal way of exposing discrepancies between implementations, is a test that does something in that area
... Mark it as tentative, and we can see that in wpt.fyi
... This is an area that there's some disagreement between implementations
... We can discuss that in this group, do we want A or B?
... It would be great if discrepancies between implementations would be covered by tests showing behavior
Bas: Wouldn't be part of Interop, because that could be scope creep
... We know the tests that are there, and the discrepancies
Yoav: Agree that it could be scary but the alternative is that we have 3 implementations that pass the tests but don't agree on things, that's scarier
Michal: Other part is INP
... Last time we talked, and you expressed support for interactions in general
... Chromium is going through a lot of stages of cleanup, it got complicated before it got simpler
... Doesn't change EventTiming or how it's spec'd
... But I think there are simpler ways to do it based on what we learned
... If you're in the weeds of implementing, reach out
Bas: interactionID stuff I think Ollie had some questions around
... I was curious about duration as specified, it has some language around when to do it
... Right after paint as defined in the spec, that seems to be what we're doing as far as I can tell, we're firing after main thread part of the paint has been done, that seems consistent for how we handle it in spec
... But I remember you sharing some concerns
Michal: Answers are exactly the same as LCP, not with PaintTiming Mixin, there are two values, the paintTime and presentationTime. paintTime is on the main thread, before UA-specific paint starts, after style and layout, but before work of paint.
Bas: Need more on PaintTiming Mixin
Michal: EventTiming spec hasn't been updated in terms of Mixin, it does a better job specifying the things we're using
... Right now EventTiming is in terms of presentationTime, but the way we want to do it is, you'll always have a paintTime, you may have a presentationTime, e.g. if not X-O isolated
... Take whichever is largest and available
Bas: Current spec, in Interop, seems to require it to be the paintTime, rather than presentationTime
Michal: I read it is presentationTime, but we can take a look
... spec for EventTiming needs updating
Bas: We can discuss async
Michal: I think what you're doing right now is fine.
... Events right now, there's only one next frame
... paint vs presentation is less important
... For images, when talking about decode and async decode, it gets less clear
... Not just what timing you take, but which frame you take
... Just reading what's in Interop, the number of awesome things is extraordinary!
Bas: Current spec, EventTiming duration says, next time update rendering steps are completed
Michal: This is the discrepancy, the update the render steps has changed over time
... Noam has updated
... Note somewhere that we were monkey patching
Barry: Interop WPTs have been frozen in time
... There's a process if we've added a new one, to get consensus
Michal: If this group collectively, and early made changes for the better, we presumably could make an appeal
Yoav: I agree that scope creep is a problem if we're adding more features, but things that are obvious interop-bug-fixes, assuming an appeal process would get approved
Barry: Process where if we all agree it goes through. It's the implementors. If we don't agree...
Michal: Took a scan at LCP WPT tests, look good for the snapshot
... But the EventTiming spec wasn't updated, and it would help with interop, and with other paint metrics. Hasn't been updated, may want to do that. Less work overall.
Barry: Here's the LCP tests, 3 are not included in Interop
... Labels with Interop

Font-Swap

Yoav: Met up with open-source folks a few weeks back, we talked about fonts and subsetting
... Various font optimizations as part of build processes
... Interesting conversation that turned into an upcoming spec being worked on in WebFonts Working Group
... IFT -> Incremental Font Transfer, allows font-subsetting on the fly
... All these conversations made me realize, if you're defining fonts to be swapped
... Baseline font that's installed on most users' OSs, then you swap into Web Font at some point
... No clean way of measuring when that swap actually happens
... You can measure various bits of text, and layout dimensions and when they're changing
... But no way to determine when font-swap for a font has hit
... As a RUM provider or platform provider, no way to know if you have a font-swap problem
... If you're doing something about fonts, assuming you have a font-swap problem, no way to know if you improved
... Made me think that this is an area where we're oblivious in real world websites
... Not sure if Chrome or other browsers have internal metrics to when font swaps happen
... Would be a great first step
... Interesting to have web-exposed metrics
... Suggested during conversations, if you're preloading that may be good enough, some browsers delay rendering so there's no swap because they assume the font will be there in time that it wont' delay rendering "too much"
... But if I'm applying this optimization, I can know if I improved other things, but not if I know if I've eliminated swaps
Bas: I've been looking internally at our data, we have the download time for the fonts, something already through ResourceTiming API
... Don't have time it takes to interpret fonts and gets it into the page
Yoav: And you don't know necessarily with font loading strategies, some delay rendering then swap, etc
... Lots of moving parts, and you can polyfill a lot of it through magic
Bas: What's the proposed metric?
Carine: How much is this browser-side vs. webpage problem?
... How many have control on whether font-swaps happen?
Yoav: They have CSS properties that give them that control?
Carine: How many use that, and what level of control of the browser's side? Isn't more of a browser issue in how they handle font swaps?
Michal: I was looking into this on influence of layout shifts
... Many ways of expressing fonts, useful use-cases, widely used, many different tradeoffs
... Once you pick a strategy, the site author doesn't have as large of a role as a browser
... One way to measure downside of the wrong font strategy is to measure layout shifts
Yoav: One of the techniques discussed around font optimizations, is to reduce layout shifts
... Find dimensions for fallback fonts to match swap fonts
... Even if you reach minimal or 0 layout shifts, it's still a jarring experience you want to avoid
... User is seeing something and then it changes, it's not great
... Even if we eliminate Layout Shifts entirely, it's not ideal
... Here's a bunch of strategies developers can use to have some control
Barry: I don't think CLS always measures swaps properly, "font-display: swap" was worst thing ever to add
... I think there's a big usage:
…50% of pages use font-display
... 45% of "font-display" usage is "swap"
... How much we can get by measuring is a separate question
Philip: font-swap can also affect LCP, you have no way of knowing if the text block was affected by the swap
Yoav: If the real font was slightly larger than regular font, it could be LCP
Philip: Bunch of different possibilities and it's not possible to know which happened
... With images we have the source, with text nodes we don't
Yoav: Come up with a proposal that measures font swaps, we'd want to know when a swap happened, if it did, which font was involved, what % of fonts
... What other dimensions to expose?
Bas: Theoretical situation where some content using webfont comes in later, and can use it just fine right away. vs. some content comes in w/ root document and it's not ready for that.
... They may need to be separate measurements/events, or a single entry when font came available and which were rendered before and after
Yoav: Second one wasn't a swap at all, just a rendering
Barry: Edge cases which is why LCP gets it wrong. Examples: Lato loading but not Bold. You use Bold, swaps it in. Definition of when a font loads a particular text, is quite complex.
... Rehydration issues, user sees no difference, but is it a later paint, etc
... Would need to be quite well-spec'd
Yoav: Synthesis isn't something I had in mind, but is a thing
... Not just system fonts, but also synthesis from already loaded web fonts
... Theoretically you could have multiple swaps on a single character
Barry: While I agree there is something here that can cause performance issues, and isn’t currently measurable, when I’m struggling with is WHY this matters? What are the use cases after we measure this?
Yoav: For example, we might use it to identify better loading experience for users with less jarring font changes.
Yoav: What I'm hearing is that there seems to be some appetite for this. Not only one thinks this is a missing feature, while at the same time it may not be an easy fit
Bas: My interpretation too
Barry: Good to measure use-cases, it's something changing on the page and we can't measure on the moment.
... What I'm not 100% convinced of is "why"
... Why do we need to measure this, is it user-annoyance? Does CLS not measure it?
Yoav: Agreed we need to cover use-cases, what do people want to measure and what are they going to do with it.
... Shopify has font optimization service, is it doing what we want it to do? Preloads? Something else we can do better?
... I can estimate some things from download sizes, but don't have clear visibility into the user experience there.
... If I want to fund a project internally I need to prove it's a problem
... Maybe everything is OK? Maybe everything is awful and we don't know?
... Action item for me would be to summarize use-cases, share with the group so folks can chime-in