- From: Nic Jansma <nic@nicj.net>
- Date: Tue, 12 May 2026 16:18:06 -0400
- To: Yoav Weiss <yoav.weiss@shopify.com>, public-web-perf <public-web-perf@w3.org>
- Cc: "Jansma, Nic" <njansma@akamai.com>
- Message-ID: <a9f4eef4-82c0-411f-afa4-bb59c054aa04@nicj.net>
Minutes are published at:
https://w3c.github.io/web-performance/meetings/2026/2026-04-09/index.html
Participants
* Nic Jansma, Yoav Weiss, Adrian de la Rosa, Amiya Gupta, Carine
Bournez, Franco Vieira de Souza, Guohui Deng, Luis Flores, Noam
Helfman, Scott Haseley, José Dapena Paz, Robert Liu, Michal Mocny,
Giacomo Zecchini, Bas Schouten, Ryosuke Niwa
Admin
* *Next meeting*: May 7th, 2026
Minutes
Consider exposing LCP duration value relative to
navigation-specific time origin
<https://www.google.com/url?q=https://github.com/w3c/largest-contentful-paint/issues/159&sa=D&source=editors&ust=1778620344066709&usg=AOvVaw1qg8xElzRSuF7yMijgo8UP> -
Michal
* *Michal*: LCP and a few other metrics (FP, FCP, Element Timing) use
the startTime to represent a single time point - the time the paint
happens.
* … duration is currently 0
* … Relative to the time origin of the page
* … We now have prerendering withactivationTime and BFCache restoration
* … So the “visual time origin” is now not necessarily the time origin
* … Scripts are supposed to get those timings from the different
sources (e.g. activation time) and compute their own values
* … Given that the duration is always 0, maybe we could just expose
the duration in a way that we would have if we redid the API?
* … If no one is relying on the duration to be zero, we could expose
it to be relative to the navigation “visual time origin”
* … It impacts SoftNavs as well, which define it differently. Also BG
loaded navigation, pretenders, BFCache
* *Nic*: mPulse doesn’t look at duration for any of these. So you’re
saying that duration would now be relative to the thing that matters?
* *Michal*: yes
* *Nic*: How would we know what the thing that matters is? E.g. Is it
BFCache, prerender, etc?
* *Michal*: That’s the status quo today. You get a paint and it’s your
responsibility to know what are the things that happened on the
page. By default you have large values that don’t correlate with the
user experience. This would give you durations
* *Nic*: startTime is a point in time, duration is a span that you
need to figure out where it started
* *Michal*: startTime will not change. Would equal duration when it’s
a “regular” navigation
* *Amiya*: did you consider adding a new field?
* *Michal*: It would be a good alternative and less risky. But patchy.
So asking if we can leverage the existing attribute.
* *Jose*: duration scares me because in paint events it’s zero, but
other entries have other semantics. Seems risky as tools may
misrepresent it
* *Michal*: Agree it’s weird. Comes down to the fact that in LCP and
other paint timing startTime doesn’t represent a meaningful thing
* *Jose*: Agree that startTime is confusing. A different set of names
would allow better ergonomics in the future
* *Bas*: Violating the invariant of endTime-startTime=duration would
be unfortunate. Let’s just V2 the whole thing. Over years we’d end
up with something more intuitive and easier to use
* *Michal*: Hard to know when to pull the trigger on v2. Can do that
through a new entry type or a parameter
* … Need to expose the activationStart somehow
* *Simon*: Is startTime specified?
* *Michal*: All of these values are specified but there may not be a
single place to update. ActivationStart is probably the most pressing
* *Simon*: As an implementer I need it to be specified
* *Bas*: When we implemented it wasn’t intuitive for us. We did end up
figuring it out
* *Michal*: For BFCache, we talked about BFCache restoration entry.
There’s VisibilityState observer
* … But maybe we can consolidate that as they have similar motivations
* *Bas*: Could having something like this serve to have LCP relative
to the UI event that triggered it, similar to soft navs?
* *Michal*: exposing the raw values more conveniently wouldTODO
* … I’ll update the issue with the discussion, but sounds like no one
really loves the idea of changing duration, but tightening the spec
would be welcome
*
What is the behavior when paints emit from inside the Shadow DOM?
<https://www.google.com/url?q=https://github.com/w3c/largest-contentful-paint/issues/152&sa=D&source=editors&ust=1778620344071671&usg=AOvVaw2gDEddw_H7Ub9W3ww9SyOI> -
Jase / Jose
* *Simon*: From our reading of the spec, we concluded that LCP should
not fire for images in Shadow DOM
* … Ended up implementing it anyway, but then got pushback as shadow
DOM shouldn’t be exposed
* *Michal*: No WPTs is a huge oversight. The Chromium impl does report
paints inside Shadow DOM (open and closed). Events are also
reporting on what’s happening inside shadow roots. But element
references are returned as null, without a direct ref to the element
itself.
* … The paint timing spec implies not to support shadow DOM, but LCP
does imply it
* … Need to update the spec
* *Bas*: Did you happen to check what Firefox does?
* *Simon*: no
* *Jose*: From Element Timing seems like we should expose, but paint
timing spec counters that. Would be interesting to expose a shadow
DOM timeline that would enable the shadow DOM implementers to see
their entries
* … Unclear what would be intuitive for developers
* … There is an algorithm in paint timing. Need to adapt it to deal
with Shadow DOM
* *Michal*: Element Timing doesn’t get exposed for elements inside
Shadow DOM atm. You’re asking about a specific element, so if you
filter the element references, there’s nothing to report.
* … For LCP it’s still useful to know that something happened, even if
you don’t get the element itself
* … RE visibility on shadow DOM, I don’t think they apply to all elements
* *NoamH*: Is that for closed only?
* *Michal*: No distinction at the moment. I think that open should be
exposed. Ryosuke had different opinions
* … For closed shadow DOM there are still ways to understand if paint
happens, so the encapsulation boundaries should not apply
* *NoamH*: What happens when the entire app is a web component?
* *Michal*: You’d get LCP data in Chromium with no attribution. In
Safari you get nothing
* *NoamH*: This is a problem, as it’s somewhat of a pattern
* *Michal*: Does the distinction matter between open and closed?
* *NoamH*: Not really
* *Michal*: The advantage of using open shadow DOM are for style and
layout benefits, but there’s no intention to hide the content inside
that shadow DOM
* *Ryosuke*: Even in the open case you’re not supposed to see it
unless intentional
* *Bas*: Could be a case where the element names conflict. The thing
you added to your shadow DOM conflicts withTODO^[a]
<https://w3c.github.io/web-performance/meetings/2026/2026-04-09/index.html#cmnt1>
* … Firefox exposes LCP but no element ref
* *Michal*: That’s the speced behavior
* … We should clarify this wording in paint-timing
* … Once an image/text elements’ paint is passed to the LCP algorithm,
it’s considered eligible for paint timingTODO^[b]
<https://w3c.github.io/web-performance/meetings/2026/2026-04-09/index.html#cmnt2>
* … However, The default getter for the LCP performance entry is not
to expose element refs for elements inside shadow roots.
* *Bas*: Tend to agree with Ryosule that even open shadow DOM are not
meant to expose things to the outside of the shadow DOM
* *Michal*: In your intuition, would you include only metadata to the
fact that it painted?
* *Bas*: Maybe expose that the container painted? Would complicate the
implementation
* *Michal*: That’s how Event Timing does it. Events bubble up and tell
you “something in the shadow host clicked”
* *Ryosuke*: Makes sense to expose the host, and to Noam’s point that
getBoundingClientRect exposes paints
* … If you start exposing things inside the shadow root, that’s weird
* *Yoav*: Update spec to actually align what Chromium and Firefox are
currently doing which is to expose Shadow host by default. Doesn't
expose, right now it's null, maybe change to expose host.
* … Don't want to expose things inside of Shadow Roots open/closed
w/out their consent
* … Same time, entire apps are just custom elements all the way down
* … Developers have disadvantage for this way of building apps
* … Maybe we can figure out a way for Shadow / Custom Element to opt-in
* … Container Timing will solve this, depends if we're exposing from
inside Shadow tree to global namespace. Some kind of opt-in for
Custom Element to expose timings to global timeline.
* … Don't think we want per-Shadow-Root timeline
* … Effectively reporting that to global and allowing RUM providers to
collect for Custom Elements that want this
* … Single point of collection for all of that information
* *Michal*: Was a proposal in the past for mutationObservers to
include shadow DOM if you have an existing ref
* *Yoav*: RUM providers, same person built custom element may not be
the same as observed it
* *Michal*: Something needs to bubble up, to RUM providers, principled
right now – see the host and summaries of what the boundary is, "the
host painted", "the host interacted with", but if you want deep
insights into host only the component author would want access to that
* *Yoav*: Allow for opt-in?
* *Michal*: Component could with JS API surface to an observer
* … Value-add that comes down the line that we could discuss
* … Agree with all principles so far
* …*Last question*: For a component where you only see the host, for
LCP, there could be many paints inside. Stream of paints.
* … FCP only one event, even in Safari, that fires in boundary
* … Is it OK to report any time a new larger content inside a host
paints? That's what we need for LCP at page-level
* … No insights into what/where, but you get N paints inside host
* *Bas*: I think opt-in should be in host not component itself, as the
host might make certain assumptions of what happens in timeline,
component shouldn't be able to violate.
* … For Michal's point, type of element that would redraw multiple
sizes that you could get multiple LCPs for
* *Michal*: Many requests to support that, depends on the node being
persistent, if you remove and reattach, or rebuild DOM, folks have
asked for this before
* ... One of the examples, is fonts loading, late-loading font-swap.
* … Don't re-fire, layout shift but not new LCP entry
* *Yoav*: Switching source on an image, similarly doesn't fire but should
* *Michal*: In Chromium it does, as src+node is a pair of keys, but
it's an open-spec issue
* *Scott*: Great if we could apply the same principles we do now (per
element) but not exposed, we wouldn't re-emit for every text paint
if it's a redraw, but we would for new text
* … Unfortunate if we only reported once from Shadow host
* *Ryosuke*: Needs consistent with model of how Shadow DOM behaves
* … Media element events shouldn't be exposed to outside world
* … By default that behavior needs to exist
* … Component wants to opt-in to main timeframe, if we had a
mechanism, we need all performance measurements including
ResourceTiming/etc
* … Don't want a new flag for each type of PerformanceObserver
* *Yoav*: RT is currently exposed from Shadow DOM
* … Fetches are exposed in the global timeline
* … Haven't heard of this being a problem
* *Ryosuke*: Consistency
* *Yoav*: RT is exposed but doesn't have attribution that a specific
element triggered a resource
* … Consistency would be on element attribution, would be fine to
expose paints pointing to host, but not what's building the elements
* … Similar for resources, right now they don't have attribution to an
element, would point to a host but not script in Shadow host.
* *Michal*: For Media elements, browser may implement its own UI in
Shadow DOM
* … Is there some sort of internal + closed? We don't want to expose
timings to this
* … Ideally we don't even record these
* … Open Shadow DOM, closed Shadow DOM, plus browser UI
* *Jose*: Was that the same web context in the end?
* *Michal*: For media controls, I would guess it's the same
* … Fruitful, sounds like it's acceptable to make sure not to report
elements except for host, which we're not doing even right now for
Chromium
* … Elements inside of Shadow DOM be considered
* … Reporting times that paints happen, even multiple, in Shadow
Roots, as long as the elements aren't described themselves
* *Ryosuke*: I'm not sure. Media UI applies to other elements. Not
sure everything is considered content by the user
* … Need to continue discussion on that point
* *Yoav*: For browser-owned closed components vs. developer-owned
* … Not because they're contentful or not, it's because developers
don't have control those components compared to open/closed web
components on their site that they can include or exclude
* … Browser components is a black box chosen by the user
* … Can extensions draw web components on top of the context? I'm not
sure
* … Web extensions shouldn't be exposed (e.g. ResourceTiming,
initiated by extensions are excluded)
* … Extensions w/ components, picked by user, site doesn't have any
business knowing that
* *Ryosuke*: Depends, if you control component
* *Yoav*: Information about the host, not inside element
* *Ryosuke*: Whenever Shadow DOM is updated you don't necessarily want
to know about it
* … Parts are relevant for user, parts that are not
* *Yoav*: For LCP, if part getting updated is largest paint in page
(not just Shadow Root). Example I'm thinking of is banner or app is
custom element, in those cases we want to know one thing or a larger
thing was painted
* *Ryosuke*: Not sure you universally want that
* *Yoav*: Examples?
* *Ryosuke*: Page that is just a video, full white video
* … Play will render, is that LCP or not?
* *Michal*: A browser UI play button? Or custom component
* *Ryosuke*: Browser UI
* *Michal*: I don't think we need to describe browser painting
* … But for "custom clock" element it's real content
* … When I ask for video on screen, I'm not asking for play button. I
want to know loading performance of component underneath.
* *Yoav*: And play buttons aren't necessarily going to be larger than
other content being played.
* *Michal*: Will summarize discussion in issue
[a]
<https://w3c.github.io/web-performance/meetings/2026/2026-04-09/index.html#cmnt_ref1>+bschouten@mozilla.com
[b]
<https://w3c.github.io/web-performance/meetings/2026/2026-04-09/index.html#cmnt_ref2>@mmocny@google.com
- Nic
https://nicj.net/
@NicJ
On 4/9/2026 1:48 AM, Yoav Weiss wrote:
> Hey folks!
>
> Apologies for sending this late..
>
> On the agenda
> <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?tab=t.0#heading=h.3wervvuspgea> for
> this week, we have a couple of LCP issues and some updates on the
> speculative load measurement proposal.
>
> Hope to see y'all there
> <https://meet.google.com/agz-fbji-spp?authuser=0>!!
>
> Cheers :)
> Yoav
Received on Tuesday, 12 May 2026 20:18:17 UTC