Intent to Ship: Long Animation Frame Timing

조회수 752회
읽지 않은 첫 메시지로 건너뛰기

Noam Rosenthal

읽지 않음,
2024. 1. 12. 오전 5:31:051월 12일
받는사람 blink-dev

Contact emails

nrose...@chromium.org

Explainer

https://github.com/w3c/longtasks/blob/loaf-explainer/loaf-explainer.md

Specification

https://w3c.github.io/longtasks/

Summary

This is an extension of long tasks. It measures the task together with its subsequent rendering update, adding information such as long running scripts, rendering time, and time spent in forced layout and style ("layout thrashing"). Developers can use this as a diagnostic for "sluggishness", which is measured by INP, by finding the causes for main-thread congestion which is often the cause for bad INP.



Blink component

Blink>PerformanceAPIs

TAG review

https://github.com/w3ctag/design-reviews/issues/911

TAG review status

Issues addressed

Chromium Trial Name

LongAnimationFrameTiming

Link to origin trial feedback summary

https://github.com/w3c/longtasks

Origin Trial documentation link

https://github.com/w3c/longtasks/blob/main/loaf-explainer.md

Risks



Interoperability and Compatibility



Gecko: Positive Not yet a formal signal but showed positive interest at WG call.

WebKit: No signal

Web developers: Positive (https://twitter.com/jebbacca/status/1653355406368952321) Wix, Taboola, and others have already experimented with this in Canary. Strong excitement from several partners at We Love Speed conference.

Other signals:

Ergonomics

It should work well with other performance timeline entries, mainly event-timing/INP.



Security

This feature exposes rendering time to iframes, which might be cross-origin (same-process). This is already observable today, by using requestAnimationFrame. Underwent internal security review. Note that everything in this feature is same-process.



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?

N/A



Debuggability



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

https://wpt.fyi/results/long-animation-frame/tentative?label=experimental&label=master&aligned



Flag name on chrome://flags

LongAnimationFrameTiming

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1392685

Launch bug

https://launch.corp.google.com/launch/4244858

Adoption expectation

The origin trial was a big success, and opted into by both major companies (Wix, Microsoft, Google), smaller companies and several RUM providers.

Adoption plan

Shipping it in stable (with a minor API change that is underway) is already on track for wide adoption due to very positive response to origin trial.

Estimated milestones

Shipping on desktop123
OriginTrial desktop last123
OriginTrial desktop first116
Shipping on Android123
OriginTrial Android last123
OriginTrial Android first116
Shipping on WebView123
OriginTrial webView last123
OriginTrial webView first116
Shipping on WebView123


Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None. The issues raised in the TAG reviewed were previously addressed in the security review of this feature, and need some clarification but not spec changes.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6118675067699200

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJn%3DMYbX%3DEOAwkEvDQY9Ja1trSXLFtM1XNsuw1Lr2QR88%2BTnqw%40mail.gmail.com Intent to Experiment: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJn%3DMYbdL3atq6FvsfrR%3DVs%2Boexvt04zfjV97BNNPL76iPTGLg%40mail.gmail.com
Intent to Extend Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/MClbXXUhOTs
Intent to Ship: https://groups.google.com/a/chromium.org/g/blink-dev/c/MClbXXUhOTs


This intent message was generated by Chrome Platform Status.

Yoav Weiss

읽지 않음,
2024. 1. 12. 오후 11:32:561월 12일
받는사람 Noam Rosenthal, blink-dev
Thanks for working on this important problem! :)

On Fri, Jan 12, 2024 at 11:31 AM Noam Rosenthal <nrose...@chromium.org> wrote:

Can the explainer be updated? e.g. I'm assuming that the "this is a work in progress... lots of things might change" disclaimer is no longer valid.
Beyond that, the script attribution parts are not really explained outside of examples. Is there some developer-facing documentation covering that elsewhere?
For example, it'd be good to cover how code is attributed for async calls, Promises that got resolved, etc.


The link above is broken. I think you meant https://w3c.github.io/longtasks/#sec-PerformanceLongTaskTiming

Regarding the spec, I see that it's monkeypatching WebIDL, DOM and HTML. This feels odd in a WG-adopted spec.
Have you tried to PR these changes upstream?
 


Summary

This is an extension of long tasks. It measures the task together with its subsequent rendering update, adding information such as long running scripts, rendering time, and time spent in forced layout and style ("layout thrashing"). Developers can use this as a diagnostic for "sluggishness", which is measured by INP, by finding the causes for main-thread congestion which is often the cause for bad INP.



Blink component

Blink>PerformanceAPIs

TAG review

https://github.com/w3ctag/design-reviews/issues/911

The discussion seems to still be ongoing..
 


TAG review status

Issues addressed

Chromium Trial Name

LongAnimationFrameTiming

Link to origin trial feedback summary

https://github.com/w3c/longtasks

Origin Trial documentation link

https://github.com/w3c/longtasks/blob/main/loaf-explainer.md

Risks



Interoperability and Compatibility



Gecko: Positive Not yet a formal signal but showed positive interest at WG call.

WebKit: No signal

Can you link to the position requests?
Can you tick the other review boxes on the entry?
 
--
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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJn%3DMYZ9AtHwBuXzz%3D7B7wZyrGqbhv5F%2BYVxDm8Lc6TV2LEkDg%40mail.gmail.com.

Noam Rosenthal

읽지 않음,
2024. 1. 15. 오전 5:32:001월 15일
받는사람 Yoav Weiss, blink-dev
On Sat, Jan 13, 2024 at 4:32 AM Yoav Weiss <yoav...@chromium.org> wrote:
Thanks for working on this important problem! :)

Thanks for reviewing, I realize that the chromestatus entry was erroneous/lacking in a few important bits, let me try to rectify this :)
Updating the chromestatus entry and posting the missing links in the reply. 


On Fri, Jan 12, 2024 at 11:31 AM Noam Rosenthal <nrose...@chromium.org> wrote:

Can the explainer be updated? e.g. I'm assuming that the "this is a work in progress... lots of things might change" disclaimer is no longer valid.

 
Beyond that, the script attribution parts are not really explained outside of examples. Is there some developer-facing documentation covering that elsewhere?
For example, it'd be good to cover how code is attributed for async calls, Promises that got resolved, etc.
There was no slot in chromestatus to add this but this one is much more comprehensive than the explainer.
 

Regarding the spec, I see that it's monkeypatching WebIDL, DOM and HTML. This feels odd in a WG-adopted spec.
Have you tried to PR these changes upstream?

 
 


Summary

This is an extension of long tasks. It measures the task together with its subsequent rendering update, adding information such as long running scripts, rendering time, and time spent in forced layout and style ("layout thrashing"). Developers can use this as a diagnostic for "sluggishness", which is measured by INP, by finding the causes for main-thread congestion which is often the cause for bad INP.



Blink component

Blink>PerformanceAPIs

TAG review

https://github.com/w3ctag/design-reviews/issues/911

The discussion seems to still be ongoing..
Fair, though the discussion rehashes problems that were discussed when we shipped long tasks and didn't introduce new concerns.
I have addressed all the concerns raised but it's up to the reviewer to respond to that. This was 1 month ago. We can also discuss them here or in another forum, or if we want to block until the TAG reviewer is satisfied with all the answers we can do that.

 


TAG review status

Issues addressed 


Chromium Trial Name

LongAnimationFrameTiming

Link to origin trial feedback summary

https://github.com/w3c/longtasks

Origin Trial documentation link

https://github.com/w3c/longtasks/blob/main/loaf-explainer.md

Risks



Interoperability and Compatibility



Gecko: Positive Not yet a formal signal but showed positive interest at WG call.
https://github.com/mozilla/standards-positions/issues/929
(I also corrected the entry to say "No signal", the positive signals were only informal as I stated in the note)
 

WebKit: No signal

Can you link to the position requests?
 
 

Web developers: Positive (https://twitter.com/jebbacca/status/1653355406368952321) Wix, Microsoft, RUMVision and others have already experimented with this in Canary. Strong excitement from several partners at We Love Speed conference.
Not sure I understand what boxes?

It's been 2 months since filing the official position and about a year since we discussed this in WebPerfWG, and we haven't received a formal signal from Gecko/WebKit, only informal (somewhat positive) sentiment. In the meantime the origin trial has been very successful, and the list of things missing in the implementation is pretty close to zero. Happy to proceed in whatever way the API owners see fit.

Noam Rosenthal

읽지 않음,
2024. 1. 15. 오전 5:34:191월 15일
받는사람 Yoav Weiss, blink-dev


Regarding the spec, I see that it's monkeypatching WebIDL, DOM and HTML. This feels odd in a WG-adopted spec.
Have you tried to PR these changes upstream?

Was planning to upstream the monkey-patches once we have formal positive signals from Gecko/WebKit. 

Noam Rosenthal

읽지 않음,
2024. 1. 17. 오전 3:32:561월 17일
받는사람 blink-dev, blink-dev, Yoav Weiss
Updating that Mozilla gave an official positive signal:

Updated the corresponding chromestatus field.

Manuel Rego Casasnovas

읽지 않음,
2024. 1. 17. 오전 6:53:361월 17일
받는사람 Noam Rosenthal, Yoav Weiss, blink-dev


On 15/01/2024 11:31, Noam Rosenthal wrote:
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/6118675067699200
> <https://chromestatus.com/feature/6118675067699200>
>
>
> Can you tick the other review boxes on the entry?
>
> Not sure I understand what boxes?

Yoav refers to the buttons to request other reviews (apart from the API
owners review that happens here).

In "Prepare to ship" section you can find buttons for the following reviews:
* Privacy
* Security
* Enterprise
* Debuggability
* Testing

You should click those to request a review from the different parties.

Cheers,
Rego

Noam Rosenthal

읽지 않음,
2024. 1. 17. 오후 2:02:211월 17일
받는사람 Manuel Rego Casasnovas, Yoav Weiss, blink-dev
Gotcha thanks!
I totally missed those buttons... will file a UI bug on chromestatus, maybe their discoverability can be improved.

Mike Taylor

읽지 않음,
2024. 1. 24. 오전 7:26:131월 24일
받는사람 Noam Rosenthal, blink-dev, Yoav Weiss

LGTM1

--
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.

domenic via Chromestatus

읽지 않음,
2024. 1. 24. 오전 7:31:331월 24일
받는사람 blin...@chromium.org
I found some interesting test failures at https://wpt.fyi/results/long-animation-frame/tentative/loaf-source-location-redirect.html?label=experimental&label=master&aligned . Do they represent anything worth worrying about, e.g. a potential breaking change? Assuming not, LGTM2.

Noam Rosenthal

읽지 않음,
2024. 1. 24. 오전 7:45:351월 24일
받는사람 domenic via Chromestatus, blin...@chromium.org
Oh thanks for pointing it out! This wouldn't be a breaking change, probably a test bug from previous changes, will fix that before shipping of course.

On Wed, Jan 24, 2024 at 12:31 PM domenic via Chromestatus <admin+...@cr-status.appspotmail.com> wrote:
I found some interesting test failures at https://wpt.fyi/results/long-animation-frame/tentative/loaf-source-location-redirect.html?label=experimental&label=master&aligned . Do they represent anything worth worrying about, e.g. a potential breaking change? Assuming not, LGTM2.

--
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.

Yoav Weiss (@Shopify)

읽지 않음,
2024. 1. 24. 오전 8:04:521월 24일
받는사람 Noam Rosenthal, domenic via Chromestatus, blin...@chromium.org
전체답장
작성자에게 답글
전달
새 메시지 0개