Loading the formatter is inherently slow, though the browser will cache simple formatters like this for follow up calls. This actually happens here; the second call to broadcastMetricsUpdates is much faster because it's using a cached formatter:
Expected behavior
The extension shouldn't cause long tasks itself.
Unfortunately there's not a way around loading the formatter at least once to get a formatted value. The value would need to either not be formatted, or maybe it could be formatted in the popup (here?), which should happen outside of the page's process.
Describe the bug Formatting metric timestamps with
toLocaleString()can cause a long task in the target page's main thread.To Reproduce
web-vitals.jsinjected by the extension.It's not a long task on my machine, but for example:
(@gilbertococchi who spotted this issue saw a 74ms task)
This points to
getTimestampand its call totoLocaleTimeStringhttps://github.com/GoogleChrome/web-vitals-extension/blob/a938095d13fca49090f58a8186a065b717c6c4cc/src/browser_action/vitals.js#L189-L192
Loading the formatter is inherently slow, though the browser will cache simple formatters like this for follow up calls. This actually happens here; the second call to
broadcastMetricsUpdatesis much faster because it's using a cached formatter:Expected behavior The extension shouldn't cause long tasks itself.
Unfortunately there's not a way around loading the formatter at least once to get a formatted value. The value would need to either not be formatted, or maybe it could be formatted in the popup (here?), which should happen outside of the page's process.
Version: