Intent to implement and Ship: unprefixed Resource Timing API (on worker and document context)

[Kenji Baheux]

Contact emails

Engineering ksak...@chromium.org

Spec igri...@chromium.org

PM kenji...@chromium.org

Spec

[1] https://w3c.github.io/resource-timing/#extensions-performance-interface

Summary

This intent is about:

1. implementing and shipping the unprefixed Resource Timing APIs

2. expose only the unprefixed Resource Timing API to Workers.

3. emit a deprecation warning for the prefixed APIs

Only 2 methods and 1 attribute are prefixed.

Usage stats for the prefixed APIs:

• PrefixedPerformanceSetResourceTimingBufferSize: 0.053%

• PrefixedPerformanceClearResourceTimings: 0.654%

• PrefixedPerformanceOnResourceTimingBufferFull: coming soon (with caveats such as inability to detect things like addEventListener([...]))

Motivation

This is to resume a previous intent to ship that was postponed for concerns over exposing prefixed APIs to an extra surface.

Compatibility Risk

Low risk.

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

OWP launch tracking bug

http://crbug.com/465641 (crbug.com/515344)

Link to entry on the feature dashboard

existing Resource Timing API entry:

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

Requesting approval to ship?

Yes.

[Philip Jägenstedt]

LGTM to implement and ship. Do you have a date of removal in mind for the deprecation message or is it a "maybe this will be removed" message?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Chris Harrelson]

LGTM2

[Elliott Sprehn]

I don't think we should ship this API, we should ship PerformanceObserver instead. It fixes many issues with this API and we don't want to have to support both forever.

[Ilya Grigorik]

On Wed, Aug 5, 2015 at 11:03 PM, Elliott Sprehn <esp...@chromium.org> wrote:

I don't think we should ship this API, we should ship PerformanceObserver instead. It fixes many issues with this API and we don't want to have to support both forever.

To clarify, ResourceTiming API *was* shipped back in M31. The only gotcha is that it went out with webkit preferences on two methods:

- performance.webkitClearResourceTimings

- performance.webkitSetResourceTimingBufferSize

This intent is to remove these prefixes and the unnecessary pain & confusion for developers.

With regards to PerformanceObserver: 

- it will surface RT events and we will nudge developers to use it over the buffer model where possible

- observers are not sufficient for all RT cases - e.g. no look-back for monitoring scripts

Based on the discussions in the webperf WG, our plan is to encourage adoption of PerfObservers, but we have no intent to deprecate the buffer model.

ig 

[Elliott Sprehn]

Supporting two different ways to do the same thing is bad for the web (and means complexity in the browser), we shouldnt unprefix the buffer API, we should deprecate and remove it if we plan to ship PerformanceObserver.

The observer API is strictly better, it lets the browser avoid creating records if no one is listening, and also works in a multi actor world.

Unprefixing this API just means itll be much harder to remove later.

[Rick Byers]

What have the other browsers done here, and do we have any measure of the unprefixed API usage in the wild?  If there's already non-trivial adoption for the other browsers, then deprecation may not be practical.

[Kunihiko Sakamoto]

Status of other browsers:

- Firefox 35+ has the unprefixed APIs

- IE (10, 11, Edge) has unprefixed setResourceTimingBufferSize and clearResourceTimings methods, but no onresourcetimingbufferfull event handler

- Safari does not support Resource Timing.

[Rick Byers]

Thanks.  It sounds to me like the issue of deprecation is one for the working group.  Elliott, do you want to discuss it with them on the appropriate public list?  As long as the WG and other browsers intend to keep these APIs, then I personally feel we should unprefix and keep them as well.

[TAMURA, Kent]

Because of no plan to deprecate the buffer model, we should reduce compatibility issues.

LGTM3.

--

TAMURA Kent
Software Engineer, Google

[Kunihiko Sakamoto]

Thanks all. Let me land the change.

Answering Philip's question:

> Do you have a date of removal in mind for the deprecation message or is it a "maybe this will be removed" message?

For now I'm not adding specific date/milestone of removal in the deprecation message.

We will watch the usage stats and decide if/when it's safe to remove (and will send an intent to remove). We can update the message then.

[foo...@google.com]

I'm going through deprecation messages that have no removal milestone, and came across this.

Here are the counters for the things that are now deprecated:

https://www.chromestatus.com/metrics/feature/timeline/popularity/341

https://www.chromestatus.com/metrics/feature/timeline/popularity/342

https://www.chromestatus.com/metrics/feature/timeline/popularity/920

The first two look good, and the last is probably inflated by the fact that it's measuring any access to the onwebkitresourcetimingbufferfull attribute (but not when events are actually fired).

ksakamoto@, looks like attempting a removal of this should be possible now, is that something you're interested in driving?