Intent to Deprecate and remove chrome.loadTimes()

[Shubhie Panicker]

Primary contacts

pani...@chromium.org, philip...@chromium.org

Summary

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.

Motivation

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

• Navigation Timing 2

• nextHopProtocol in Resource Timing & Navigation Timing 2

• Paint Timing API

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: https://bugs.chromium.org/p/chromium/issues/detail?id=334679

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 window.chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=768489

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

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

Entry on the feature dashboard

https://www.chromestatus.com/feature/5637885046816768

Requesting approval to remove too?

Yes.

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]

lgtm1

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK7ODi-sH-g%2BO_pS%3DsaEa3Lch5k0twRUG7qdX_kF_0Q6msjtJg%40mail.gmail.com.

[Dimitri Glazkov]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALjhuieE4HL7_xeL%2BQBzgZA4O0y2HLotoYr3TRBKz9P2sJbhoA%40mail.gmail.com.

[ben.m...@gmail.com]

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.

-b

[nicj...@gmail.com]

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]

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 blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/914894fe-183d-4506-a78b-6d75c5aa5dd0%40chromium.org.

[Shubhie Panicker]

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

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9Z9OM2yjWF4hQ0n62-7kRR%3DO0ePu6fNN9Pf5QcwHw54g%40mail.gmail.com.