Intent to Deprecate and remove chrome.loadTimes()

741 vues
Accéder directement au premier message non lu

Shubhie Panicker

non lue,
24 oct. 2017, 11:54:0524/10/2017
à blink-dev,

Primary contacts,


chrome.loadTimes() is a non-standardized API that enables collecting loading related metrics to understand performance in the real world. However the metrics there are now available as standardized APIs, so this should now be deprecated and removed.


The metrics within chrome.loadTimes() have replacements that are standardized APIs:

Therefore there is no good reason to keep maintaining this API. Furthermore, removing this API will unblock the following efforts:

a. getting rid of v8::Extensions in chrome:

chrome.loadtimes is implemented as v8 extension, which slows down context startup.

From the bug: “this API currently takes about as long to start as all of V8 together..” --jochen

b. standardize or remove

Note that Usecounter values (% pagevisits) is high, so we plan to do outreach to get developers to switch over to the new standardized APIs before removing this API, therefore the deprecation period is relatively long.

Interoperability and Compatibility Risk

Interop risk: none, no other browser implements this API, this is not a standardized API.

Compat risk: medium. Removing this API will not cause breakage for end users as it a performance measurement API. However this may break analytics for many websites, if they don’t switch over to using standardized APIs.

Alternative implementation suggestion for web developers

All the metrics within chrome.loadTimes have been replaced with standardized APIs.

1. The following metrics are addressed by Navigation Timing 2, shipped in M56 (Intent to Ship link).

requestTime, startLoadTime, commitLoadTime, finishDocumentLoadTime, finishLoadTime, navigationType

2. The following metrics are addressed by nextHopProtocol in Navigation Timing 2, shipped in M61 (Intent to Ship link).

connectionInfo, wasFetchedViaSpdy, wasNpnNegotiated, npnNegotiatedProtocol, wasAlternateProtocolAvailable

3. The following metrics are addressed by PaintTiming API, shipped in M60 (Intent to Ship link).

firstPaintTime, firstPaintAfterLoadTime

Usage information from UseCounter

Link to usage stats

requestTime: 3.39%

startLoadTime: 1.53%

commitLoadTime: 0.02%

finishDocumentLoadTime: 0.02%

finishLoadTime: 0.02%

firstPaintTime: 4.83%

firstPaintAfterLoadTime: 0.08%

navigationType: 0.02%

wasFetchedViaSpdy: 10.61%

wasNpnNegotiated: 8.94%

npnNegotiatedProtocol: 0.52%

wasAlternateProtocolAvailable: 8.94%

connectionInfo: 0.36%

OWP launch tracking bug

Entry on the feature dashboard

Requesting approval to remove too?


Target milestone: Chrome M71, stable release Dec 4, 2018.

We want to provide a long deprecation period due to high usage, it will take some time and effort to drive this down.

We will do developer outreach with /web updates post, contacting maintainers of popular github repos and google3 code (both of which use this API).

A console warning will be added for 7 milestones (M64 to M70).

Jochen Eisinger

non lue,
24 oct. 2017, 11:59:0424/10/2017
à Shubhie Panicker,blink-dev,


You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit

Dimitri Glazkov

non lue,
25 oct. 2017, 11:34:2225/10/2017
à Jochen Eisinger,Shubhie Panicker,blink-dev,

non lue,
25 oct. 2017, 12:14:4525/10/2017
à blink-dev,
Have you guys considered being more aggressive in terms of the removal schedule? The chances of the removal of this API breaking anything are astronomically small. I looked at all the cases where FB uses these APIs and they're all written to assume that chrome.loadTimes may or may not be a function. I'd hope that others would generally follow this pattern as well.

Removing the APIs quickly will likely encourage people to much more rapidly pick up the new APIs which in turn may encourage other vendors to implement them.


non lue,
25 oct. 2017, 13:53:3225/10/2017
à blink-dev,,
The Dec 2018 timeline seems reasonable to me.  That will give us (a third-party analytics provider) time to upgrade the library version our customers are using (which we do one-by-one according to our customer's release schedules) to the PaintTiming API (when available) instead of chrome.loadTimes().

It will also give other consumers of the API, who may not be as in-tuned to the PaintTiming API and chrome.loadTimes deprecation, enough runway to fix their own sites.  I agree with Ben that most developers probably consume the API by validating chrome.loadTimes is a function first, but I want to ensure they have continuity in their metrics in case they haven't added support for PaintTiming yet.

- Nic

Chris Harrelson

non lue,
25 oct. 2017, 14:02:4525/10/2017
à,blink-dev,,Ben Maurer
LGTM3 to deprecate with specific removal milestone specified, but please come back explicitly to blink-dev for approval to finally remove once the stats have been driven down.

Regarding speed of deprecation/removal: the best way to speed it up is for sites (Facebook :) ) to remove all references to the old API. Without more data on all of the uses, it's impossible to say whether there would be site JS errors.

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
To view this discussion on the web visit

Shubhie Panicker

non lue,
25 oct. 2017, 14:41:3025/10/2017
à Chris Harrelson,,blink-dev,,Ben Maurer
Thanks all.
After Ben's comment and looking more into google3 and github code usage, it is more clear that JS errors are unlikely, so this is really about breaking monitoring and continuity if developers haven't switched over, as Nic points out.
Philip is going to do a bunch of outreach to drive down usage, if usage declines faster than expected, we may consider updating Removal deadline (with blink API owners approval of course).

Répondre à tous
Répondre à l'auteur
0 nouveau message