Re: [JSPreflight] An alternate approach

See comments in line

From: <Podjarny>, Guy <gpodjarn@akamai.com<mailto:gpodjarn@akamai.com>>
Date: Monday, September 9, 2013 4:19 PM
To: "McCall, Mike" <mmccall@akamai.com<mailto:mmccall@akamai.com>>, "public-web-perf@w3.org<mailto:public-web-perf@w3.org>" <public-web-perf@w3.org<mailto:public-web-perf@w3.org>>
Subject: Re: [JSPreflight] An alternate approach
Resent-From: "public-web-perf@w3.org<mailto:public-web-perf@w3.org>" <public-web-perf@w3.org<mailto:public-web-perf@w3.org>>
Resent-Date: Monday, September 9, 2013 4:32 PM

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.

[Alois] Whenever we talk to people the are extremely concerned with additional data; especially when they run the monitoring infrastructure themselves. This is the case for all banks and many eCommerce shops due to legal compliance reasons.  The better the data the more the want to fully control access to it. I have an additional concern with mobile web users. Sending this additional data unfiltered on low-bandwidth mobile connection will seriously impact user experience.


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

[Alois] This makes a lot of sense. However, if only the browser can do this, it does not help analytics solutions which need to register for this event first. I made the proposal to change JSPreflight to have a script that does not block initial page loading but will be loaded and executed before the unbeforeunload event.


  1.  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"?
  2.  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?

[Alois] I think the question should be asked the other way round. What data are analytics tools sending and how can standards help to more efficiently get them.

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



The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Compuware Austria GmbH (registration number FN 91482h) is a company registered in Vienna whose registered office is at 1120 Wien, Austria, Am Euro Platz 2 / Geb?ude G.