Intent to Ship: Server Timing

[Vazac, Charles]

Contact emails

Charles Vazac (cva...@gmail.com, cva...@akamai.com)

Yoav Weiss (yo...@yoav.ws, ywe...@akamai.com)

Spec

http://wicg.github.io/server-timing/

Tag review:

https://github.com/w3ctag/design-reviews/issues/188

Summary

Add the PerformanceServerTiming Interface which makes Server-Timing header timing values available to JavaScript running in the browser.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/y3qwr490Fc4/boGoo41-BwAJ

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

Yes

Demo link

https://server-timing.now.sh/

Debuggability

https://gist.github.com/paulirish/a76ac17fc211b019e538c09d8d827691

Interoperability and Compatibility Risk

Compatibility risk is low, as this is a relatively new feature with no incompatible existing deployments. The Blink implementation we intend to ship is compatible with the implementation already exposed in dev tools.

Interoperability risk is medium. We have no clear signals from other vendors regarding their intentions. The spec has been iterated on and we fill that is at a mature stage. A web-platform-tests test suite was upstreamed and should make sure that future implementations are interoperable.

Edge: Low priority

Firefox: No signals

Safari: Positive

Web developers: Positive

Community Signals:

https://gitlab.com/gitlab-org/gitlab-ce/issues/29933

https://twitter.com/paul_irish/status/829090506084749312

https://www.drupal.org/node/2851733

There are already several packages on NPM that help to write Server Timing headers on response:

https://www.npmjs.com/package/node-server-timing

https://www.npmjs.com/package/server-timing

https://www.npmjs.com/package/express-server-timing

https://www.npmjs.com/package/server-timings

https://www.npmjs.com/package/servertime

https://www.npmjs.com/package/servertiming

https://www.npmjs.com/package/express-middleware-server-timing

Blogs about Server Timing:

https://ma.ttias.be/server-timings-chrome-devtools/

https://umaar.com/dev-tips/136-server-timing/

https://www.alsacreations.com/astuce/lire/1726-server-timing-http-console-performance-serveur.html

https://developer.akamai.com/blog/2017/06/07/completing-performance-analysis-server-timing/

Is this feature fully tested by web-platform-tests?

https://github.com/w3c/web-platform-tests/tree/master/server-timing

OWP launch tracking bug

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

Entry on the feature dashboard

https://www.chromestatus.com/features/5695708376072192

.

​

[Philip Jägenstedt]

The TAG review points to these interesting bits:

https://github.com/cvazac/server-timing/blob/gh-pages/explainer.md (should be merged into main repo?)

https://w3c.github.io/server-timing/#privacy-and-security

Overall this all makes sense to me, just a few observations/questions:

For web-platform-tests, I assume they'd currently fail everywhere, but nevertheless I filed an issue about the fact that wpt.fyi doesn't have results for them. Thanks for using wpt, and I also sent a few suggestions for more tests your way!

I looked at the spec's IDL and it doesn't quite match what's in Blink, in particular we won't expose the interface in workers. If that's deliberate, is there an issue tracking that? How about the toJSON bits?

For Firefox I found https://bugzilla.mozilla.org/show_bug.cgi?id=1337684 and poked the bug. Have you had any other discussions with Gecko developers?

--
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/1503339074506.33275%40akamai.com.

[Vazac, Charles]

explainer.md merged:

https://github.com/w3c/server-timing/blob/gh-pages/explainer.md

CR for:

* WPT: entries on the same resource of the same name

* `toJSON` bits

I can easily expose PerformanceServerTiming to workers, but I'm failing to see the value that adds (unless this is just for feature detection from inside a worker). PerformanceResourceTiming isn't exposed to workers either, but you can still get everything you want from the exposed performance object.

We did talk to Mozilla and server timing is on their radar, but it's not super high on their list. 

-Charlie

​

---

From: Philip Jägenstedt <foo...@chromium.org>
Sent: Wednesday, August 23, 2017 7:05 AM
To: Vazac, Charles; blin...@chromium.org
Subject: Re: [blink-dev] Intent to Ship: Server Timing

 

[Ilya Grigorik]

On Thu, Aug 24, 2017 at 11:13 AM, 'Vazac, Charles' via blink-dev <blin...@chromium.org> wrote:

I can easily expose PerformanceServerTiming to workers, but I'm failing to see the value that adds (unless this is just for feature detection from inside a worker). PerformanceResourceTiming isn't exposed to workers either, but you can still get everything you want from the exposed performance object.

ResourceTiming should definitely be exposed to Workers -- if that's not the case, then we have a regression+bug. ServerTiming should similarly be exposed on Worker, to enable ServiceWorkers to collect ST telemetry, etc. 

ig 

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1503598408552.95165%40akamai.com.

[Yoav Weiss]

On Sat, Aug 26, 2017 at 1:39 AM 'Ilya Grigorik' via blink-dev <blin...@chromium.org> wrote:

On Thu, Aug 24, 2017 at 11:13 AM, 'Vazac, Charles' via blink-dev <blin...@chromium.org> wrote:

I can easily expose PerformanceServerTiming to workers, but I'm failing to see the value that adds (unless this is just for feature detection from inside a worker). PerformanceResourceTiming isn't exposed to workers either, but you can still get everything you want from the exposed performance object.

ResourceTiming should definitely be exposed to Workers -- if that's not the case, then we have a regression+bug. ServerTiming should similarly be exposed on Worker, to enable ServiceWorkers to collect ST telemetry, etc. 

`window.performance.getEntriesByType` is exposed to workers and worker code can use that to get ResourceTiming entries and from that, Server Timing entries. At the same time, `PerformanceResourceTiming` is undefined in the context of a worker. 

While exposing `PerformanceResourceTiming` to workers can be valuable for feature detection purposes, I'm not sure there's similar need for ServerTiming (as you can see if it's present on the PerformanceResourceTiming entry).

At the same time, we may want to expose it for consistency.

[Philip Jägenstedt]

Since the base interface PerformanceEntry is exposed to workers in spec and implementation, and PerformanceResourceTiming is  in the spec, it looks like a simple oversight that it isn't exposed to workers in Blink.

PerformanceServerTiming doesn't inherit from anything, but since you can get instances of it in both window and worker contexts, it would make sense to either expose them in both. ([NoInterfaceObject] would also be consistent, but simply exposing interfaces is the usual thing to do.)

Thanks for merging the explaining and poking more at the tests.

LGTM1 with [Exposed=(Window,Worker)].

[Dimitri Glazkov]

LGTM2

--

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/CAARdPYd5Ujynm2qmbUwz-ZVCZtBwzLBFRLSQkuhJ8RZW1L%2B2iA%40mail.gmail.com.

[Rick Byers]

Is this really still blocked on a 3rd LGTM?  If so, I'm very sorry - LGTM3!

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

[Charles Vazac]

Hello all!

This was delayed following the TAG review and spec changes that followed, but it's ready to go out now.

Most notably, the header format changed from:

Server-Timing: metric=123;"description"

to:

Server-Timing: metric; dur=123; desc="description"

Because of that change, dev tools had to be updated as well.

We will be switching the flag from "experimental" to "stable" here.

-Charlie

[Rick Byers]

Thanks for the update Charlie, I'm excited to see this ship!

--
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/d051ea88-807b-493d-87c1-acdec077e9f3%40chromium.org.