WebPerfWG call - May 23rd 2024

Participants

Yoav Weiss, Dan Shappir, Mike Henniger, Alex Christensen, Amiya Gupta, Jase Williams, Noam Helfman, Patrick Meenan, Philip Tellis, Nic Jansma, Benjamin De Kosnik, Dave Hunt, Emilia Juda-Ozbay, Michal Mocny, Sean Feng, Hugh Crail, Barry Pollard, Carine Bournez, Hao Liu, Ian Clelland, JeB Barabanov

Admin

Next meeting: June 6, 2024 at 10am PST / 1pm EST / 7pm CET
TPAC - September 23-27 Anaheim

Tentative schedule - mornings and early afternoons of Monday, Tuesday and Thursday
Remote friendly
Let the W3C Team know ASAP around meetings with other groups

Minutes

Container timing (Jase Williams)

Recording

Jase: Revisit discussion we had (“Element Timing for Containers”)
… Recap first
… Issues raised with ElementTiming and LCP not able to choose something larger like Components
… Affects Bloomberg Terminal
… One of our benchmark functions, we use LCP for our own applications
… Right now LCP candidate is small thing in corner, but we want to use the full table
… We’re thinking of web as being composed of components now
… How do you know when a container is painted?
… Not easy to do, browser isn’t aware of any future updates of text content, XHRs, or images being swapped in
… Things we could do, but shouldn’t:
… Working towards candidate model
… Created a Polyfill after feedback from first meeting, “container-timing”
… Allows monitoring of various containers that you can select
… Can attach a Container Timing to the DOM element
… When Polyfill kicks in, it annotates leaf nodes with ElementTiming
… Subscribe to a PerformanceObserver, listen back for any events
… Aggregate those
… Examples
… This method gives a lot of data to play around with. How do we interpret the data?
… Start with most naive approach, then get more intelligent
… Easiest solution: (demo)
… We get 3 events, for each event we get a render time. New content adding triggered the entries.
… We also had a new element get swapped out triggering ET
… Next solution, demo of polyfill with debug mode
… We have render time, identifier and size
… A bit better than the first one, but misleading
… Can we do better?
… Trying to keep track of all of the elements and the intersection rect, and only trigger and entry if it’s going over new area
… Covering elements and dynamic updates, but no 3rd entry because the bottom cell was already painted
… Size is improved, it increases (similar to LCP) should only get bigger as we take into account larger areas
… We can surface not just visuallyComplete but LCP and FCP
… Nested Containers?
… We took a look at this to see how we could deal with it
… We offer 3 modes in polyfill today
… Ignore ignores entries coming out of inner container
… New paint events won’t bubble up at all
… transparent doesn’t see boundary at all. If LCP in inner container it bubbles up to wrapper.
… You’ll get duplicate
… Shadowed similar to transparent, but the pieces of data around element and size are just scoped to container host, no details on individual elements
… Performance Impact?
… Weren’t expecting to see big changes on overall score
… React Complex DOM test generates 6k elements, there’s a performance penalty (worst case, enabling all elements)
… Memory usage on some of the top websites
… Cap on buffer of entries
… I think reason we don’t see too much change overall is there’s instrumentation already on these elements for e.g. LCP
… Limitations?
… Need to manipulate DOM on Page Load as early as possible, get a MutationObserver running
… Polyfill alone will slowdown rendering
… Have partnership with Igalia, conversations being had
… Think they could deliver a more optimized version
… Ideas e.g. add bitfield if the node has a Container Timing query on it (or if Parent does)
… Before we generate overall DOM and tree we could add markers to elements so they don’t all have to be checked and traversed
… Questions?
Barry: From API shape standpoint, I’m wondering does it make sense to have partial container paints, or are you more interested in if the whole thing has been painted?
… I think it’s a little weird to say this container that I care about is somewhat painted, then more painted, etc. Kind of like LCP where you get a partially-rendered view
… Second question: I like that you put it in one place and it figures out all elements, but it may be interesting to allow picking the specific elements you care about
Jase: For the first question, I think this is going to vary for us. Example was a table of data. For our clients it’s important that it has everything there the client needs. We wouldn’t consider a table ready until it has everything they need, every cell needs to be populated.
… Other web developers for their components need just the Paragraph and other side things can be ignored. Nested components could be an answer for this.
… We’re interested in when knowing the component is fully complete
… If only a half table was loaded, we can look at what happened with the render to debug
Barry: Do you know when it’s ready/complete?
Jase: Never a perfect answer when something is complete, we just work with candidates. If we see a final update and nothing for a while, we’ll just go with that.
… But there could be a long period then another update, maybe we could look at interactions around it
Barry: You could say you need N(=5) elements to make this particular group complete
.. also can we explicitly decorate the subcomponents?
Jase: For the second question, do you want some sort of way to give an exclusion list?
Barry: If you have a carousel, two images + prev + next button, but you just want to know when those two images are drawn
Jase: Something could be done in Polyfill there could be an opt-out list. Say I care about the main image in the carousel but not the two buttons to render.
… We could have it not track certain elements and an opt-in list
Yoav: Regarding Barry’s first point, we can to some extent know when things are done unless further dynamic changes are made. Maybe there’s something to do there? Requires some more thinking.
… For Barry’s second point, if we try to take too much logic into the opt-in, there are things we’ll not cover. Exposing to JavaScript and allowing people to do that in code sounds like a more flexible option. Assuming all of the updates are limited to only certain containers and not the entire document for all the documents. Feels like a more expressive option.
Michal: Thank you for this progress and report.
… Clarify Visually Complete concept.
… You’re using it as a stream of updates that affect the painted impact?
Jase: Discussion on name internally
Michal: Every individual node of the page is waiting to be fully loaded before reporting its own Element Timing
… An image will wait for a certain number of bytes to qualify for loaded
… So when you move up to a container or component, interesting to think what point that component is loaded (it’s made up of parts)
… Also provides dynamic updates and other things, stream of updates
… Today ElementTiming does not provide further updates (but we could)
Benjamin: Question about not caring about specific elements
… What about things like VIDEO or SVG, would this be a way to get LCPs on ElementTiming that are not already reported
Jase: Parallel discussion about that, one of the slides in the first meeting are like that
… SVG has a bug on the Chromium tracker. TABLE could be included. MathML.
… I don’t think they require this specifically to happen to be taken into account.
… Are there some elements out there that could be taken into account for ElementTiming
Benjamin: Seems like an interesting way to extend. Useful functionality.
… Second question: Is there a way to filter a DIV with Container Timing, and it has an ID attribute, where you could do inner/outer with IDs. Use JavaScript to filter?
Jase: Attribute itself, you can do containertiming=
… With identifier, you can filter based on the identifier name
… Single observer listening to any specific one
… What we could do is when you’re doing your observation, you could pass identifier in there, so only that container is spit out at all
Michal: Hit a similar SVG-related issue with these containers in EventTiming and I’m working on exposing targets. In SVGs I’d like to say the container is the target of the event. These types of issues bubbling to the closest container might be helpful.
… For motivations, marking containers even if it regresses the reported performance of Load metrics, you want to measure impact. Is this an opt-in for regressing LCP data? Or do you think that table loads so quickly, yet it’s not being reported as the largest content? And opt-ing in to this container could result in better LCP performance?
Jase: For us it’s the other way around, the title loads faster than the table. If we attribute the load of the table to LCP, that would be a regression. That’s not a bad thing. That’s better than us thinking we’re better than we actually are. We (performance team) want to know when it’s slow before we hear from clients.
… We don’t want table taking 2s because we’re hearing of complaints down the line.
… The opposite of that could happen with other websites, could slow it down, so less incentive there
… Believe it’s good to have real-world numbers on the main content of the application
… I hope implementation of this is fast enough that it’s not degrading performance of LCP
Benjamin: Mozilla does use visually complete, we’d like to have a 75% visually complete manifestation
Yoav: Would love to continue the discussion

Realms Initialization Control (Gal Weizman)

Gal: Want to introduce something on the security impact of things
… Consider if it’s relevant to your world
… Focusing on JavaScript security and client-side security
… One thing we noticed was a “same-origin concern”
… Developing JavaScript security tools, i.e. Akamai and PeremiterX and other scripts that hook/monkey-patch APIs that may be sensitive to security
… e.g. Network / DOM access
… Try to virtualize a security mechanism on top of these
… e.g. hook into fetch() API to determine if some things are trying to leak, stuff at runtime
… Working on this at MetaMask
… We encountered a problem that cancels these efforts
… Even when we apply runtime patches
… Escaping to same-origin realm in browser allows you to access new instances of those APIs that we’re trying to catch
… If we’re trying to patch behavior of fetch(), they create IFRAME and get fetch() from within
… To take this one step forward
… Created a virtualization JS shim that hooks into all of the APIs that allow you to create a same-origin realm, allows you to apply them automatically and recursively
… When someone tries to escape via IFRAME, apply security patch for fetch and applies to that API in the IFRAME
… Virtualizing such a solution security-wise seems to be possible for how parts of the web are defined
… IFRAMEs and load events
… Hard to accomplish this in user-land
… Propose to see if we can get some help from browser to do that
… Performance tools such as Sentry that would be interesting in applying patch APIs or being aware of new IFRAMEs and same-origin realms
… Maybe such tools would be interested in applying these behaviors to new IFRAMEs automatically
… See if anyone is interested in that
… We have a proposal in WICG
… https://github.com/WICG/proposals/issues/144
… Explainer and proposal for how it may integrate into the browser
Nic: very interested in this for several products Akamai is working on
.. for boomerang we wrap a lot of native objects to get info not accessible from the browser
… we do this kind of wrapping but it’s fragile and depends on loading order
… other 3Ps can also try to wrap and break things
… in other cases, we would replace the fetch with a cleaner one we got from a frsh iframe
… we also have bot and security products and coordinating efforts between the different products is also useful
… So some way for a 3P to register these hooks would be good. Needs to make sure it works with multiple different products trying to wrap things all at once
Gal: great to hear. I have conversations with the CameleonX folks so maybe can partner
… allowing patches on top of patches could be simple, as long as you can dictate the order and apply patches in a configurable way
… Most security tools do this in a non-configurable way , but that no longer make sense
… “configurable” - object defined property that allows you to redefine properties on an object, allowing anyone to redefine your property afterwards
… So redefining e.g. fetch in a way that could be redefined afterwards
Philip: I see the use cases for performance and security being slightly different.
… performance would care more about data sent, whereas security cares more about CSP violations
… Maybe there’s another API more similar to CSP reporting that would be a better fit
Gal: The point is not to focus on specific reconfiguration of properties, but to allow to easily redefined properties in realms you don’t have access to. The function you want to redefine is a developer problem.