Hi all! We collected styleDuration, forcedStyleDuration, layoutDuration and forcedLayoutDuration in RUM across Shopify storefronts during the origin trial and compared shops before and after theme upgrades.
The split let us confirm in the field that one CSS selector fix in our Horizon theme (narrowing a body:has(...) ... > * selector and removing several :has() rules) cut style plus forced style time by 40–50% at p75, with layout unchanged, matching our lab results. The combined style-and-layout timing would have shown a drop, but not that it came entirely from style. The split also showed that forced style is our largest styling cost, well ahead of layout, which changed where we focus. We'd like to see the attributes ship. On Wednesday, March 11, 2026 at 4:23:02 PM UTC+1 Alex Russell wrote: > Thanks, Noam. > > LGTM1. > > On Monday, March 9, 2026 at 12:03:32 PM UTC-7 Noam Rosenthal wrote: > >> >> >> On Mon, Mar 9, 2026, 6:53 PM Alex Russell <[email protected]> wrote: >> >>> I would hope that all forced layouts that generate long jank >>> (`getComptuedStyle()` in Noam's example) would generate these events. Is >>> there reason to believe they would/should not? >> >> >> They all do, but there is no distinction between time spent in style vs >> layout computation. This is a problem of missing attribution, the time >> spent in "style and layout" seems like a big opaque purple box that >> developers cannot influence or understand. >> >> >>> Best, >>> >>> Alex >>> >>> On Monday, March 9, 2026 at 5:30:17 AM UTC-7 Noam Rosenthal wrote: >>> >>>> On Mon, Mar 9, 2026 at 3:37 AM Yoav Weiss (@Shopify) >>>> <[email protected]> wrote: >>>> > >>>> > >>>> > >>>> > On Friday, March 6, 2026 at 6:42:41 PM UTC+1 Ian Kilpatrick wrote: >>>> > >>>> > >>>> > >>>> > On Fri, Mar 6, 2026 at 9:38 AM Ian Kilpatrick <[email protected]> >>>> wrote: >>>> > >>>> > Hmm... this is pretty fragile, e.g. you are missing the interleaving >>>> that occurs for anchor-positioning for example. >>>> > >>>> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/css/style_engine.cc;l=3896;drc=4ae3a738cbcbfb87d2bf747e530650484e448361;bpv=1;bpt=1 >>>> >>>> > >>>> > >>>> > Fair. Does that mean that these style and layout calcs are not >>>> accounted for in the current probes? are they accounted from in the >>>> current >>>> LoAF implementation? >>>> >>>> Currently, LoAF cares about two things: >>>> - The "lifecycle" style-and-layout timestamp, which is a well defined >>>> time within the rendering cycle, regardless of whether more >>>> style/layout happens afterwards. >>>> - Forced style and layout, as one bucket, when called from a JS method >>>> that needs a synchronous result that depends on up to date values. >>>> >>>> Where I would draw the line between style and layout depends on >>>> whether the methods would be called for `getComputedStyle()` or only >>>> if a measurement like `offsetLeft` is required. >>>> I don't know what the answer for that when anchor position fallbacks >>>> are used. >>>> >>> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/501f98fe-dee2-4d31-bb04-5d278ac83393n%40chromium.org.
