Monitoring 101 Myth – Javascript Injection is Safe

I was reading an article on the AppDynamics blog recently about the “5 Gotchas for Monitoring Applications in the Cloud” and it got me to thinking about how end user experience is often monitored by various solutions. It often boils down to a debate between passive tapping and server-side agents vs. client-side solutions like desktop agents or Javascript injection. Before I continue, though, let me point out that BMC supports all of those options, so I don’t really have any particular interest in one over the other. However, I do think that Javascript injection is poorly understood and deserves to be brought out into the light a bit more than it has.


I’ve noticed more and more solutions emerging lately that are chasing end user experience by injecting Javascript into the browser. Given the client-heavy nature of modern applications these days, getting some awareness on the client itself is becoming more important (I’ll be posting another blog on this shortly). Javascript is definitely one way to get that client presence. However, it comes with its own baggage and risks, which are often swept under the rug.


In brief, using Javascript to gain client-side awareness is a lot like measuring quantum events by observing them directly – the act of measuring something often alters the thing being measured. This is true of almost every intrusive form of monitoring and Javascript is no exception. In fact, it’s one of the worst offenders.


The fact is that browsers are highly reactive to Javascript. For example, browsers stop all processing of HTML and CSS once they run into any free-floating Javascript (i.e., script code that is not encapsulated within a function). They do this in order to determine whether that script code will alter the HTML and CSS of the content. The size and complexity of the Javascript being evaluated can easily make the problem worse. This is such a serious issue that a new metric called “idle time” was introduced into the lexicon of web monitoring in order to account for the delays in loading time caused by this behaviour.


There is a reason that Javascript developers try to limit the number of browsers and browser versions that they need to support when writing a Javascript-heavy application – they are trying to avoid having to support “cross-browser behavior”. Different browsers process Javascript in their own quirky ways, which is often the result of the on-going arms race between vendors to build the fastest and most standards-compliant Javascript processing engine. In fact, some of these behaviours change from one version to another of the same browser. As an example, Javascript makes heavy use of DOM events as invocation triggers by registering each Javascript function as a “listener” for that event. This can result in having multiple functions using the same event as a trigger. The problem is that browsers will use inconsistent strategies for determining the order of the listeners when invoking them – a real problem if your script depends on the order of invocation. All of these factors drive larger and more complex scripting.  Those that are trying to inject Javascript face the same problems, compounded by the fact that they have to avoid breaking an already complex application by adding new unanticipated scripts into the mix.


Javscript injection is not free. In fact, it is actually one of the most expensive options in the monitoring toolkit. It will change the performance of your UI and runs a serious risk of breaking your application, unless the scripting is incredibly simple. However, in some cases, it might be the only way to get a client-side presence. Consequently, you should only pull that tool out of your toolbox if it is absolutely necessary.

These postings are my own and do not necessarily represent BMC's position, strategies, or opinion.

Share This Post