Re: [JSPreflight] An alternate approach

On 9/9/13 10:19 AM, "Podjarny, Guy" <gpodjarn@akamai.com> wrote:

>1. Could/Should Browser Hints [1] be used as the way for the server to
>opt-in to getting the stats?

I think Browser Hints could be a great method of getting the server
to opt-in, and its implementation has benefits beyond this spec.

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

I believe the Beacon API addresses some issues with queuing the
transmission of the beacon data. However, thinking about it, are
there cases when we'd want to force a UA to send a beacon earlier?

The original spec outlines a concept of a 'Timing Interval', the intent of
which was to force the browser to package up whatever measurements it had
for a given time since the beginning of the navigation, and send them.
This might be useful in the case of resource timing, in which you could
instruct the server to send back a beacon at a given SLA time - say,
for example, 4 seconds - and determine which resources on a page had
loaded by that time.  Not sure if that's still a useful or desirable
feature.

Mike

Received on Monday, 9 September 2013 20:31:14 UTC