Intent to Implement and Ship: exposing User Timing and Resource Timing APIs to Workers, adding workerStart to Resource Timing

[Kenji Baheux]

Contact emails

Engineering ksak...@chromium.org

Spec igri...@chromium.org

PM kenji...@chromium.org

Spec

[1] http://www.w3.org/TR/user-timing/

[2] https://w3c.github.io/resource-timing/

[3] https://w3c.github.io/performance-timeline/

Summary

We are:

1. making the already shipped User Timing and Resource Timing APIs available to Workers (this section in [3]).

2. adding a workerStart to Resource Timing (this section in [2]).

Note: workerStart is also defined in the Navigation Timing V2 spec. Chrome’s existing implementation is based on a V1 spec. This will be for a separate intent to implement & ship discussion.

Motivation

Service Workers can be used to dramatically improve the performance of a web application, esp. loading improvements come to mind. With Push/Notification API and upcoming APIs such as Background Sync, Service Worker will also handle app logic that a developer might want to instrument via the User Timing API.

Adding support for User Timing and Resource Timing APIs to Workers will help developers measure and compare the gains of different designs. The new attribute workerStart is needed to account for lifecyle considerations which didn’t exist with document centric designs.

Compatibility Risk

The first change is about surfacing 2 shipped APIs to Workers: minimal risk.

The second change is about adding one attribute to an existing API surface: 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

crbug.com/465640

crbug.com/465641

crbug.com/465643

Link to entry on the feature dashboard

Existing entries:

• Resource Timing API: https://www.chromestatus.com/feature/5796350423728128

• User Timing API: https://www.chromestatus.com/feature/5066549580791808

Requesting approval to ship?

Yes.

[Boris Zbarsky]

On 6/11/15 9:07 PM, 'Kenji Baheux' via blink-dev wrote:
> adding a workerStart to Resource Timing (this section in [2

> <https://w3c.github.io/resource-timing/#widl-PerformanceResourceTiming-workerStart>]).

I thought this section of the spec was in flux (and that in particular
it's not clear that this attribute will end up being an attribute at all).

Are you also planning to change the zero time of performance.now() in
dedicated workers as part of these changes?

-Boris

[Ilya Grigorik]

On Thu, Jun 11, 2015 at 6:27 PM, Boris Zbarsky <bzba...@mit.edu> wrote:

On 6/11/15 9:07 PM, 'Kenji Baheux' via blink-dev wrote:

    adding a workerStart to Resource Timing (this section in [2
    <https://w3c.github.io/resource-timing/#widl-PerformanceResourceTiming-workerStart>]).

I thought this section of the spec was in flux (and that in particular it's not clear that this attribute will end up being an attribute at all). 

This is a different "workerStart". I know... sorry :)

This intent is to implement and ship the workerStart attribute on PerformanceResourceTiming interface:

http://w3c.github.io/resource-timing/#widl-PerformanceResourceTiming-workerStart

> workerStart of type DOMHighResTimeStamp, readonly

> If the current browsing or worker context's have an active worker ([SERVICE-WORKERS]), 

> this attribute must return the time immediately before the  user agent runs the worker 

> required to service the request, or if the worker is available, the time immediately before

> the user agent fires an event named `fetch` at the active worker. Otherwise, if there is 

> no active worker this attribute must return zero.

This attribute captures the ServiceWorker startup time when such is present.. which, as Kenji pointed out, is not something that was part of the request lifecycle prior to enabling SW.

 

Are you also planning to change the zero time of performance.now() in dedicated workers as part of these changes?

No, this is a separate discussion. As you're well aware, the discussion on public-webperf has now taken a few different turns around this (defining time origin's and a way to convert between time bases), and we need to resolve that first. As a byproduct, it looks like the naming conflict will be addressed as well (bonus! :)) since we're moving away from the earlier attribute proposal.

ig

[Boris Zbarsky]

On 6/11/15 11:07 PM, Ilya Grigorik wrote:
> This is a different "workerStart". I know... sorry :)
>
> This intent is to implement and ship the workerStart attribute
> on PerformanceResourceTiming interface:

Ah, I see. Sorry for the noise!

-Boris

[TAMURA, Kent]

LGTM

--

TAMURA Kent
Software Engineer, Google

[Chris Harrelson]

LGTM2

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

[Philip Rogers]

LGTM3

[Philip Jägenstedt]

Oops...

I think this amounted to shipping prefixed APIs in a new context, namely webkitClearResourceTimings(), webkitSetResourceTimingBufferSize() and the webkitresourcetimingbufferfull event in workers.

I think there are two reasonable options:

1. Remove the APIs from WorkerPerformance.idl and whatever non-IDL bits that the logically go together with.
2. Speedily implement and ship the unprefixed Resource Timing APIs and ship that in all contexts, while deprecating the prefixed APIs.

What do you all think?

Philip

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

[PhistucK]

You mean, 1, or 1 and 2 together, right (never ship the prefixed APIs in Workers)?

☆PhistucK

[Philip Jägenstedt]

Yes, indeed.

[Ilya Grigorik]

Doh, great catch.. +1 for 1+2.

[Philip Jägenstedt]

To take a peek at the next step, are there any open issues around these prefixed APIs in the spec that might get in the way of speedy unprefixing?

[Ilya Grigorik]

On Fri, Jul 10, 2015 at 3:22 PM, Philip Jägenstedt <phi...@opera.com> wrote:

To take a peek at the next step, are there any open issues around these prefixed APIs in the spec that might get in the way of speedy unprefixing?

As in, issues against clearResourceTimings(), setResourceTimingBufferSize(), and resourcetimingbufferfull events? If so, no, I'm not aware of any.

ig

[Philip Jägenstedt]

On Sat, Jul 11, 2015 at 12:41 AM, 'Ilya Grigorik' via blink-dev <blin...@chromium.org> wrote:

On Fri, Jul 10, 2015 at 3:22 PM, Philip Jägenstedt <phi...@opera.com> wrote:

To take a peek at the next step, are there any open issues around these prefixed APIs in the spec that might get in the way of speedy unprefixing?

As in, issues against clearResourceTimings(), setResourceTimingBufferSize(), and resourcetimingbufferfull events? If so, no, I'm not aware of any.

Yes, that is what I mean. Sounds good!

Philip

[kenji...@google.com]

As pointed out by Philip, this would have resulted in exposing some existing prefixed APIs to more surface.

So, we've decided to revert the CL (merged back to M45) and aim for M46.

1. Implement and ship the unprefixed Resource Timing APIs

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

2. Re-enable Peformance APIs for workers, but only unprefixed ones for Resource Timing

=> Offer Resource timing in Workers (blocker: unprefix resource timing API).

Let us know if there are any additional concerns or if we should kick a new intent to implement and ship.

[Kunihiko Sakamoto]

Heads-up: Step 1 (Implement and ship the unprefixed Resource Timing APIs) is done, so I'm going to re-enable performance API for workers, only unprefixed ones this time.

Thanks,

[Kinuko Yasuda]

Yay~!