Intent to Implement - ServerTiming

[Charles Vazac]

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/

Summary

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

Motivation

The PerformanceServerTiming interface will allow JavaScript to collect, process, and act on performance metrics written by the server to the Server-Timing header field of the responses of the base page and resources. These timing metrics can provide additional insight into the site's backend performance, enabling analytics and RUM providers to collect and report them.

Interoperability and Compatibility Risk

Interoperability risk is medium-low, as the feature is not yet implemented in other browsers. We’ll be sure to reach out to other vendors before shipping, to avoid them shipping a similar yet incompatible API in the future.

Compatibility risk is low, as this is a new feature and there’s close-to-zero risk of shipping it resulting in content breakage..

Edge: No signals

Firefox: No signals

Safari: No signals

Web developers: Positive (see: https://twitter.com/paul_irish/status/829090506084749312)

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

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

Link to entry on the feature dashboard

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

Requesting approval to ship?

No

[Elliott Sprehn]

This adds a new version of the buffering api (several methods and a new event), this should use PeformanceObserver instead.

[Ilya Grigorik]

On Fri, Mar 17, 2017 at 4:39 PM, Elliott Sprehn <esp...@chromium.org> wrote:

This adds a new version of the buffering api (several methods and a new event), this should use PeformanceObserver instead.

Yep! That draft predates PerformanceObserver... We'll rebase Server Timing on top of PerformanceObserver and remove all the buffer business. :)

[Elliott Sprehn]

On Sat, Mar 18, 2017 at 10:49 AM, Ilya Grigorik <igri...@google.com> wrote:

On Fri, Mar 17, 2017 at 4:39 PM, Elliott Sprehn <esp...@chromium.org> wrote:

This adds a new version of the buffering api (several methods and a new event), this should use PeformanceObserver instead.

Yep! That draft predates PerformanceObserver... We'll rebase Server Timing on top of PerformanceObserver and remove all the buffer business. :)

Awesome! :D

[Charles Vazac]

I'm not sure the pure observer pattern works here. 

We create the timing entry for the base page when reading its response. No observer can yet be registered. 

[Anne van Kesteren]

On Fri, Mar 17, 2017 at 9:34 PM, Charles Vazac <cva...@gmail.com> wrote:
> Spec
> http://wicg.github.io/server-timing/

This seems to use HTTP trailer functionality, but Chrome has thus far
refused to expose that primitive to developers. Shouldn't that be
sorted first? (It's also a little unclear to me what this offers over
service workers and a JavaScript library to interpret the header.)


--
https://annevankesteren.nl/

[Yoav Weiss]

On Sat, Mar 18, 2017 at 3:29 AM Charles Vazac <cva...@gmail.com> wrote:

I'm not sure the pure observer pattern works here. 

We create the timing entry for the base page when reading its response. No observer can yet be registered. 

Yeah, we'd need to find the balance between buffering the entries for the initial response (as well as the first few subresource responses, which would race against observer registration) and using the observer pattern for the rest of the entries.

[Yoav Weiss]

On Sat, Mar 18, 2017 at 7:02 AM Anne van Kesteren <ann...@annevk.nl> wrote:

On Fri, Mar 17, 2017 at 9:34 PM, Charles Vazac <cva...@gmail.com> wrote:
> Spec
> http://wicg.github.io/server-timing/

This seems to use HTTP trailer functionality, but Chrome has thus far
refused to expose that primitive to developers. Shouldn't that be
sorted first?

We have no intention of supporting the trailer functionality here. We need to update the spec in that respect as well.

 

(It's also a little unclear to me what this offers over
service workers and a JavaScript library to interpret the header.)

Standard Server Timing gives us:

* Standard way for analytics providers to collect timing from the origin server as well as third parties.

* Way to expose those timings in devtools.

 

[Anne van Kesteren]

Right, but that's also possible via a library. I thought the idea was
that these days we'd have things proven to be popular through
libraries first before adding them to the platform. The exception
being new primitives of course.

> * Way to expose those timings in devtools.

There's nothing stopping devtools from exposing headers in a certain
way. devtools is not a reason to standardize something.


--
https://annevankesteren.nl/