Open Bug 1348405 Opened 6 years ago Updated 2 months ago

Implement Long Task API (v1)


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




Tracking Status
platform-rel --- +


(Reporter: Harald, Unassigned)




(Keywords: dev-doc-needed, Whiteboard: [platform-rel-Facebook] [webpagetest])

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


Tag review link:
Chrome's Intent to Ship:!topic/blink-dev/Mx9q5WXunSE
Flags: needinfo?(overholt)
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.
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).
smaug's needinfo queue is open :)
Flags: needinfo?(overholt) → needinfo?(bugs)
What is the current spec for this? clearly says "Not Ready For Implementation" and that is from February.
(In reply to Olli Pettay [:smaug] from comment #4)
> What is the current spec for this?
> clearly says "Not Ready For Implementation"
> and that is from February.

Fixed in

Related a discussion on blink-dev:!topic/blink-dev/Mx9q5WXunSE
platform-rel: ? → +
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?
Flags: needinfo?(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.
Flags: needinfo?(overholt)
Priority: -- → P2
The Activity Stream team is interested in this.
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 (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.
Back to :overholt for prioritizing, considering the new input.
Flags: needinfo?(bugs) → needinfo?(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.
Flags: needinfo?(overholt)
See Also: → 1398477
Whiteboard: [platform-rel-Facebook] → [platform-rel-Facebook] [webpagetest]

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 :)

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

Severity: normal → --
Component: DOM: Core & HTML → Performance
Priority: P2 → --

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

Severity: -- → N/A
Flags: needinfo?(plawless)
Priority: -- → P3
Component: Performance → DOM: Performance

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

Flags: needinfo?(plawless)
You need to log in before you can comment on or make changes to this bug.