Gatling Analytics: make any JavaScript tracker asynchronous
Gatling is a jQuery plugin that provides a framework for firing non-asynchronous tracking pixels in an asynchronous manner.
The problem with non-asynchronous trackers is they block the page load until they respond, creating a sequence of delays. By using Gatling to handle third-party analytics trackers, you get the following benefits:
- Trigger any number of tracking pixels in parallel, without impacting site performance.
- Centralize your tracking pixels into one file for easier management and auditing.
- Implement multiple trackers for one provider much more easily (e.g., track a hit on two different Google Analytics accounts).
- Stop depending on third parties to implement their own asynchronous libraries properly.
- Fire off trackers as the result of a user action on your site without touching the actual source of your application.
It’s good for site owners, and it’s good for tracker providers. Get into it by reading the Gatling overview.
The slippery slope
It starts off simple enough: you need some analytics data.
You sign up for a Google Analytics account, throw a bit of code at the bottom of your page template, and bam: you’ve got analytics. And it’s great! You soon realize that you’re not getting the information fast enough, so you sign up for a Chartbeat account and get hooked on real-time charts. Awesome!
But, is it awesome enough? Is it sick? You’re hooked on visitor data and sign up for every great presentation of it available through third parties: funnels from KISSmetrics; heatmaps from Reivigorate. You’re an analytics machine!
Then, marketing has some tracking pixels they’d like you add, including conversion trackers, retargeting, and some trial affiliate partners.
Before you know it, your pages have more analytics code than content, and they’re taking forever to load. These small, magical code snippets have become unwieldy, for two reasons:
- There’s no centralized way to manage all your analytics trackers.
- Most of your trackers are non-asynchronous.
This is problematic because of how browsers work.
How browsers work
JavaScript snippets on a page (the kind you put there by tossing in a “<script …>” tag) are loaded by the browser non-asynchronously (i.e., one after another). Why? Because of dependencies: if you’re including “a.js” first which defines some variable “foo”, and you’re including “b.js” second which uses the variable “foo”, then bad things will happen if “b.js” loads before “a.js”. To prevent this specific kind of badness, the browser loads your JavaScript one at a time, waiting for completion before proceeding to the next.
Most people don’t know that the script tag you add to the bottom of a page isn’t always the end of it. Sometimes those script snippets bring in other scripts that load more scripts. The worst I’ve seen is a tracker that includes 6 other trackers, some of which included other scripts themselves.
Because these are third party trackers, you have no control over how they work, which means no control over how many requests your page must complete before users can see your content.
Example
Let’s say you have ten trackers you want to put on your page, half of which actually include one other script; you’re now actually waiting on 15 requests to finish before the page is ready, not 10. Now let’s say that each of those requests takes an average of 150 milliseconds to respond.
15 requests * 150 milliseconds = 2.25 seconds just for analytics
That’s where the knewton.com site was not too long ago. We had include files on every page that contained the common tracking pixels for each page. Then we had the non-common tracking pixels on all pages of a certain type. If you asked me what trackers we were using, it would (and did) take me 2 days of digging through page after page to figure it out.
The worst part wasn’t the nightmare of managing them, it was the performance hit our users were getting; it wasn’t uncommon for users to see 2-4 seconds of blank screen on every page as they clicked to different pages in the site. It was a mess.
A solution for everyone
Enter the Gatling jQuery plugin. In writing the plugin, I had one simple goal in mind: track any number of analytics providers without impacting the user’s experience. This turned out to be a pretty tricky goal given how poorly some analytics providers tracking code is designed. And, because most of our trackers were synchronous trackers, I needed a way to create asynchronous trackers without relying on every provider. Gatling does that.
Gatling provides a framework for expressing almost any synchronous tracking pixel as a comparable asynchronous Gatling Tracker. These Gatling Trackers can then be fired after the browser’s DomReady event, meaning that user experience isn’t impacted. And because I’m dealing with one type of tracker now—a Gatling Tracker representing Google Analytics works the same way as a Gatling Tracker representing Chartbeat—I can centralize all my tracking code into a single JavaScript document, which I can just include on every page.
This implementation comes with an added perk for developers: it takes less code to trigger multiple trackers of the same type, such as using two different google analytics accounts on the same page.
We get two customer acquisition benefits: users get a snappier experience on the site, which helps conversion, and our SEO gets a nudge in the right direction because search engines appreciate faster page loads.
For site owners
If you run a website that’s suffering from analytics bloat, take a look at Gatling. It’s open source and on github with some example implementations and a library of Gatling Trackers for common analytics providers.
For analytics providers
If you provide trackers that rely on JavaScript and want to speed up your customers’ sites and save internal dev time developing your own asynchronous trackers, encourage your customers to try Gatling.
Let’s do this.
To encourage the plugin’s adoption and implementation, we’re offering free consulting (as much as possible) for expressing any tracking pixel not already defined as a Gatling Tracker. If you’d like to use Gatling but can’t figure out how to create a Gatling Tracker for your analytics provider, open a ticket on the project’s Issue Tracker.
You can check out more information about Gatling on the overview page, browse the library of common Gatling Trackers, take a peek at how you create a Gatling Tracker, or skip to getting started.
