Well, it’s been a few weeks, and we ended up getting the SiteCatalyst tracking script working just fine … and we even managed to get part of it moved into an external file, to allow for better client side caching.
In the end, we ended up with a newer version of the tracking script, which I am quite happy about, as it should have fewer bugs and provides more accurate tracking for my client.
But, it did cost my client something like 2,5 working days of billable hours for me to finally get the script to behave. And considering the hefty fees my client already pays to use SiteCatalyst, you’d have thought that support would be really good.
Anyhow, these numbers just in:
In it’s current incarnation on the very same test page as I profiled in part one, the impact of SiteCatalyst is now:
- 1107 extra javascript calls
- 70,64ms extra execution time.
This means that SiteCatalyst is now responsible for about half the javascript calls and about 57% of the execution time of all the scripting on the page. The new version of SiteCatalysts tracking script is actually performing worse than the previous one.
Considering the fact that SiteCatalyst provides absolutely NOTHING to the visitor experience, I think it’s a quite significant impact.
But at least I finally got round to cleaning up some of my older code as well, so it went from somewhat sluggish to immeasurable impact. 1 call, too fast to measure. Thanks to Chris Heillman for providing the article / experiment that got me to think in new ways
I find it rather shocking that “Enterprise” software can suck so hard, but maybe I am just too focused on creating good user experience and providing a base for my clients to increase their revenue and sustain their business … ironically, most clients expects their “Enterprise” software to do that for them ;-)
