I took a crack at a plugin that pulls all the data out of the Navigation Timing API (window.performance.navigation / window.performance.timing) and adds them to the beacon.
This adds a number of metrics like DNS/connect/ssl/FB times, load and unload event times, DOM loading/interactive/complete, and others to the mix.
Let me know if there's anything I can do to make it better..
Add a plugin to collect data from the W3C Navigation Timing API, for …
…user agents that support it.
May be better if we put the done() method inside the impl object, then it's not callable from outside the plugin. Will leave it to you to decide on this
you can actually call addVar with an object (key/value pairs) that will make this entire section of code much smaller and easier to read.
you'll also want to do browser specific prefixes like webkitPerformance, msPerformance and mozPerformance. Also check if the google toolbar adds this object to other browsers.
Looks good. I've added a few line notes for you to fix before I merge this in, but it's on the right track.
Also, add some documentation in the doc subfolder.
Thanks for the feedback. I'll revise and update the branch.
Implement feedback from bluesmoon. Check (moz|webkit|ms)Performance t…
…o get older Navigation Timing implementations. Use one BOOMR.addVar(obj) style in favor of multiple addVar(name, val) calls. Tuck done() inside impl instead of letting it hang out in the plugin's public interface.
Oops! I only meant to comment, not comment and close. Maybe those buttons shouldn't be so close together :)
Got it. It also looks like mozilla will just use window.performance instead of mozPerformance, IE has already moved to window.performance. I don't know about chrome & safari yet though.
Yeah, vendor prefixes are going away and everyone is standardizing on window.performance going forward. Chrome is already there. But I think the legacy prefixes still have value in the event the plugin encounters one of those old versions.