New Blind Spot in Performance Monitoring Tools
Monitoring from the browser comes with some limitations causing at times what we call “Blind Spots”, which occur when the data provided lacks clarity.
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!
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
– Catchpoint Team