Re: [JSPreflight] - First Draft of JavaScript Preflight Injection online

See comments inline …

From: Chase Douglas <chase@newrelic.com<mailto:chase@newrelic.com>>
Date: Thursday, August 1, 2013 6:28 PM
To: Alois Reitbauer <alois.reitbauer@compuware.com<mailto:alois.reitbauer@compuware.com>>
Cc: "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] - First Draft of JavaScript Preflight Injection online

Hi all,

I've been lurking on the list watching for anything that might be of interest to us here at New Relic. This spec looks really helpful for many of our use cases. A few comments:

* The HTTP setter header is named differently in two locations, once as Set-Preflight-Cookie and once as Set-PreflightCookie

[Alois] Will fix this. This should obviously be the same.

* If the page fails to be loaded, will there be window.document? Would it represent what is shown in the browser, like how chrome dev tools lets you inspect the "Oops! Google Chrome could not find lksjdflsakjdf.com<http://lksjdflsakjdf.com>" page?

[Alois] It would just provide access to the window properties that make sense. Navigation Error logging makes the most sense here for me

* If the page fails to be loaded, how will the preflight script interact with scripts on browser error pages (e.g. the javascript in the Chrome oops page)

[Alois] Do we need this interaction?

* Can there be multiple preflighted scripts? If so, what is the order for them loading?

[Alois] I presume we will need multiple, just as there are multiple analytics tools available today. For simplicity I would not add the complexity of script odering

* I'm assuming scripts are fetched and run synchronously. Should there be a built-in mechanism for async/lazy loading of scripts? This could be worked around by a sync script adding an async script tag to the document, but maybe it would be nice to allow for specifying async scripts more directly.

[Alois] Some scripts rely on being executed first, while for others it is no problem to be executed at different types. Having async support for performance reasons therefore makes sense.

Thanks!

-- Chase

On Mon, Jul 22, 2013 at 2:37 AM, Reitbauer, Alois <Alois.Reitbauer@compuware.com<mailto:Alois.Reitbauer@compuware.com>> wrote:
The first draft of the JavaScript Preflight Injection Specification is available. The goal of this specification is to provide a reliable means for collecting performance data in the browser without affecting page behaviour. You can find the latest version at http://w3c-test.org/webperf/specs/JSPreflightInjection/. Comments and contributions are welcome.

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

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.