Intent to Experiment: Long Animation Frames style/layout duration

[Yoav Weiss (@Shopify)]

Contact emails

yoav...@chromium.org

Explainer

https://github.com/w3c/long-animation-frames/pull/30#issue-3828859369

Specification

https://github.com/w3c/long-animation-frames/pull/30

Summary

Add `styleDuration`, `forcedStyleDuration`, `layoutDuration` and `forcedLayoutDuration` information to the Long Animation Frame API, enabling developers to distinguish style and layout times.

Blink component

Blink>PerformanceAPIs

Web Feature ID

Missing feature

TAG review

Not yet.

TAG review status

Pending

Risks

Interoperability and Compatibility

New attributes, so no compatibility risk. In terms of Interop, this doesn't increase the interop risk of LoAF, which is currently only shipped in Chromium.

Gecko: No signal

WebKit: No signal

Web developers: Shopify developers need the data these attributes expose in order to better understand CSS performance bottlenecks in the wild.

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No.

Goals for experimentation

See if the API provides the right data that enables developers to understand their CSS performance bottlenecks.

Ongoing technical constraints

No.

Debuggability

Not applicable.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes.

Is this feature fully tested by web-platform-tests?

Yes.

Flag name on about://flags

No information provided

Finch feature name

LongAnimationFrameStyleDuration

Non-finch justification

No information provided

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/476826067

Estimated milestones

M147-M152

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5171478175809536?gate=5452953152520192

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSJxRuMp6Ha5RVCjzNfsG0Sj96Y%3Dgy9LnxtM%2Brq-S6DEew%40mail.gmail.com

This intent message was generated by Chrome Platform Status.

[Ian Kilpatrick]

On Fri, Mar 6, 2026 at 8:58 AM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

Contact emails

yoav...@chromium.org

Explainer

https://github.com/w3c/long-animation-frames/pull/30#issue-3828859369

Specification

https://github.com/w3c/long-animation-frames/pull/30

Summary

Add `styleDuration`, `forcedStyleDuration`, `layoutDuration` and `forcedLayoutDuration` information to the Long Animation Frame API, enabling developers to distinguish style and layout times.

Its incorrect to think of style and layout as two separate things now. They can be interleaved. What's the usecase for separating them out? E.g. can the API be simplified as a styleLayoutDuration and forcedStyleLayoutDuration ?

Ian

 

--
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 blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSJ2PJ0dZxYH48PALOSUenSSV7VuZ9CzTHnGd8u_jTKkcg%40mail.gmail.com.

[Ian Kilpatrick]

Ah I see Emilio gave the same feedback here: https://github.com/w3c/long-animation-frames/pull/30#issuecomment-3819162688 can you address this before experimenting?

[Yoav Weiss (@Shopify)]

Having style and layout interleaved doesn't prevent us from accounting for the time each took separately.

[Yoav Weiss (@Shopify)]

On Fri, Mar 6, 2026 at 6:12 PM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

Having style and layout interleaved doesn't prevent us from accounting for the time each took separately.

To expand on that, the implementation accounts for style and layout being potentially interleaved and augments the relevant duration of each accordingly.
 

On Fri, Mar 6, 2026 at 6:04 PM Ian Kilpatrick <ikilp...@chromium.org> wrote:

Ah I see Emilio gave the same feedback here: https://github.com/w3c/long-animation-frames/pull/30#issuecomment-3819162688 can you address this before experimenting?

I can reply, sure.

[Ian Kilpatrick]

On Fri, Mar 6, 2026 at 9:18 AM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

On Fri, Mar 6, 2026 at 6:12 PM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

Having style and layout interleaved doesn't prevent us from accounting for the time each took separately.

To expand on that, the implementation accounts for style and layout being potentially interleaved and augments the relevant duration of each accordingly.
 

Where is the implementation for this?

[Yoav Weiss (@Shopify)]

https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/frame/animation_frame_timing_monitor.cc;l=887?q=render_style_duration_during_layout_&ss=chromium%2Fchromium%2Fsrc

[Ian Kilpatrick]

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

> What's the usecase for separating them out?

Can you expand on the usecase for separating them out? There are many implementation differences here (e.g. where does each engine account for layout-tree construction)? And having them as a unified bucket would mitigate that between implementations.

Ian

[Ian Kilpatrick]

[Yoav Weiss (@Shopify)]

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 <ikilp...@chromium.org> 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?

 

> What's the usecase for separating them out?

Can you expand on the usecase for separating them out? There are many implementation differences here (e.g. where does each engine account for layout-tree construction)? And having them as a unified bucket would mitigate that between implementations.

They are already exposed as a unified bucket:  https://w3c.github.io/long-animation-frames/#dom-performancelonganimationframetiming-styleandlayoutstart

That is not sufficient when trying to gather data from the wild about CSS performance issues and where they are coming from. (and what would solve them)

One concrete example - I'm currently investigating a case where we want to know if reducing the number of spurious rules would help reduce the overall time spent in stylecalc+layout. Currently the only way to find out is to implement that (a significant eng investment), ship it and see if the numbers move.

Splitting out the stylecalc numbers could have helped us know that reducing spurious rules is likely to help.

Ian

https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/frame/animation_frame_timing_monitor.cc;l=887?q=render_style_duration_during_layout_&ss=chromium%2Fchromium%2Fsrc

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Noam Rosenthal]

On Mon, Mar 9, 2026 at 3:37 AM Yoav Weiss (@Shopify)
<yoav...@chromium.org> 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 <ikilp...@chromium.org> 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.