RE: [Server Timing] Proposal how a user-agent can request that a server adds the server-timing header response field

Understood; bundling an opt-in mechanism for server-timing to the existence of observers will not work.

The key questions is: Do we need an opt-in mechanism or do we assume that servers are configured in the future in a way that they attach the server-timing header to each response?
We use for our REST-API’s response header called “sap-statistics” with a meaning very close to “Server-Timing”; no nested traces, just a few metrics values (e.g. see https://help.sap.com/saphelp_nw74/helpdata/en/40/93b81292194d6a926e105c10d5048d/content.htm for one server component, we have a few more). A  query-option or a special header field is used for the opt-in; but I would prefer the preference header solution I have described in my proposal. We collect the data only if they are requested by the client and the client is allowed to see the data (--> security); we want to avoid to waste server resources and  to influence the request processing time and to put unnecessary bytes in the non-compressible header (we are still on http 1.1).
We followed the principal “If no one has asked for it don’t compute it and don’t transfer it”. But to be honest, we haven’t measured so far the influence per request and for the server overall if we would send server-timings all the time.

I’m interested to learn what others think: “Do we need an opt-in mechanism for Server-Timing?”.
If yes, how can we trigger the opt-in from the client?

-- Martin


On Thu, Jun 16, 2016 at 3:48 PM, Zurmuehl, Martin <martin.zurmuehl@sap.com<mailto:martin.zurmuehl@sap.com>> wrote:
Example:
> GET /resource HTTP/1.1
> Host: example.com<http://example.com>
> Prefer: Server-Timing

< HTTP/1.1 200 OK
< Server-Timing: miss, db=53, app=47.2;
< Server-Timing: customView, dc;atl

The prefer header could be automatically set, if an "observer" exists on the client side - e.g. an observer defined in the Java-Script layer or a developer tool in the browser displaying timing data.

That's an interesting idea! A couple of gotchas I see with this:

(1) It doesn't work for the main navigation; there is no observer.
(2) For subresources, in theory you could create an observer before any resource declarations, except.. the preload scanner might race ahead anyway. You'd either need to teach the preload scanner to 'infer' the subscription from the inlined JS (something we'd really like to stay away from), or switch to a declarative mode ala client-hints.
(3) Fetches initiated via Link header have similar problem to (2).

Stepping back though.. Server Timing is intentionally designed to be lightweight (i.e. signal a small number of rolled up metrics, not nested traces), is the opt-in really necessary?

ig