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