Re: [JSPreflight] An alternate approach

Mike,

I remember the presentation you gave a year back on this. I see the point
of having kind of an automatic beaconing back mechanism. For "standard"
data this can be very usable. By standard I mean Navigation Timing etc.
Forcing to send the data asynchronously when the browser unloads the page
also makes a lot of sense. The only concerns that need to be addressed are
how to handle situations when the resource buffer is full and/or the
overall amount becomes rather large.

So for data that is available in the browser this approach can be tweaked
to work I think. How to actually implement it is another topic. Ilya
proposed an approach that follows the concept used for security policy
validation.

The problem I am trying to solve is how can you get additional
instrumentation into a web application that is not covered by standards.
This is true for all analytics tooling. Having some client-executable
logic also helps to reduce traffic. We for example decide on the client
side with resource data we beacon back, based on actual timings. Typically
we end up with a fraction of the overall data.

On 9/9/13 3:45 PM, "McCall, Mike" <mmccall@akamai.com> wrote:

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

Received on Wednesday, 11 September 2013 09:44:07 UTC