What you need to know about JavaScript and performance

Hi there,

JavaScript is the main culprit behind slow sites. Ten years ago it was network bottlenecks, but the growth of JavaScript – both first and third party – has outpaced network and CPU improvements on today's devices: 

Chart based on this analysis from the HTTP Archive.

Understanding how JavaScript affects your site – and your users – should be a top priority. Keep reading for tips on how you can better monitor and control your scripts.

JS performance and user behaviour

Given the dominance of JavaScript on most sites, it's not a big surprise to learn that there's a strong correlation between JS performance and user behaviour. 

For example, looking at the distribution of real user traffic for an ecommerce site in the chart below, you can see that longer JS CPU times correlate to much higher bounce rates. At 0.8 seconds, the bounce rate is 20%. By 4 seconds, the bounce rate has more than doubled to 45.6%. 

(If you're a SpeedCurve LUX user, you can see your own version of this chart at the top of your JavaScript dashboard.)

JavaScript growth and third parties

A decade ago, the amount of first- and third-party JavaScript was about the same. Today, third-party JS is more than twice that of first party. 

Third-party growth in terms of JavaScript size is even more alarming. While first-party JS doubled from 53 KB to 106 KB, third-party JS octupled (!!!) from 32 KB to 258 KB. Steve Souders highlights more concerning JS trends in this blog post.

What can you do to monitor and mitigate the impact of JavaScript on your pages? Keep reading...

Load scripts asynchronously

The reality is that most scripts are still loaded synchronously. The best way to load scripts asynchronously is to use the async attribute. The benefits of loading scripts asynchronously are highlighted in the following waterfall chart for nytimes.com:

Notice that none of the scripts have the red hash pattern that (in SpeedCurve) marks a synchronous script. That means all of these 20+ scripts are loaded asynchronously. As a result, the page renders quickly (0.7 seconds) and the script parsing and execution are not blocked – each script is handled as soon as it arrives. Learn more.

Preload scripts

Even when scripts are loaded async, the browser may still twiddle its thumbs for a second or more waiting for the first script to arrive. This delay can be decreased by using link rel=preload like this:

Link rel=preload is useful for downloading any important resource more quickly, such as stylesheets that contain critical CSS, fonts that are used in important design elements, and hero images. It's especially important for scripts because they block page content from rendering and consume the most CPU during page load. Learn more.

Track CPU usage

If the CPU is blocked, then browsers are delayed in responding to user interactions like scrolling and clicking on links. In other words, the page feels janky. Guess what consumes the most CPU in browsers. Correct: JavaScript.

In order to keep pages rendering and feeling fast, we need to focus on JavaScript CPU time to reduce blocking the browser main thread. If you're not tracking your site's JavaScript CPU usage, start doing that now. Learn how to get the most out of your LUX and Synthetic JavaScript dashboards.

Create performance budgets for your third parties

We've recently revamped your Synthetic third-party dashboard. Now you can:

• Track individual scripts over time (including first-party JS, if you'd like)
• See which of your third parties have blocking JS & CSS
• Find out which scripts block CPU
• Create performance budgets for specific scripts & get alerts when they go out of bounds

Questions? Ask us online and IRL

• Reply to this email or contact us at support@speedcurve.com.
• Find us at SmashingConf TO on June 25-26.