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

103 views
Skip to first unread message

Kenji Baheux

unread,
Aug 5, 2015, 1:14:33 AM8/5/15
to blink-dev

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:



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

unread,
Aug 5, 2015, 7:25:17 AM8/5/15
to Kenji Baheux, blink-dev
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

unread,
Aug 5, 2015, 1:04:43 PM8/5/15
to Philip Jägenstedt, Kenji Baheux, blink-dev
LGTM2

Elliott Sprehn

unread,
Aug 5, 2015, 5:03:17 PM8/5/15
to Philip Jägenstedt, blink-dev, Kenji Baheux

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

unread,
Aug 5, 2015, 6:19:07 PM8/5/15
to Elliott Sprehn, Philip Jägenstedt, blink-dev, Kenji Baheux

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

unread,
Aug 5, 2015, 6:38:35 PM8/5/15
to Ilya Grigorik, blink-dev, Philip Jägenstedt, Kenji Baheux

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

unread,
Aug 5, 2015, 11:11:58 PM8/5/15
to Elliott Sprehn, Ilya Grigorik, blink-dev, Philip Jägenstedt, Kenji Baheux
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

unread,
Aug 6, 2015, 6:14:39 AM8/6/15
to Rick Byers, Elliott Sprehn, Ilya Grigorik, blink-dev, Philip Jägenstedt, Kenji Baheux
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

unread,
Aug 6, 2015, 10:40:09 AM8/6/15
to Kunihiko Sakamoto, Elliott Sprehn, Ilya Grigorik, blink-dev, Philip Jägenstedt, Kenji Baheux
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

unread,
Aug 7, 2015, 3:43:25 AM8/7/15
to Kunihiko Sakamoto, Rick Byers, Elliott Sprehn, Ilya Grigorik, blink-dev, Philip Jägenstedt, Kenji Baheux
Because of no plan to deprecate the buffer model, we should reduce compatibility issues.
LGTM3.

--
TAMURA Kent
Software Engineer, Google


Kunihiko Sakamoto

unread,
Aug 10, 2015, 11:47:55 PM8/10/15
to TAMURA, Kent, Kunihiko Sakamoto, Rick Byers, Elliott Sprehn, Ilya Grigorik, blink-dev, Philip Jägenstedt, Kenji Baheux
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

unread,
Nov 24, 2016, 4:28:23 AM11/24/16
to blink-dev, tk...@chromium.org, ksak...@chromium.org, rby...@chromium.org, esp...@chromium.org, igri...@google.com, phi...@opera.com, kenji...@chromium.org
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:

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?
Reply all
Reply to author
Forward
0 new messages