We all know how dangerous blind spots are when driving. Before changing lanes or making a turn, you check your mirror and turn your head to ensure there is no car in your blind spot. Make a decision using the mirror alone and you could end up smashing into the car at 7’oclock. Same goes for performance monitoring and blind spots. Make a decision based on your monitoring tool alone without checking your blind spots and you could end up pointing fingers at the wrong person or wasting time trying to solve a problem that isn’t there.

Last year, we blogged about monitoring blind spots with Internet Explorer (IE7+) (Objects in IE Might Be Faster Than They Appear) and cautioned:

• Network monitoring tools at the browser layer don’t show actual network activity – can be impacted by other factors on the page.
• On IE, if a waterfall result shows long iframe network response time, don’t immediately put the fault at the server of the iframe.
• JavaScript execution times can be appended to iframe network response/receive times in IE based monitoring tools.

We recently received feedback from Microsoft on the issue, and decided to write a follow up to the original post.

The Symptoms

We came across the IE issue back in March 2011 when a client of ours approached us with surprising high network times on an iframe tag pointing to a URL, recorded from an IE7 performance monitoring service. The response content of the iframe was < 1k bytes, which fit in a single TCP packet, and yet the receive time (time from first to last byte of the HTTP content) was 500+ ms. This would suggest that the packet was fragmented and/or lost. We replicated the same results using different monitoring tools* as well as IE9 “Developer Tools” Network Tab.

IE9 Developer Toolbar IE9 - DOMContentLoaded

To validate the speed bump was at the TCP protocol level, we utilized Wireshark to capture the packets. We confirmed the URL content was delivered in a single packet in less than 100 ms from when the request was sent (First Byte or Wait time). The network was behaving normally, so somehow IE was reporting something else.

The Tests

We inspected further and discovered that IE started executing JS on the page right after the DOMContentLoaded event was reached (or on pre-IE 9 browsers, an approximation of that event.) We created different test pages under the similar conditions and determined that IE was appending JS execution time to the network time of the iframe request.  Tests on image requests did not yield the same behavior as for the iframes.

The Follow-up

We filed a bug with the Microsoft  engineers for Internet Explorer pointing out the issue. They recently got back to us, confirming both the problem and stating this was expected behavior, and no changes would be made to fix the problem. Here is the information from Microsoft:

“Internet Explorer (IE) executes JavaScript on the same thread the UI is updated on. Consequently IE cannot be executing script and update the UI at the same time. In your example the page is manipulating the DOM by adding new nodes in a loop. At the same time the iframe’s content is being loaded. The DOMContentLoaded event fires before all the content in the iframe has loaded. As the DOMContentLoaded event signals that the DOM is ready for manipulation not that all its content has been fetched. For example images and other binary content might still be downloading. As your example is executing JavaScript in a loop the UI cannot be updated until after the function has returned and JavaScript is no longer executing. At that point you will see the UI update and other events occur such as the completion event for a network download. It’s worth noting that while network requests are downloaded on different threads their events and data are marshaled on to the UI thread. The network inspector reflects what a customer would see if they were to view the page. For monitoring focused exclusively on the network stack a tool like NetMon http://www.microsoft.com/download/en/details.aspx?id=4865 would it be more appropriate.”

There are no plans at this time to change this design aspect of IE but we appreciate your feedback.”

In other words, “Network Capture” in Internet Explorer Developer Tools is not a replacement for traditional network capture tools. The numbers can be impacted under some circumstances by other processes happening in the browser, at the UI thread. Of course this begs the question: “Why call it Network Capture, if it is not actual network data?”

Who Else Suffers?

Any tool capturing network related data on Internet Explorer, at the browser level is impacted by the problem. So far one specific case has been confirmed Iframes tag requests contenting with JavaScript executions that take longer to execute than the load of the iframe request.

Firebug for Firefox did suffer this problem early on, but seems to have solved. We have yet to observe any issuer on it, or hear of any problems.

“Developer Tools” on Chrome 15 and 16 seem have a blind spot. In certain requests that are less than 1k in size, the tool reports “Receiving” times above 0ms. The problem is very visible for 302 redirect response, which traditionally have only HTTP Headers, no Response body. It is unclear what the cause is, and we have yet to file a report with Chromium team.. To replicate the issue take a look at 302 redirect requests in the CNN Homepage:

Redirects on CNN With Slow Receive Time on Chrome 16

 Conclusion

 The network tools provided by the browsers or built by third parties collecting data at the browser layer might not accurately measure request network time in certain conditions. Next time you see absurd times for a request, remember to test the request standalone to confirm the request is actually slow. Lastly, don’t be afraid of running Wireshark when the numbers continue to not make sense.

* HTTPwatch, DynaTrace, Webpagetest, Catchpoint IE monitor

Download It Now