Nav timings metrics set to 0 on IE11 private instance

Web Performance Discuss Test Results
1

I am running into an issue where IE11 on a private instance in EC2 is having the following nav-timing set to 0:

_loadEventStart: 0,
_loadEventEnd: 0,
_domContentLoadedEventStart: 0,
_domContentLoadedEventEnd: 0,
_browser_name: "Internet Explorer",
_browser_version: "11.0.9600.16428",

This happens for many websites (amazon.com, ebay.com), but not all (for instance, on google.com, I see no such problem in the private instance).

However, in the public instance, I see no such problem. Any ideas on what might have gone wrong?

2

I was finally able to make the public instance (webpagetest.org) come up with an invalid nav-timing.

I found three cases:

  1. San Jose, IE-11: http://www.webpagetest.org/result/140731_XK_1DEC/2/details/
  2. Denver, Colorado, IE-11: http://www.webpagetest.org/result/140731_G8_1DVH/
  3. Dulles, VA, IE-11: http://www.webpagetest.org/result/140731_VY_1EK3/

If you download the HAR file, you’ll see that the nav-timing metrics are all 0. It seems to happen sporadically as I have seen successful IE-11 results from Dulles, VA.

I think this is very closely related to Navigation timings missing from first view (IE 10) · Issue #264 · WPO-Foundation/webpagetest · GitHub but just that it happens even for IE-11.

3

Yeah, I need to take a look at the IE side of the code that collects the post-test DOM metrics to see if there is a race condition or something. I’m pretty sure you’re seeing the same bug.

4

Pat, I think IE isn’t the only culprit. I have a case with Chrome as well – http://www.webpagetest.org/result/140801_1R_15EA/. The nav-timing events are all 0. I managed to get this on Chrome only after changing the connection type to DSL.

I don’t have a proof, but I think the issue is timing – it seems like the request to collectStats (both on IE’s BHO and Chrome’s extension) are being sent too soon. Is it possible that we are asking the extension to dump these metrics even before the actual event is fired (in this case DOMContentLoaded and OnLoad)?

The good thing however is that, I think we have a consistent reproducible case which is to run it with a dial-up connection.

5

That case is expected because the test times out (no onload) and I expect the dial-up cases are very similar.

6

You’re right. This issue is indeed confined to IE. However, the question still remains, I guess. Is it possible that we are sending the request to dump the nav-timings a tad sooner to IE’s BHO. May be that causes the metrics to be returned as 0 as the corresponding events might not even have fired.

7

We’re not sending the request sooner, the same code runs the sequencing in both browsers but there’s a chance that there is something timing related with actually running the in-browser JS code because that’s all browser-specific (and a royal pain to do in IE from C++).

8

I am seeing the same issue on a private instance and with IE 11. It is intermittently reproducible for the sites mlb.com and espn.com.

What is happening on my machine is that for certain sites another BHO is being installed on a second, blank browser window. This occurs shortly before the “collectstats” message is sent, so the BHO attempt to collect stats on the blank window but the window->execScript() call fails. I know this is the 127.0.0.1:8888/blank.html window only by debugging — it is not visible on the agent machine.

A hacky workaround is to not set the global_wpt pointer during install unless global_wpt is NULL. This essentially ignores any BHO install after the first. Since the Wpt destructor already sets global_wpt back to NULL, it will leave everything in a good state to run the next test if all goes well.

However this doesn’t fix the underlying issue that two BHO installs are occurring and I haven’t been able to discover why this is happening.

9

I just pushed a 193 build of wptdriver that prevents double-hooking in case it happens. Not sure that it will solve all of the cases but it’s worth trying.