1348405 - Implement Long Animation Frame API

Status: NEW

(Core :: DOM: Performance APIs, enhancement, P3)

Description

[:Harald Kirschner :digitarald]

A new performance API to enable applications to measure responsiveness, by detecting presence of “long tasks” that cause contention on the main thread.

References:

Spec: https://wicg.github.io/longtasks
Explainer: https://github.com/spanicker/longtasks
Tag review link: https://github.com/w3ctag/spec-reviews/issues/150
Chrome's Intent to Ship: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/Mx9q5WXunSE

Comment 1

[:Harald Kirschner :digitarald]

Long Tasks proposals are being migrated from WICG to WebPerf WG

> Long Tasks API was incubated in WICG and the group has been involved from the start: we discussed it at length at TPAC and been iterating on it since, in our calls and via WICG discussions. Chrome is shipping v1 of the API soon. We intend to migrate and continue work on this spec within WebPerf WG.

Comment 2

[Andrew Overholt [:overholt]]

I'm interested in smaug's thoughts here but his queue is closed so I'll ask him by email and report back (leaving needinfo on me).

Comment 3

[Andrew Overholt [:overholt]]

smaug's needinfo queue is open :)

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

What is the current spec for this?
https://w3c.github.io/longtasks/ clearly says "Not Ready For Implementation" and that is from February.

Comment 5

[:Harald Kirschner :digitarald]

(In reply to Olli Pettay [:smaug] from comment #4)
> What is the current spec for this?
> https://w3c.github.io/longtasks/ clearly says "Not Ready For Implementation"
> and that is from February.

Fixed in https://github.com/w3c/longtasks/pull/23

Related a discussion on blink-dev: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/Mx9q5WXunSE

Comment 6

[:Harald Kirschner :digitarald]

ni? overholt for prioritization. v1 is in Chrome since 58. Would it make sense to start with a technical review of the spec if there any blockers?

Comment 7

[Andrew Overholt [:overholt]]

I'll try to get it into our queue for the next few months. Any more info you can share about usefulness would be appreciated.

Comment 8

[Selena Deckelmann :selenamarie :selena]

The Activity Stream team is interested in this.

Comment 9

[:Harald Kirschner :digitarald]

Facebook & LinkedIn both are interested in this.

Related, Soasta/Akamai rolled this out on a few sites and shared tips & first insights in a presentation at Fluent in collaboration with Shubhie from Google

https://cdn.oreillystatic.com/en/assets/1/event/259/Reliably%20measuring%20responsiveness%20in%20the%20wild%20Presentation.pdf (Long Task started at page 22)

This can really help sites to identify the culprits for slow page load and optimize more effectively. This presentation only focuses on page load as it is the easiest to aggregate. I don't agree that Long Task is very interesting for page load as is becomes most important after the page is actually interactive. This API will be even more useful for single page apps, like FB and LinkedIn.

Comment 10

[:Harald Kirschner :digitarald]

Back to :overholt for prioritizing, considering the new input.

Comment 11

[Andrew Overholt [:overholt]]

Thanks! Still P2 as we keep all non-critical-but-important-next-items as P2 but the information is great to facilitate that conversation.

Comment 13

[Shane Caraveo (:mixedpuppy)]

nudge nudge

https://docs.google.com/presentation/d/12_nkYWYYo4zDSK3o0Hmf8YC6upTFoLAQn3bZ1mhbLso

Comment 14

[Peter Hedenskog]

Would love to have this in Firefox too. I think the value in the long task API has been proved by the two new metrics derived from Long Tasks: Total Blocking Time and maxPotentialFirstInputDelay.

However I would also like better attribution so when we get a long task, we can understand what's causing it :)

Comment 15

[Stephen Donner [:stephend] Not actively reading bugmail]

Mass-removing myself from cc; search for 12b9dfe4-ece3-40dc-8d23-60e179f64ac1 or any reasonable part thereof, to mass-delete these notifications (and sorry!)

Comment 17

[Olli Pettay [:smaug][[e-mail]]]

plawless, is this perhaps in perf team's todo list.
Marking this p3 to get this out from the triage list.

Comment 18

[Patricia Lawless]

This is in our backlog. We'll review it again in our next planning session.

Comment 19

[Sean Feng [:sefeng211]]

Given there's a proposal about changing what long task measures, we should wait for that to be finalized before starting the implementation.

Comment 20

[Sean Feng [:sefeng211]]

The above proposal (Long Animation Frame API) has been merged to the spec https://w3c.github.io/longtasks/#sec-loaf-timing . This is the one that we are interested.

Instead of implementing Long Task API, I am rephrasing this bug to only implement that particular part.

I've also filed a spec issue to separate Long Animation Frame out

Comment 21

[Bas Schouten (:bas.schouten)]

Having discussed this with Olli, I believe this is more complicated than it might seem at first. Implementing the spec requires us to clearly annotate tasks by document, which is something we are not currently doing, and would involve quite some work. I'm going to adjust the size estimate, and for the moment, while I really do like this as a feature, I don't think it's feasible to do this for interop 2026.

Comment 22

[Olli Pettay [:smaug][[e-mail]]]

And the HTML spec itself is very much unclear on what is task's document.
See the red warning in https://html.spec.whatwg.org/#implied-event-loop