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

Unfortunately reality is not that easy.

Ad 1)  Advanced analytics and performance management tools require to be loaded first on a page,  as they need to interact with the DOM and also ensure they can inject JavaScript monitoring code into frameworks like jQuery. So for simple page load scenarios I agree, but for complex JavaScript heavy single page apps the story is a different one.

Ad 2) Monitoring code can be inject in two ways a) by manually modifying the page or b) by doing this dynamically at runtime when the page is delivered by the web server. While a is simple it does not work in cases Third Party software is used or pages are created dynamically by frameworks that do not support injection. In these cases the script tag must be injected at the right place in a page to not cause any side effects. The simple case is to do this right after the head tag. In reality there are lots of cases when this does not work that easily. There are cases when a substantial part of the page has to be read to take the decision where to insert monitoring code. As the output has to be buffered this will result in a slow down of the page delivery.

Ad 3) This is about availability monitoring. The frequency of the event is not the question here. Availability monitoring is the top use cases for web ops. If this case was irrelevant why would we then have the Navigation Error spec at all?

Ad 4) This use case is about downloading e.g. a pdf file. There is no document in this case and therefore also no Resource Timing information.

You should trust people who have been in the monitoring business for a long time instead of calling their problems contrived ;-)

// Alois

From: Ilya Grigorik <igrigorik@google.com<mailto:igrigorik@google.com>>
Date: Thursday, August 1, 2013 1:48 AM
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


  *   The monitoring JavaScript becomes a single point of failure for the page if it does not load
  *   Modification of page source can result in unwanted side effects
  *   The monitoring JavaScript will not be loaded when the page cannot be loaded (e.g. because of a DNS error).
  *   It does not allow to collect performance data for non-HTML request (e.g. images, pdf downloads)

The first two seem contrived.. we all know that these scripts should be loaded in an async way, and we have well defined mechanisms to do so. And isn't the last point intentional and handled by ResourceTiming?

Really, it seems like the only new functionality here is point #3, which is error reporting for pages which failed to load? Which is a valid and interesting case, but having said that, do we have any idea or data on how frequently this occurs in the wild? I know this may be a chicken and the egg question, but I'm curious if the extra machinery (and another cookie-like mechanism is pretty heavy), is really warranted.

ig





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.