New Blind Spot in Performance Monitoring Tools

Web performance tools rely on actual browsers to capture the performance data of a webpage and any requests made by a webpage. Monitoring from the browser, comes with some limitations due to the complexity of the browser and  the internet, causing  at times what we call “Blind Spots”. A “blind spot” occurs when the data provided by a tool lacks clarity.

The main “blind spot” with external monitoring is that you cannot always distinguish between network and application performance. At Catchpoint we introduced Catchpoint Insight and other features to remove this limitation and facilitate the understanding of the performance factors.

Recently we came across another “blind spot” related to monitoring tools built on top of Internet Explorer.  We internally refer to it as “Objects in IE might be faster than they appear”.

It all started when a client of ours engaged us in a performance study regarding the impact of their Iframe tag on the pages of one of their clients. Their client was observing network times on the Iframe call that were quite high on an IE7 based performance monitoring service.  We were able to reproduce the problem on the webpage with various tools like HTTPwatch, DynaTrace Ajax, Webpagetest, IE9 Developer tools, and even in the Catchpoint IE monitor.

The performance numbers we observed made no sense! The response content of the Iframe URL was less than 1000 bytes (it fits in a single TCP packet), yet the tools were displaying 500ms+ for the time from the 1st byte to last byte of the HTTP Content. The only way this could happen is if there was something wrong at the TCP level and packets were fragmented and lost.

To ensure it was not an issue at the TCP level, we utilized Wireshark to capture the TCP packets as we were monitoring the pages with the other tools and mapped the data from Wireshark to the metrics displayed in the tools. The data confirmed that the URL content was delivered always in a single packet and the URL response was less than 100ms.  However, the monitoring tools built on top of IE still showed that 1st to last byte was 500ms or more for the same request! Clearly a new “blind spot” with IE!

Since we proved it was not the network, the only other possibility was that something happened during the browser execution! We looked through the 20+ JavaScript files referenced on the webpage and we determined that the page executed JavaScript code when the DOMContentLoaded event was reached. The event is not native in pre IE9 browsers, and the page relied on one of two solutions: “doScroll()” or “script defer” to approximate when the event has been reached. Once the event was fired, JavaScript on the page made DOM modifications that were time consuming. However, this JavaScript execution time was not being displayed on the tools as gap.

To test what was happening, we created several simple pages that contained an Iframe pointing to URL. The pages also contained a JavaScript that created 10,000 spans and appended them to a DIV on the page. The JavaScript execution would vary on each page and rely on:

1. the “doScroll()” method to detect DOMContentLoaded and execute

2. the “Script Defer” method to detect DOMContentLoaded and execute

3. the native DOMContentLoaded for IE9 to execute the script

4. inline execution below the Iframe tag

In all four test cases we observed that all the tools, including IE9 developer tools, always included the time of the JavaScript execution to the network time of the Iframe request! We replicated the test cases with an image in place of the Iframe, and were unable to reproduce the same results. Interestingly the issue did not occur on Firefox and Chrome on Windows – but both clearly showed there was JavaScript executing and delaying rendering of the Iframe content.

We believe the problem occurs due to the fact that the browser executes JavaScript in a single threaded mode and it takes precedence over the Iframe creation. The monitoring tools are relying on the browser to tell them when the Iframe is complete, but the IE browser does not mark the Iframe complete until the JavaScript execution is complete. Hence, the JavaScript execution time is included in the Iframe response time!

This means that monitoring tools relying on Internet Explorer might append the time to execute JavaScript to the Iframe request time, if the JavaScript executes right after the Iframe request starts. This does not mean that the server serving the Iframe is slow and it does not mean that the Iframe slowed down the page. It simply means the JavaScript time was incorrectly attached to the iframe request. So the next time you see a very slow request in a monitoring tool, try the request standalone to ensure it is the request and not something else on the page.

At Catchpoint we understand such “blind spots” have an impact on our users, therefore we have already started development work to address this issue on our waterfall charts. Our IE based monitor will be able to clearly distinguish between the network request time, and the JavaScript execution time.

– Catchpoint Team