Blind Spots in Browser Network Capture Tools
The network tools provided by the browsers or 3rd parties might not accurately measure request network time in certain conditions.
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.
We recently received feedback from Microsoft on the issue, and decided to write a follow up to the original post.
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.
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.
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:
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?
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
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