Optimising Javascript for Marketers

How Javascript affects web page speed. 5 of 10 things marketers should know about website performance.

Article 5

This is our fifth article on website performance for marketers. This time focusing on the impact of Javascript (JS) on the speed of web pages loading. Fast loading pages are essential for keeping your visitors on them and also for good SEO ranking.

I'm an ex-marketer turned developer spilling the beans on all the the performance tips I wish I had known when I was marketing.

If you're new to managing a website then this is the series of articles for you.

1. What does Javascript do again?

Good question... we gave a basic overview of Javascript in our second article. JS has many roles, but one of its main jobs is to add interactivity to a web page. But it can also be responsible for pulling in dynamic data plus much more.

Here are some jobs where you'll typically see it in action!

• A light box: this is a gallery for opening up images in a light box type view.
• Filtering content on the page: we used it on a builder's website to filter examples of residential projects from a long list.
• Some bespoke animations
• Carousels and sliders: where content is being slid across the page.
• Map functionality, e.g. Google Maps
• Updating a shopping cart
• Game functionality
• Pulling in adverts
• Scroll effects, i.e. doing something as the user scrolls down a web page
• And much more...

Is is essential for a website? No, only if functionality like the above is needed. There are plenty of websites out there running fine without a single line of JS.

2. How to recognise a JS performance issue

Just because JS is being used doesn't mean that it will generate a performance issue. For example, this site scores 100/100 for performance and we use it.

But if your site is sluggish, or scoring less than 90% for a PageSpeed Insight's performance test - then JS maybe one of the main culprits for this.

In general, JS becomes a problem:

1. When more than is necessary is used, i.e. there is redundant code being downloaded and parsed (read by the browser)
2. Or, there is simply too much

You'll know if you have a JS problem if your PageSpeed Insight tests are throwing these following error warnings:

• Reduce unused Javascript: More JS is being downloaded than is required by the elements on the screen.
• Reduce Javascript execution time: Big JS files take longer to process
• Minimize main thread work: JS can consume the main thread, i.e. the main process running - consuming memory and slowing everything down.

These other warnings could also be related to too much JS:

• Eliminate render blocking resources: that's code that needs to load (in the head of your web page) before any content is displayed.
• Reduce the impact of third party code: this is code coming from another server (i.e. computer) that your site needs. This is most likely to be CSS or JS.

In my last article, I remarked on a local marketing agency website that has 2.4mb of CSS to download. Well, their JS isn't performing much better either. They have nearly 750kbs of compressed JS downloading to their site via 53 requests to the server (arghh!). Uncompressed the size of this JS rockets to 2.7mb. Considering code is just plain text then that is oodles and oodles of JS! It's a recipe for a super-slow site. No wonder they only score 29% performance on PageSpeed Insights.

Remember the browser needs to read that JS and match it up with elements on the page that need it. All that reading / parsing of JS is going to consume the browser, slowing it right down.

3. Causes of JS performance issues

So now we know that too much than is needed or simply too much JS is going to cause site performance issues.

Here are some common reasons why JS might be affecting your website.

3.1 JS that is being downloaded but for no reason

3.1.1 Plugins

This will generate the redundant code error warning as seen in PageSpeed Insights. This is a common WordPress (WP) problem, especially when plugins are used.

We touched on it with our CSS performance article. The issue is this, you may be using a WP plugin to create a gallery on a product page. When the plugin installs, it adds all its needed code to the head of the web page, e.g. CSS and JS.

This head section is the same one for all pages across the website.

End result, your homepage (that doesn't have a gallery displaying) downloads code for a gallery widget!

3.1.2 Bundling site-wide JS code into one file

Some developers may inadvertently do the same thing by trying to save on requests to the server (a good thing). All the JS for the whole site will be bundled into one file... so again, the gallery code will be downloaded even when there is no gallery on the page (a bad thing).

3.1.3 Using libraries

There are plenty of JS libraries: designed to make life easier for the developer. They come with lots of really useful functionality. One such library is JQuery. It's incredibly popular and simplifies arduous developer jobs when coding JS. It's only 88kb (the current compressed version) but every byte counts!

The trouble is that the developer may only use a tiny fraction of JQuery's capability. So, most of the code will be redundant. A waste of downloaded bytes.

Another popular library is GSAP (Greensock Animation). It's used for complex animations on the web. But I've also seen it used for simple animations that could have been achieved with pure CSS.

3.1.4 Page builders

Page builders also have a habit of downloading too much JS. The good ones inline their code with the element that needs it. Or tree-shake their code (i.e. get rid of the unused code / the dead leaves). But others will add their complete JS library even though the elements that might use it never end up on any web page.

3.1.5 CSS libraries

CSS libraries (like Bootstrap 5) often come with a JS file. This is only needed for some of their components, e.g. an accordion. But inadvertently developers may include it as standard. Again, even though the carousel it powers is never used.

3.1.6 JS instead of CSS

Often developers use JS to do something that could have been done using CSS. The CSS only approach is better as there is only one file to download or it is inline (i.e. with the HTML code). Often this is relating to animation of elements... there are some pretty cool animations that CSS can do without JS.

Or for something like making sure columns with uneven content end up the same height. The latter can be achieved using CSS Grid or CSS Flexbox; there's no need to use JS.

3.2 Simply too much JS...

Even though you're downloading the exact code for the elements on your page, i.e. there's no redundant code... this still might throw a Javascript related performance error.

You may have a gallery on your homepage, with a filter and a carousel. Three items that can often need a load of JS to power them.

PageSpeed Insights is going to complain because it's still going to take time to process the JS. And to further compound the problem, the user may never scroll down to the gallery... so what was the point in downloading that code?

Other big consumers of JS can be social media feeds, maps and reCAPTCHA (used to avoid spam). Often I see a website footer, which may not get scrolled to very often, with:

• A Google map
• A form with reCAPTCHA
• And a social media feed

Arghhhh!!! That's really going to slay page speed. And wearing my old marketing hat... is it really going to add value for the website visitor?

4. Optimizing Javascript - solutions

A lot of these solutions are technical. But if you know the principle and can see what's happening on a web page. Then at least you can have a useful dialogue with your developer.

4.1 Choose and use your plugins and page builder wisely

Take a long good hard look at your list of plugins. Are they adding value? If not remove them - be careful though, some WordPress sites fall apart without their plugins. It's best to make a list of what each one does and consult your developer.

Ideally, can the plugin code be added conditionally, e.g. a gallery plugin's JS is only added on the web pages that use the gallery.

Also, make sure you do lots of PageSpeed Insights tests on page builder plugin websites. If they don't perform well, then it clearly isn't a priority for them.

4.2 Separate out JS, conditionally add it

If your developer has bundled all your JS into one mega-file... can this be separated out and conditionally added? So, there is no redundant code being downloaded; only the code needed for the elements on the web page.

4.3 Vanilla JS vs libraries

Libraries such as JQuery make it easier for the developer to manipulate web pages. But they don't need to be used. Developers can write vanilla JS (i.e. without being dependent on any library) to manipulate web pages. This has the advantage that the developer only writes the code that is needed... and that's very lightweight. We don't use JQuery on this site, opting for the vanilla approach.

4.4 Choose lightweight vanilla JS libraries

There is some functionality that would be hard to recreate in vanilla code. For example, to create JS that manages a slider then it would take too long and cost too much for the developer to build their own.

So, it makes sense to use a library. But, developers do have a choice of what libraries they can use. For example, they don't have to choose a slider library that depends on JQuery (i.e. needs JQuery downloaded to run as well).

We recently had to build a component with a slider in it. We spent quite some time looking for light-weight components. And found Glide - a super light weight component for making sliders. We conditionally add this on only pages that use the slider. Perfect.

4.5 Control when JS loads

Developers can control when JS is loaded. For example, one good practice is to load the main content of the web page. And only then to add the JS. This is perfect for elements that need JS, that are further down the page, i.e. need to be scrolled to. Obviously, not for components in the main view when the page loads.

Another practice is to lazy-load JS. JS can be loaded dynamically. For example, when the website visitor scrolls the page, when a certain point in the page is reached then this triggers JS to be loaded.

4.6 Are the on-screen components worth it?

If you're using components that use lots of JS then you need to make sure that they're pulling their weight from a marketing poing of view. Is that gallery adding value? Is that social media feed really needed? Do we need a Google map? Etc etc.

4.7 Avoid third-party JS

Your website might use JS that is being pulled from another server. For example, you can access JQuery from a remote server, instead of having it on your server. This isn't good... as your web page speeds are now dependant on a third-party server. If that server is being hit with lots of requests then it's going to slow down and not respond quickly to your request. It's best to get that code direct from your own server.

In fact this subject (the impact of third party code) is such a biggy that it will have it's own article on it.

4.8 Minimise and compress everything!

In our previous article we talked about compressing CSS files. This is the process of removing white space and notes from CSS files, so that they are smaller.

Well, good news, the same thing can be done to JS files. They can be minimized and GZipped to compress them to smaller sizes.

4.9 Minimise the number of requests, consider inlining the code

In my earlier example, the local marketing agency was requesting 53 JS files (crazy!). This needs to be avoided at all costs.

Developers can also inline some code to avoid a request for a file to the server. It's simple to do and can lead to speed efficiencies.

And finally...

Don't use JS when there is a CSS solution.

5. Useful tools

In the last article, I suggested the Page Size Inspector in Chrome. This will also be useful for spotting JS performance issues.

This neat little Chrome extension will tell you:

• How much JS is being downloaded in total
• The names of the JS files - useful for identifying what they do in relation to plugins
• How many bytes they are (note bytes, not KB) when compressed and when uncompressed
• And how many files have been requested from the server
• How long it took to get everything

I use this all the time, as well as PageSpeed Insights.

If you need to convert bytes to KB or MB, then Google will do that for you. Just search on bytes to KB, or bytes to MB. And go from there.

OK, I think that's about all for this article, hope you enjoyed reading it. More in the next one!

BTW, you'll notice that I've been using fast animals for the blog images... since we're talking about speed. No need to further explain the cheetah!

If you've found this interesting then don't forget to follow us: LinkedIn, Twitter and Facebook.