Re: [JSPreflight] An alternate approach

Mike,

I like the core proposal, and have a few thoughts/suggestions:

 1.  Could/Should Browser Hints [1] be used as the way for the server to opt-in to getting the stats?
 2.  I'd be supportive of sending back the whole Performance Timeline, given that the beacon request is async, to avoid the big response header
 3.  One concern Alois voiced in the JSPreflight discussion was tracking pages that didn't complete loading. Perhaps the browser can send a beacon on unload with whatever timing information it has available? Assuming the server opted-in, of course.
 4.  Assuming cookies are also sent with the measurements beacon, this could be useful well beyond measurements, especially if we implement #3. If you agree, maybe we should rename it? Maybe name it something with "Analytics" or "feedback"?
 5.  Continuing the thought in #4, what other metrics do browsers offer that are often collected by Analytics services and are simple browser traits? Perhaps connection type (on Android)? Or device pixel ratio?

Cheers,
Guypo

[1] http://tools.ietf.org/html/draft-nottingham-http-browser-hints-05

--
Guy Podjarny | CTO, Web Experience | guy@akamai.com<mailto:guy@akamai.com> | 613-670-8420

From: <McCall>, Mike <mmccall@akamai.com<mailto:mmccall@akamai.com>>
Date: Monday, September 9, 2013 9:45 AM
To: "public-web-perf@w3.org<mailto:public-web-perf@w3.org>" <public-web-perf@w3.org<mailto:public-web-perf@w3.org>>
Subject: [JSPreflight] An alternate approach
Resent-From: <public-web-perf@w3.org<mailto:public-web-perf@w3.org>>
Resent-Date: Monday, September 9, 2013 9:45 AM

Hi,

Since the JSPreflight spec was announced, there has been some very good,
and heated, debate about its merits.  While I think the idea's heart is in
the right place, I agree with many of Ilya Gregorik's concerns about it -
in particular those regarding security and the effect it may have on
performance.

>From what I've gathered from the spec and subsequent discussion, it seems
there's a desire to collect analytics data without needing to modify the
page's HTML.  With that in mind, I'd like to point out a proposal[1] that
I had drafted during the HTTP 2.0 discussions a year or so ago, as an
alternative or perhaps a complement to the JSPreflight spec.

While it can be refined more for this audience, the crux of idea is that:

- A server and user agent negotiate a set of measurements to collect
- The UA collects the measurements, and sends them back to the server

The semantics of how this is done can and probably should be changed from
their current state.  In particular, the proposal below uses HTTP headers
for much of the heavy lifting, whereas we might be able to refine it to
just have the UA send back the whole Performance Timeline[2], and/or
leverage the Beacon API[3] to send back data.

Thoughts?

Mike

1. http://tools.ietf.org/html/draft-mccall-httpbis-timing-measurements-00
2. http://www.w3.org/TR/performance-timeline/
3. https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/Beacon/Overview.html