Be careful using Navigation Timing in Firefox
The W3C Navigation Timing API has found its way into most modern browsers. It is also now already party supported in Firefox mobile and fully support on new Windows Mobile Phones. While this is a great step forward it should at the moment still be used with care. We at dynaTrace started using the Navigation Timing API a while ago in our User Experience Management Solution. Just recently we discovered that that the Firefox implementation still seems to not work 100 percent correctly.
Initially we relied on feature detection to figure out whether we can use the Navigation Timing API or not. As we started to see weird results we looked at the data more closely and figured out that some of the timestamps seem to be set incorrectly. Others seems to have to have the same problems as we do. We have also seen problems with fetchStart not being properly set as well.
Obviously the information is not yet reliable enough to use it for monitoring. I am sure that this will be fixed in Firefox soon. However if you are relying on feature detection in your application to figure out whether Navigation Timing is supported you should add code to check whether the values actually make sense.
Hi Alois,
you wrote “you should add code to check whether the values actually make sense.”
Can you share your thoughts/code/tips for this?
Txs!
Aaron
Aaron,
I propose to do two things. First use the classic approach of using JavaScript at the beginning and end of the page and compare these measurements to the Web Timing values. This is pretty old school but it works. We actually now rely on our own timing measurement rather than the Web Timing API in Firefox.
You might now think we use them after all. Well, while some values are wrong you are still able to get some metrics on DNS time etc.
Another way to find out whether values are correct is to compare them against the rules how they should be set. Like in the liked bug report connectStart cannot be 0 for example. While this approach is doable I prefer the first one as it is simpler to implement.
Hi Alois,
old school can be very effective some times.
Will try that, txs!
Aaron
Alois,
you wrote: “Well, while some values are wrong you are still able to get some metrics on DNS time etc.”
Does this mean that in FF7 the values for DNS, connect, etc. are always good?
Aaron,
I most of our tests they are. However I do not fully trust them. I would wait for FF 8. There all the problems should be fixed.
How do you know the problems will be fixed in FF8?
Hi Alois,
for cdnplanet.com, in the GA Site Speed report, I just noticed this:
- for day X, page load times seem normal, except for a couple of measurements. I zoomed in on these and all are FF7. Very, very high numbers, like 30 seconds.
- for day Y, the same pattern but now the browser with the very high page load times is FF8.
- on many other days, I see the same thing: timings for FF browser are extremely high, other browsers are normal.
Note: the page load samples are low.
Do you recognize this?
This is pretty old school but it works. We actually now rely on our own timing measurement rather than the Web Timing API in Firefox. There all the problems should be fixed.
nexium vs prilosec otc