W3C home > Mailing lists > Public > public-web-perf@w3.org > June 2016

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

From: Ilya Grigorik <igrigorik@google.com>
Date: Thu, 16 Jun 2016 23:50:58 +0200
Message-ID: <CADXXVKq7Kco=g2CJoqb7H7_BHCudAgLZhD3EDZgVBqVsOdG4Ug@mail.gmail.com>
To: "Zurmuehl, Martin" <martin.zurmuehl@sap.com>
Cc: "public-web-perf@w3.org" <public-web-perf@w3.org>
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
Received on Thursday, 16 June 2016 21:52:07 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 16 June 2016 21:52:07 UTC