Issue 593476  has been merged into this issue.

Do we have any stats on how often this API is used?  Just wondering how nervous we should be about changing it's semantics from a compat perspective.  I guess if we want to remove the API we should add some usage metrics anyway.

I do think we should understand how often this API is used before we consider removing it.

RE: the first phase change to move to using performance.timing as our data source (https://codereview.chromium.org/2084583002), I'm not sure that this adds risk. chrome.loadTimes().firstPaint has changed a few times over the past year as the implementation that backs it changed. It has improved as the backing impl changed, but it's still not as accurate as the Blink paint timing code. Ilya and others have advocated that we should switch to a timing implementation that we trust, so developers are getting accurate data from this API.

RE: the other proposed changes, I spot checked on a handful of pages and the timings don't meaningfully change. They are either identical or change by a few milliseconds. The exception is requestStart, which currently reports zero or sometimes totally erroneous values. With the proposed patch, requestStart will at least report a consistently sane value.

All that said I'm open to instrumenting usage before making this change if you think it's needed. But my sense is the risk is low & it's better for us to update these APIs to report timing data we trust as a first step.

Wonder if UseCounters might be helpful in understanding usage?

Agree they'd be useful to help us decide how to deprecate the API. I'm advocating that we update the API first to use timing data we trust, without blocking on collecting use counter data, though. Proposed flow:
1. update existing timings to report data we trust that's based on the standardized navigation timing API data (see previously linked CL)
2. add usecounters, roll them out to stable, understand usage
3. put together a plan for deprecating chrome.loadTimes() APIs, drawing on the data collected from use counters

Ilya and Paul, what are your thoughts on this? Can we / should we update chrome.loadTimes() to report data we trust now (e.g. trusted first paint, rather than the current impl that's not trusted or maintained, and that has changed at various points over the past year)? Or do we need to add use counters and wait for them to roll out before making any changes to the timings we are reporting?

As an additional bit of info to help guide our decision, I looked into how developers are using some of the other timings reported from this API. There are various code snippets on github where developers are incorrectly using chrome.loadTimes().startLoadTime as the time the navigation started. This API currently reports the time a provisional load is first processed in the render process, which for browser-initiated navigations is different from navigation start. In looking at code snippets, no developers using startLoadTime are using it properly; they're all incorrectly using it as navigation start time. I believe we should update this API to report the time that it's being used for (navigation start time), drawing from the trusted/supported timings that come from the navigation timing API.

> Ilya and Paul, what are your thoughts on this? Can we / should we update chrome.loadTimes() to report data we trust now (e.g. trusted first paint, rather than the current impl that's not trusted or maintained, and that has changed at various points over the past year)? Or do we need to add use counters and wait for them to roll out before making any changes to the timings we are reporting?

Given your earlier comment, which points out that the underlying implementation has changed a few times already over the past year, I don't think we should block making this change to make it more accurate and aligned with other perf API's. 

Current high level plan:

1. update chrome.loadTimes() to use a timing source we trust (nav timing)
2. better understand how often these APIs are used in the wild and whether/why developers are still using them
3. expose first paint via a standardized API, so all information from chrome.loadTimes() is available via standardized APIs
4. migrate any developers using this API away from chrome.loadTimes()
5. eventually, turn chrome.loadTimes() down

As part of 4, maybe the same hack that is used for document.all can be used here -
if (document.all) // false here
if (typeof document.all === "undefined") // false here

Hopefully, the usage would be very low that it can just be outright removed.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7b1c45eea8eda457180d981fd077cc1042680844

commit 7b1c45eea8eda457180d981fd077cc1042680844
Author: bmcquade <bmcquade@chromium.org>
Date: Thu Jun 30 16:06:44 2016

Add loading metrics owner entry for loadtimes_extension_bindings

BUG=621512

Review-Url: https://codereview.chromium.org/2106793002
Cr-Commit-Position: refs/heads/master@{#403189}

[modify] https://crrev.com/7b1c45eea8eda457180d981fd077cc1042680844/chrome/renderer/OWNERS

Summarizing the proposed changes to chrome.loadTimes() for step 1:

1. switch timing source from deprecated DocumentState, to supported WebPerformance

2. per suggestion from pmeenan, report a value of 0 for firstPaintAfterLoadTime, since this metric is not useful and may cause developers to draw misleading conclusions. firstPaintAfterLoadTime was added as a hacky workaround when firstPaintTime didn't report meaningful data, but didn't report useful data for most pages then and isn't useful now. now that firstPaintTime is accurate (and has been reasonably so for a while), developers should focus on that metric and not use firstPaintAfterLoadTime. I can't find any devs that are actively using firstPaintAfterLoadTime and I find evidence that devs are already moving away from depending on it, see e.g. https://gerrit.wikimedia.org/r/#/c/181006/ "Don't log Chrome's firstPaintAfterLoadTime, which has no analog in other browsers, and is therefore less useful than firstPaintTime."

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0d38f4e0ac28e2af5feec1fe93085037f9eb8d45

commit 0d38f4e0ac28e2af5feec1fe93085037f9eb8d45
Author: bmcquade <bmcquade@chromium.org>
Date: Sat Jul 02 00:04:29 2016

Update chrome.loadTimes() to use timings from WebPerformance.

Update chrome.loadTimes() to use timings from WebPerformance, which backs the
standardized navigation timing API, instead of the deprecated DocumentState
timings.

BUG=621512

Review-Url: https://codereview.chromium.org/2084583002
Cr-Commit-Position: refs/heads/master@{#403570}

[modify] https://crrev.com/0d38f4e0ac28e2af5feec1fe93085037f9eb8d45/chrome/renderer/loadtimes_extension_bindings.cc

Shubhie, now that the first change has landed, I'll reassign this to you to drive the next steps. Feel free to set up time to VC if you'd like to discuss further. Thanks!

Sure, I'm adding the UseCounter next.

QQ: I noticed that UseCounter is not there in Webkit/public interfaces:
https://cs.chromium.org/chromium/src/third_party/WebKit/public/web/

Should it be added here so it can be included and referenced in: chrome/renderer/loadtimes_extension_bindings.cc
?

Just to let you know.

We use chrome.loadTimes().firstPaintTime a lot.

I am attaching a image of our RUM. It proves the benefits in the "first paint time" when we delivered the index with flush early. Sept 2015

Best

Deleted: Screen Shot 2016-07-12 at 15.07.50.png 47.7 KB

	Screen Shot 2016-07-12 at 15.07.50.png 47.7 KB View Download

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/99807eeee0d8426d239376d716cacba2a84cfddf

commit 99807eeee0d8426d239376d716cacba2a84cfddf
Author: panicker <panicker@chromium.org>
Date: Wed Jul 27 20:24:18 2016

Pre-req for adding usage counter to chrome.loadtimes:
Switch to SetAccessor, this adds a Getter where the Usage counter will be added subsequently.

A side effect of SetAccessor is that it subtly changes the  behavior: previously loadtimes data fields were mutable and persisted modifications that updated the value programmatically (from javascript).
With this change, such modifications will not be persisted.
We think this is fine -- as we cannot think of scenarios where it makes sense to modify the values returned by chrome.loadtimes. Moreover this is a necessary step to get usage counts and move the deprecation further.

BUG=621512

Review-Url: https://codereview.chromium.org/2149933003
Cr-Commit-Position: refs/heads/master@{#408226}

[modify] https://crrev.com/99807eeee0d8426d239376d716cacba2a84cfddf/chrome/renderer/loadtimes_extension_bindings.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3fcbfceb613b77295f543c55a9147b3343986571

commit 3fcbfceb613b77295f543c55a9147b3343986571
Author: panicker <panicker@chromium.org>
Date: Mon Aug 08 20:20:09 2016

Add use counter for chrome.loadTimes

BUG=621512

Review-Url: https://codereview.chromium.org/2222573003
Cr-Commit-Position: refs/heads/master@{#410427}

[modify] https://crrev.com/3fcbfceb613b77295f543c55a9147b3343986571/chrome/renderer/loadtimes_extension_bindings.cc
[modify] https://crrev.com/3fcbfceb613b77295f543c55a9147b3343986571/third_party/WebKit/Source/core/frame/UseCounter.h
[modify] https://crrev.com/3fcbfceb613b77295f543c55a9147b3343986571/third_party/WebKit/Source/web/WebLocalFrameImpl.cpp
[modify] https://crrev.com/3fcbfceb613b77295f543c55a9147b3343986571/third_party/WebKit/Source/web/WebLocalFrameImpl.h
[modify] https://crrev.com/3fcbfceb613b77295f543c55a9147b3343986571/third_party/WebKit/public/web/WebLocalFrame.h
[modify] https://crrev.com/3fcbfceb613b77295f543c55a9147b3343986571/tools/metrics/histograms/histograms.xml

- The UseCounter numbers are very low (way lower than the requisite 0.03%)
https://docs.google.com/spreadsheets/d/1zdEcRFhAggjS7HyNIWbaaawVvPclQvPFZ8mcmns47No/edit#gid=0

- Relatively speaking, the most used metrics are: firstPaintTime, requestTime, wasFetchedViaSpeedy
Followed by:  wasNpnNegotiated, wasAlternateProtocolAvailable, startLoadTime
Everything else is very negligible.

Next steps:
- continue standardizing firstPaint 
proposal is here: https://github.com/w3c/navigation-timing/issues/45
- expose nextHopProtocol: https://bugs.chromium.org/p/chromium/issues/detail?id=454818
- add console warning
- move forward with Intent to Deprecate and blog post announcing deprecation etc.

When looking at UseCounters for a metric that hasn't hit stable yet, be
sure to compare only against PageVisits values from builds that have the
counter supported (eg. Restrict the query to a particular chrome version
string).

Thanks for the pointer!
As Rick mentioned the data link I posted is off base because I compared against stable. I will loop back with correct data once the change hits stable, and we can move forward based on that data.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a2b3e8c87b3f3372fc50ebd8a5e249995d1402ea

commit a2b3e8c87b3f3372fc50ebd8a5e249995d1402ea
Author: bmcquade <bmcquade@chromium.org>
Date: Tue Nov 01 16:35:14 2016

Switch chrome.csi() to use times from WebPerformance.

This is a follow on change to https://codereview.chromium.org/2084583002
which converted chrome.loadTimes() to use WebPerformance-based timings.

The current chrome.csi() implementation uses the unsupported
DocumentState-based metrics. startE, which is derived from
DocumentState.request_time, has sometimes been reporting invalid
values for the last 12 months due to crbug.com/615781. This change
moves us to using data from a trusted/maintained/accurate data source.

This change will also allow us to remove a few timing fields from
DocumentState as part of a subsequent change.

BUG=621512

Review-Url: https://codereview.chromium.org/2456293003
Cr-Commit-Position: refs/heads/master@{#429018}

[modify] https://crrev.com/a2b3e8c87b3f3372fc50ebd8a5e249995d1402ea/chrome/renderer/loadtimes_extension_bindings.cc

I assume this bug also tracks removing chrome.csi, right?  csi and loadTimes are the only properties I see on 'chrome' on Android.  Perhaps we can remove window.chrome entirely after that?

Filed issue 665273 to track webexposed test coverage for these properties.

it's been a while now that we started looking into this again. Have we come to a conclusion whether to remove or keep the API?

If we want to keep the API, can we please refactor it to stop using the v8::Extension API?

tl;dr: the plan is to remove the API.

The current plan:
- for the low usage fields here: add deprecation warning and send out an Intent to Deprecate
- for the other fields: wait until we ship First Paint and nextHopProtocol in RT (the alternatives). Then look at HTTP Archive / drive migration. And then deprecate (if all goes well).

The use-counter data is here:
https://docs.google.com/spreadsheets/d/1eHVwAZSAjTLCO5UovtaTyWJwcBezls3UMrkBjHhbXMY/edit#gid=0

Discussion on this is here (corp list):
https://groups.google.com/a/google.com/forum/#!forum/chrome-web-perf-apis

some of those metrics are still pretty high :/

Note that this API currently takes about as long to start as all of V8 together..

Issue 113048 has been merged into this issue.

Per #25 and #26 I got the impression that chrome.csi was also included in the plan. Let us know otherwise.

And by #26, I meant #27.

I'd prefer to track chrome.csi separately, as I have a concrete plan for chrome.loadtimes, but no concrete plan yet for chrome.csi (the usecounter values haven't been evaluated)

We'll ship usage of this in AMP. Will remove immediately when standards based support is ready.

(Re-posting, as my comment using the @gmail.com account got automatically deleted)
#34 - this will delay deprecation and removal. Please, do not do that.

What is this blocked on at this point?

We need to wait for 2 milestones after shipping nextHopProtocol (M61)

Let's look at this after the M63 branch then.

The NextAction date has arrived: 2017-10-16

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/51c59d08eff5aade45c731f0d5a42802d6c02517

commit 51c59d08eff5aade45c731f0d5a42802d6c02517
Author: Shubhie Panicker <panicker@chromium.org>
Date: Sat Oct 28 04:02:22 2017

Add deprecation message for chrome.loadTimes()

Add console warning for chrome.loadTimes() in preparation for deprecation.
Link to Intent thread:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/QqvFGFgoTyI/fVfkld6HBgAJ

Bug: 621512
Change-Id: I527652aea3eaf5bb7f58fe3d67d80a8be34a8108
Reviewed-on: https://chromium-review.googlesource.com/719405
Reviewed-by: Nate Chapin <japhet@chromium.org>
Cr-Commit-Position: refs/heads/master@{#512380}
[modify] https://crrev.com/51c59d08eff5aade45c731f0d5a42802d6c02517/third_party/WebKit/Source/core/frame/Deprecation.cpp
[modify] https://crrev.com/51c59d08eff5aade45c731f0d5a42802d6c02517/third_party/WebKit/Source/core/frame/WebLocalFrameImpl.cpp

Hi panicker,
On ToT [d1054682ea0b2d1ff303f10a06a5eea374a2b532] on macOS, every time the NTP is loaded, this message is spammed several times.

"""
[97052:775:1115/110819.817557:WARNING:CONSOLE(233)] "chrome.loadTimes() is deprecated, instead use standardized API: nextHopProtocol in Navigation Timing 2. https://www.chromestatus.com/features/5637885046816768.", source: https://www.google.com/xjs/_/js/k=xjs.ntp.en_US.It0Ep9hLQM0.O/m=sx,jsa,ntp,d,csi/am=AAHEAQ/rt=j/d=1/t=zcms/rs=ACT90oGUZcHMNyNgxXJggB8iuPencubKbQ (233)
[97052:46339:1115/110819.817825:ERROR:service_manager.cc(158)] Connection InterfaceProviderSpec prevented service: content_renderer from binding interface: blink::mojom::ReportingServiceProxy exposed by: content_browser
[97052:775:1115/110819.818608:WARNING:CONSOLE(233)] "chrome.loadTimes() is deprecated, instead use standardized API: nextHopProtocol in Navigation Timing 2. https://www.chromestatus.com/features/5637885046816768.", source: https://www.google.com/xjs/_/js/k=xjs.ntp.en_US.It0Ep9hLQM0.O/m=sx,jsa,ntp,d,csi/am=AAHEAQ/rt=j/d=1/t=zcms/rs=ACT90oGUZcHMNyNgxXJggB8iuPencubKbQ (233)
"""

can you follow up?

I believe this is coming from GWS's usage of the now deprecated API, I've reached out to samarth@ 

Just came across the deprecation message but noticed the patch landed in #42 isn't using the standard 'replacedWillBeRemoved' API. The console message does not indicate the date/milestone when the feature will be removed.

Re: #43 ndsouza@google.com is working on a fix.

Ping - this bug had no updates for >100 days.

Just use Google Gmail in Google Chrome: Read some new message in the received mails, then get back to the list of messages.

These deprecation warnings are constantly emitted. Visible Gmail does not even honor the deprecation you seem to request.

I don't know what would happen to Gmail if this API is removed early from Chrome. I bet that people won't even be able to read their mails with Chrome and will have to use another browser not based on the same implementation version of this Javascript API !

#48 - I would not be worried about GMail. 1. I tried the new GMail and could not spot any deprecation message. 2. This API is used for analytics, anyway, so I would expect it to only "ruin" analytical code paths, which usually do not interrupt the main functionality anyway. Even if it does, see 1 - it does not use it anymore and it would be the default at some point.

#48, #49
I am also receiving the deprecation message in console while on Gmail although they're from a G Suite App for Business integration with our CMS, not Chrome/Gmail itself.
Pretty silly to think a deprecated load times API would break an entire browser/service.

I'm removing the last few comments as they are unrelated to this bug.

Update:
Several usecounters are still too high:
ChromeLoadTimesRequestTime	0.4442286422
ChromeLoadTimesStartLoadTime	0.6289887096
ChromeLoadTimesCommitLoadTime	0.01606764009
ChromeLoadTimesFinishDocumentLoadTime	0.01608917059
ChromeLoadTimesFinishLoadTime	0.01608980681
ChromeLoadTimesFirstPaintTime	2.132931455
ChromeLoadTimesFirstPaintAfterLoadTime	0.09075620567
ChromeLoadTimesNavigationType	0.01608252768
ChromeLoadTimesWasFetchedViaSpdy	2.983173119
ChromeLoadTimesWasNpnNegotiated	0.5771912651
ChromeLoadTimesNpnNegotiatedProtocol	0.4594993527
ChromeLoadTimesWasAlternateProtocolAvailable	0.5767884113
ChromeLoadTimesConnectionInfo	0.5585715671

I think we could remove the following:
ChromeLoadTimesCommitLoadTime	0.01606764009
ChromeLoadTimesFinishDocumentLoadTime	0.01608917059
ChromeLoadTimesFinishLoadTime	0.01608980681
ChromeLoadTimesFirstPaintAfterLoadTime	0.09075620567
ChromeLoadTimesNavigationType	0.01608252768