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

On Fri, Jun 17, 2016 at 10:51 AM, Zurmuehl, Martin <martin.zurmuehl@sap.com>
wrote:

> 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).
>

Interesting! Thanks for the pointer.


> 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?
>

I think we could leave this to the discretion of the
server/application/framework, e.g..
- Report metrics to whitelisted IP's (common pattern for development teams
which want to see perf of their site)
- Based on presence of a cookie (e.g. logged in users only; users with
certian privileges, etc)
- Query string opt-in (just as you guys do already)
- If the site is using ServiceWorker it can decorate requests with
arbitrary headers (e.g. Prefer)
- ...

ig




>
>
> On Thu, Jun 16, 2016 at 3:48 PM, Zurmuehl, Martin <martin.zurmuehl@sap.com>
> wrote:
>
> Example:
> > GET /resource HTTP/1.1
> > Host: 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
>