1) The performance impact should be functionally negligible. We do instrument a few of the lower level base JS objects but it's all very lightweight. We have not noticed any performance issues thus far. That said, we have some new features coming and we will make anything potentially performance impacting opt-in
2) the buffer of events is currently the latest 10 events from the console, network, and user interaction, for a total of 30. We are looking at modifying this.
3) You can certainly bundle our script, we use the same technique Google Analytics does to capture hits.
4) Nothing, although we currently don't have hard caps and would certainly be in communication with you if you were concerned that was happening!
I can speak to the performance issues. I use this on a very javascript laden website, and I've noticed absolutely zero performance hits as a result of running.
I do have a few questions that went unanswered, though:
- What's the performance impact, both in terms of initial page load and in terms of tracking stuff.
- How big is the buffer of "events" in the timeline?
- You charge per hit. Is there a way I can load the javascript from my own CDN? Does it ping your server upon load?
- What prevents somebody from going to my website and triggering a large number of "hits"?