The effect of JavaScript on mobile web performance is twofold.

One, it is the second largest contributor to webpage weight, behind images, thereby increasing download time; and two, once downloaded, the browser then needs to run the script, which can delay the downloading/rendering of other (perhaps more important) assets on the page.

JavaScript (aka scripts or JS) is one of the triumvirate of technologies that make web pages (and web apps) work. The HTML (Hypertext Markup Language) controls the structure and content of the webpage; CSS (Cascade Styling Sheets) controls how the site looks on different devices; and JavaScript makes the page more interactive and dynamic.

Scripts perform numerous functions on webpages such as loading ads, A/B testing, tag management (personalizing the page) or displaying an inline video player.

Over the last five years, the total weight of pages sent to mobile devices has quadrupled to 2.2MB. Size matters because, in general, the more data that is sent over a mobile, or fixed, network the longer a page will take to load. More data, more seconds staring at an empty mobile screen.

This suggests that images – which tend to take up more of the total kilobytes (KB) or megabytes (MB) of each page – are the main culprit. But this is not always the case.

JavaScript could potentially have more of an impact on page performance than images. As Patrick Meenan, founder of the web performance testing site WebPageTest and software engineer at Google, explains:

“Scripts are usually a (bigger) issue because of the time it takes to actually execute the script in addition to the download size, while images really only matter because of the download size. With mobile devices for example, it can take several seconds to run a script even after it has been downloaded.” 

It’s not necessarily JavaScript, per se, that is the problem, but how it is implemented: scripts can monopolize browser activity, blocking the download and rendering (displaying) of other content.

“The problems are often compounded where the script is referenced in the page. The content after a ‘blocking’ script (as opposed to an async script) doesn’t exist, as far as the browser is concerned, until after the script has been downloaded and executed. When, as is commonly the case, scripts are put at the beginning of the page this means that the page will be completely blank until the scripts have downloaded and executed.”

We will discuss below the difference between blocking, inline, synchronous (sync), asynchronous (async) and deferred scripts and how to fix JavaScript problems, but first we’ll look at how to spot issues.

Testing for blocking JavaScript

If you have tested your webpages using Google PageSpeed Insights (N.B. you should regularly test your mobile webpages using tools such as WebPageTest and PageSpeed Insights), chances are you have seen the following warning:

! Should Fix:

Eliminate render-blocking JavaScript and CSS in above-the-fold content

Your page has 8 blocking script resources and 7 blocking CSS resources. This causes a delay in rendering your page.

None of the above-the-fold content on your page could be rendered without waiting for the following resources to load. Try to defer or asynchronously load blocking resources, or inline the critical portions of those resources directly in the HTML.

The text and image above is from a Mobile PageSpeed Insights test on BBC.com conducted in February 2017.

Note “above the fold” refers only to the part of the webpage which is visible on a mobile device, without scrolling, Google is not analyzing scripts on the rest of the page.

The BBC is the world’s most popular English language news website, according to Alexa, so to put it in context we should also test the others in the top four. The results suggests two more publishers have similar issues with JavaScript. (The test also highlights CSS issues, but this is not the focus of the article):

1. BBC.com PageSpeed test (8 blocking scripts; 7 blocking CSS resources)
2. NYTimes.com PageSpeed test (0 blocking scripts)
3. ESPN.com PageSpeed test (2 blocking scripts; 3 blocking CSS resources)
4. CNN.com PageSpeed test (6 blocking scripts; 2 blocking CSS resources)

4x growth in JavaScript use in five years

Over the last five years the amount of JavaScript used on the average mobile page has almost quadrupled from 101KB in February 2012 to 387KB in February 2017. The number of requests (a request is the number of times a browser is required to download an additional piece of content or code) for different JavaScript files has increased from 8 to 21.

This is clearly illustrated in the graph below from HTTP Archive. HTTP Archive tests the top 1 million sites several times every month using data from WebPageTest, and publishes trends and stats that are essential benchmarking for the performance of your site.

For the top 1 million sites monitored by HTTP Archive, JavaScript accounts for 17.4% of page weight. JavaScript also accounts for 21 out of 93 total requests (22.6%).

For some sites, particularly in the news space, JavaScript has a considerably larger share of page weight than the norm.

The image below compares the breakdown by content type for the average site with BBC.com tested by HTTP Archive (15 February 2017):

• The first thing to note is how impressively small the BBC page size is: 609KB v 2225KB.
• The second thing to note is how small the combined size of the BBC images: 70KB v 1501KB.
• The third thing to note is how proportionally large the scripts are: 458KB or 75.2% of total page size.
• The fourth thing to note (not shown in the charts below) is that 39 (44.3%) of the BBC’s total 88 requests are scripts.

When you compare the test results of the top four English language news websites, it is remarkable how much smaller the BBC is than its rivals. It is a one-third to a half of the size, with two to three times less JavaScript.

1. BBC.com tested by HTTP Archive: Scripts 458KB (75.2%) of 609KB of total data; 39 JS requests (44.3%) of 167 88 total requests.
2. NYTimes.com HTTP Archive test: Scripts 1511KB (51%) of 2953KB of total data; 73 JS requests (43.7%) of 167 total requests. (N.B. NY Times has a dedicated mobile site at mobile.nytimes.com, which is not listed by HTTP Archive, which may deliver different results.)
3. ESPN.com HTTP Archive test: Scripts 1183KB (65.7%) of 1802KB of total data; 50 JS requests (47.2%) of 106 total requests.
4. CNN.com HTTP Archive test: Scripts 1484KB (68%) of 2182KB of total data; 67 JS requests (31.9%) of 210 total requests.

What is the effect on mobile page speed?

So does it follow that the slim-line BBC site would load much faster than all its rivals?

Err, no. On 15 February 2017, HTTP Archive recorded the following load times:

1. BBC.com: 18.3 seconds
2. NYTimes.com: 27.4 seconds
3. ESPN.com: 8.8 seconds
4. CNN.com: 31.5 seconds

So, the BBC is faster loading on a mobile device than CNN and the New York Times, but considerably slower than the (larger) ESPN.

This is what the two sites look like on a mobile device. (The filmstrip is one of WebPageTest’s most visually compelling features, easily understood by any non-techie). Each frame represents 1 second. When the HTTP Archive test took place, for 9 seconds BBC.com mobile visitors saw nothing, while for 4 seconds ESPN visitors saw nothing.

There could be many reasons why one website might be faster than another, such as server response times, use of content delivery networks (CDN), the impact of ad networks, inclusion of third-party data (common on news sites), or the time and place of the test (in this case California, USA).

However, all other things being equal, it is possible that JavaScript could be a contributing factor. (Apologies for the hedging of bets). As noted above, BBC.com did receive more warnings for blocking scripts above the fold than the other news sites.

Reducing reliance on JavaScript

JavaScript is often used to perform tasks that cannot (easily) be done with HTML or CSS. As the W3C gradually add these features to the HTML or CSS standards and they are implemented by browsers, the JavaScript patch is no longer needed, as HTML/CSS is likely to be more efficient. A good example of this is responsive images.

Alex Painter, Web Performance Consultant at NCC Group:

“As a rule, it’s worth sticking to the principle of progressive enhancement – delivering a site that works without JavaScript and using scripts only for those extra features that can’t be done any other way.

“Using JavaScript to render content can be expensive – it takes time to load and execute. So, for example, if you can use HTML and CSS to achieve the same result, that’s generally going to be faster.

 “When it comes to responsive images, for example, you can use media queries in CSS and picture/srcset in the HTML to deliver the right image for the viewport without having rely on JavaScript.”

Choose asynchronous and deferred JavaScript over blocking and inline scripts

There are a number of ways that JavaScript can be implemented on a webpage, including:

1. Blocking scripts are synchronous which means they have to be dealt with immediately and ahead of anything else. By default, all JavaScript is parser blocking. As the browser does not know what the script will do to the page, as soon as it meets a request (in the HTML file) to download a JavaScript file, it stops building the webpage, and does not continue until the file is downloaded and executed.

2. Inline scripts also stop the page build, but as they are included in the HTML, they do not need to be individually downloaded. However too large or too many inline scripts will bloat and delay the initial download of HTML file.

3. Asynchronous scripts allows the browser to continue parsing (analyzing the code and building the webpage), while the JavaScript file is downloaded. Including the async attribute in the HTML tells the browser that it doesn’t need to put everything on hold.

4. Deferred JavaScript – tells the browser to leave the execution of the JS file until after it has finished building the webpage, this is signified with the defer attribute.

Are blocking scripts ever justified?

Patrick Meenan:

“If the site functionality relies on the code, then it needs to be run as a blocking script so that it is ready before the page needs it. A very common case for this is tag managers and A/B testing platforms where the code will change the page. In other cases blocking is used when it will be more work to load the functionality asynchronously.”

Reducing size of JavaScript files

How big is too big? How many requests is too many?

This will always be a balancing act.

Patrick Meenan:

“Since the browser will only load six requests at a time for each domain, if you have more than that it needs to request the rest after the first ones have completed, leading to longer times from the request/response delays.

 “Larger JavaScript files also take longer to parse and run (1ms for every 1KB of uncompressed JS is a reasonable estimate).  All else being equal, if you have the same amount of JS in a lot of files it will take much longer to load than if the same amount of JS was in a single file.”

Google recommends minification of JavaScript files using UglifyJS or Closure Compiler.

For more on how to optimize the speed of your mobile site, check out our previous three-part series:

• How to optimize your mobile site speed: Testing for issues
• How to reduce the impact of images on your mobile site speed
• How to optimize images for mobile: Implementing light, responsive, correctly-formatted images

Andy Favell is Search Engine Watch’s columnist on mobile. He is a London-based freelance mobile/digital consultant, journalist and web editor. Contact him via LinkedIn, or on Twitter at Andy_Favell.