In fact, it should be helping them..
I appreciate this is what A LOT of you have been thinking for quite some time, and so have insisted that any Experiments built are written using Vanilla (plain) JS. Unfortunately (or fortunately, actually), that’s not correct.
Most websites still use jQuery – over 80% of the top 1 million Alexa-ranked websites. This is who this post is intended for.
To address the other 20% of websites – there are advantages that could be argued for adding jQuery into your testing tool library – it’s a balancing act between performance (not great if you use jQuery) vs. reliability and speed-to-outcome (great if you use jQuery). I’ll leave you to work that out.
Focusing on the sites who already have jQuery – there are a couple of arguments I hear as to why you shouldn’t be using it in your Experiments.
1. It slows down the site
Let’s be clear about this point – having jQuery AT ALL on the website slows down the site. Once it’s on, and the browser has executed it and stored it into memory, people using it does not slow down the site.
There are two aspects to performance: Time to Download and Time to Execute.
For download times, it’s important to recognise that jQuery code is considerably smaller than Vanilla JS. It’s tagline is “write less, do more” for good reason. When your test is 1/4 of the size, it downloads faster, and in doing so means your page loads faster.
For execution times, yes it’s theoretically slower. But when computers measure the ability to compute actions in billions per second (Gigahertz), this is not something you need to worry about for most AB Tests. Even for a large redesign test on an average PC, using jQuery will not slow down how quickly your page renders to within any noticeable range.
The key thing to keep in mind here is that network requests are considerably slower than local processing, and so as a rule-of-thumb, you want the priority to be on your code being as small as possible.
2. It causes Content Flickering
Let’s shoot this down straight away. Poorly architected platforms cause content flickering – using jQuery does not. Neither do poorly optimised images, forgetting to minify your code, or running too many tests.
This comes from a (still) widespread misunderstanding of how content loads, and inevitable nonsense fed to hundreds of people by their vendors.
JavaScript is single-threaded, meaning only one thing executes at any given time. Think of it like a 1-lane road, with no motorbikes squeezing past. If your code has 1 million lines of jQuery, and there’s a task to reveal the page that’s queued up, the reveal will absolutely not happen until those 1 million lines execute first.
The key is to make sure you mask the page when you start, and reveal it once you’re done. Some tools do this awfully and that’s when the excuses come out of “oh, you must have done something wrong”, but you haven’t (I promise).
Reasons to use jQuery
The one thing I don’t hear put forward often are the reasons to definitely use jQuery when possible:
- It’s shorter, and so downloads faster. Download performance matters.
- The code is faster to write. Better time-to-value. When paying for people’s time as we all do in some way or another (hourly, daily, yearly), this really matters.
- It’s better supported – if you want to support a range of browsers, it’s the most error-free way of doing things.
- It’s less error-prone – want to make sure your code doesn’t break if elements disappear? jQuery does it by default.
- It’s more powerful. Want to use advanced Sizzle selectors, filter the elements that come back by matching them against other selectors, and doing something with what’s left? No problem. Doing this in Vanilla JS is an absolute pain, believe me.
- Everyone knows it. Because the code is so much more straightforward, your devs already know it. So they’re not Googling “how to make GET AJAX request using XMLHTTPRequest vanilla JS”, they’re just writing $.get(‘https://somewhere/api/’).then( // do something.
There’s no “hmmm.. if you want it done with jQuery it’ll take 2 days. If you want it done with Vanilla JS it’ll take maybe 6-7 days”. - Event handling: Want to track clicks, scrolls or something else? jQuery does it well with minimal code. Whether the elements are there or if they appear later. You can do this with Vanilla JS, but it’s a lot to make sure you get right.
Education is important here
We all want the same thing from our experimentation programmes:
- Tests to be built quickly
- Tests to be rock-solid, and not randomly break
- Performance to not be affected
That’s all I can think of. And jQuery helps with all of these things – AS LONG AS it’s already part of the site.
So.. why not give it a try? If you’re anything like us, you’ll have been tracking every part of your build process, for every project and every member of the team, as well as how many bugs arise. Try to make the switch to using jQuery, and monitor:
- The speed of development and QA
- How many bugs you deal with in QA and once live (and the nature of them)
- The impact to site performance, compared to using Vanilla JS (you’d need to build your test twice, but it’s great for reassurance).
If the first 2 things improve whilst performance stays level, it could be a huge win to speed at which you achieve results.
