The Price of JavaScript
Using JavaScript is commonplace practice and can be found on almost any popular website you visit. With so many sites using it, what could be bad about it? We take a look at the price of JavaScript.
Most websites use JavaScript to manipulate page content and add interactivity, while many analytics services use JavaScript to listen for events as well as track user behaviour. As with most things, there are costs and benefits to consider, but many tools are sold solely on the benefits to the site owner, without considering the potential cost to the end user.
From Server to Screen
To understand the performance impact adding JavaScript features to your site can have, let's quickly step through what happens when a browser requests a JavaScript file:
- The file is downloaded from a server. How long this takes depends on the size of the file, and the speed of your network.
- The file is decompressed and parsed, so the browser knows what it contains.
- The JavaScript is executed, and the instructions it contains are performed. (These instructions could include “Download more JavaScript”, in which case go back to step one)
Due to how browsers work, your device has to run JavaScript using the same CPU process that renders the rest of the site and deals with user interactions. In practice, this means that during steps two and three, the site will be unresponsive — scrolling and clicking will have no effect. Animations or videos will stutter. Depending on how your site has been built, it might not even be visible. In front-end dev jargon, this is known as “jank”, and has been a hot topic for a while. It is something to be avoided if possible.
These issues are especially pronounced on mobile devices, which are constrained by battery and chip design, as well as slow mobile networks. While minimising your site's download size is generally not controversial, not all bytes are equal. A 150kb image will take time to download but is unlikely to block the rest of your interface. 150kb of JavaScript, on the other hand, can easily take a second just for step two — that's an entire second when your site feels like it has crashed, with no feedback to the user. Android devices, in particular, struggle with this. Given that the vast majority of devices online today (especially outside of western Europe and the US) are Android, this is likely to affect a lot of your users.
The more work you try and do in JavaScript, the jankier your site will feel. If you're doing intensive DOM manipulation (changing the content or structure of the page after load — for example, A/B testing) this can be slow, and these delays will be magnified on slower devices. The effects can be unpredictable, but the result is unlikely to be a great user experience.
Ad Nauseam
Some of the most intensive JavaScript manipulation is commonly used by online advertising providers. Many sites that rely on ad revenue give away control of their site's performance by allowing JavaScript from unknown third parties (ad buyers) to run on their site.
In exchange, they frequently find themselves shipping code that is actively user-hostile or exploitative. While these are extreme cases, it's vital to monitor the effect any third-party scripts are having on your site. In more mundane cases, we've seen services disappear without warning, leaving sites using them stuck trying to load scripts that no longer exist.
Real World Impact
The day-to-day end result of poor front-end performance has been well documented, and Google recently announced they will be using site speed as a ranking factor for mobile search in addition to desktop, putting added pressure on webmasters to ensure their site loads quickly.
So, what can you do? As with most things, there's no simple answer that's right for everyone. Just bear in mind every feature you add to your website comes at a cost. Don’t let that put you off — most third-party scripts now behave well, and have minimal impact on performance. But before adding that extra analytics script into Google Tag Manager, or asking your dev team to plug that fancy widget into the footer, ask yourself whether the benefits it brings are worth the performance cost to your users. If you normally use your site on the office wifi, try it on a mid-range Android device, on a mobile network (or try using Chrome’s developer tools to simulate different devices). Does it feel fast? Do things seem to move about on the page while it loads?
Is the price of JavaScript worth it? When you put yourself in the shoes of your users, you can judge for yourself whether the experience you’re providing is satisfactory.