WordPress Reduce Unused Javascript

WordPress Reduce Unused Javascript

In this post I’ll be talking about how to reduce unused javascript in when using WordPress, why you might want to do this, how you’d do this and the benefits you’ll if you reduce unused javascript.

If you’re trying to get good pagespeed results, this is one of the more annoying/frustrating issues to sort out.

There’s also a lot to this issue (I’ve tried to make it as human friendly as possible) so this is quite a long article. If you came here to find guidance on how to sort this out and want to get stuck in to it immediately, you can skip to the Managing Javascript Assets section by clicking here.

What is Javascript?

Javascript is a programming language, primarily used in web development. JavaScript can run both on the client side (in web browsers) and on the server side (using technologies like Node.js). Javascript is more commonly used on the client side (in browsers) and can be used for a variety of purposes.

Did that help? Great! I’m off for a cup of tea. Catch you later!

Don’t worry, I’m kidding. 

Although what I’ve mentioned above is technically correct it doesn’t really help much. I’ll try and explain things a different way.

Javascript can be used to do a LOT of different things to do with websites. When you’re using WordPress, you’re not explicitly writing your own Javascript and deploying it on your site to perform a specific function. The Javascript comes as part of your theme, and the plugins you install.

Javascript (when using WordPress) is chiefly used to “do code based things things in browsers which can be based on user interaction” (nice and vague I know). Let’s provide some examples to put this on context:

• Things that move (animations and sliders).
• Things that change with user interaction (drop down menus or buttons that change in appearance when you hover your mouse over them).
• Form validation (“you haven’t entered a valid email address” for example).
• Dynamic content (a change in appearance based on what a visitor does, or the size of the screen of the device).
• Dynamic generation of CSS (Google Fonts works like this)
• Captcha protection on contact forms (Google’s recaptcha works using this)

All of the above (with the exception of dynamic generation of CSS) are orientated toward “something done in browser or by browser makes something else happen”. It’s Javascript that handles this, as Javascript can be used for browser side code execution.

The problem with javascript and wordpress.

You’re most likely using WordPress so that you don’t have to write code (aren’t we all?).

All the code that your site runs (of which Javascript is part) has all been written by someone else. You’re simply installing someone else’s code by deploying WordPress, and installing plugins and themes, but all that code was written by someone that wasn’t you.

How does the person that wrote that code know what you’re going to do on your site that enables them to write this code for you?

The quick answer is: They don’t.

How do they  know which page it is that you’ll use their code on?

The quick answer is: They don’t.

The Javascript is written to support the features of the plugin or theme that you’re using, not what you’re specifically doing on your site. If you’re not using all the features that your theme (for example) provides, the Javascript isn’t dynamically modified according to what you’re doing. You’re just using one aspect of a code base that does other things in addition. Consequently you could do something like install a plugin that does a lot of things, use it to do one thing, and Javascript is loaded that covers “all the things the plugin does” rather than “the one thing you’re using the plugin for”.

Also, Javascript can get put everywhere, “on all pages” type of everywhere. A real life example would be a captcha protected contact form. If you only put the contact form on one page of your site, this might not limit the captcha Javascript to one page, it could get put on all pages even if only one page of your site has a contact form.

Wait a sec, captcha Javascript on all pages? Not just the page with the contact form on it? But wouldn’t that be unused?

Now combine the two situations I’ve mentioned above and you could end up with “I installed a plugin that does loads of stuff, of which I’m only using one aspect, and now the entire plugin’s javascript (not just the bit I’m using) is on every page of my site”.

Yes. There you go. Unused Javascript. As in “reduce unused Javascript”. As in https://pagespeed.web.dev/ performance score reduction/opportunity for improvement:

OK, I’ll admit that I’m paraphrasing/humanising things to a degree here, but I hope this goes some way to what “unused Javascript” means to you.

What the Reduce Unused Javascript problem actually is.

The really short explanation is that unused Javascript negatively affects your site’s performance.

• Your site is slow.
• Your site is slower than it could be.
• Your site’s code is making your browser work harder than it needs to.
• Your site is “bigger” than it could be.

All of these statements or potentially applicable when your sits has unused Javascript.

Google’s advice covering removing unused Javascript can be found here.

The page above mentions two things that can slow your site down, here’s the first:

“If the JavaScript is render-blocking, the browser must download, parse, compile, and evaluate the script before it can proceed with all of the other work that’s needed for rendering the page.”

What “rendering the page” is, is you browser turning the page output (HMTL, CSS and Javascript generated by your site) in to the page displayed in the browser that your eyes see. Render blocking Javascript means that the browser has to receive all page output (including the Javascript) then “process” it before it can show you the page. If some of this Javascript is unused, the above means roughly that your browser has to receive all page output then “process” it (including code it doesn’t actually need to process) before it can display the page.

So the time it takes for a page to be displayed in a browser is longer than it could be due to BOTH unused Javascript, and ALL page output having to be downloaded and processed before the page can be displayed.

Make sense so far?

The second sentence on the Google page linked to above reads:

“Even if the JavaScript is asynchronous (not render-blocking), the code competes for bandwidth with other resources while it’s downloading, which has significant performance implications. Sending unused code over the network is also wasteful for mobile users who don’t have unlimited data plans.”

The “asynchronous (not render-blocking)” part means that page output can be turned in to a displayed page by the browser before the Javascript has finished downloading. Whilst this sounds good in the sense that the time it takes for Javascript to be downloaded doesn’t prevent the page from being displayed while this takes place, there is still a downside. The downside is that this unused code is still being downloaded. This can affect the load times of other aspects of page output that are needed for the page to be rendered. 

Whilst Javascript being asynchronous doesn’t slow down the rendering of the page itself, it can mean that it takes longer to download other, required, aspects of the page output simply because the unused code is being downloaded at the same time as used code.

Having unused Javascript in your page output is basically a waste of network traffic (even if it’s not render blocking). This waste of traffic also has a greater implication for mobile users who don’t have unlimited data plans, as they’re effectively paying money to download this unused code on your site.

This, in part, is why it’s harder to get a decent performance score in https://pagespeed.web.dev/ for mobile, than it is for desktop.

At this point you might think something along the lines of “that’s google being facetious and telling me off about something that doesn’t really make any difference to people on my site!”

I wonder how much electricity is actually used globally by the serving, parsing, downloading, compiling and evaluation of unused Javascript. I also wonder if Google have any jobs going (that was a joke).

Working out what’s causing unused Javascript to be loaded.

Just to forewarn you, part of this might make you want to throw your computer out the window.

Google’s https://pagespeed.web.dev/ is your best friend when it comes to working part of this out. The code coverage facility in Chrome’s developer tools can be helpful if you want to take a deeper look in to things as well. I’ll do what I can to cover both of these in this section. Fingers crossed, eh?

Let’s start with the low hanging fruit. Run your site through https://pagespeed.web.dev/ and then expand the “Reduce unused Javscript” section, and you’ll see a list of scripts (part of your page output) that call unused Javascript. You can hover your mouse over the script to see the URL of the script as well:

This, at least gives you an idea of what it is that the unused Javascript is specific to. In the example above we can tel that this is something to do with Elementor.

There is also another facility in https://pagespeed.web.dev/ that can be handy as well, and that’s the treemap. It’s quite easy to overlook this what with all the other things going on in the pagespeed results, but look, here it is:

And this is the kind of thing you’ll see when you click on “View Treemap”:

There you go, there’s a nice graphical representation of your page’s Javascript. How lovely. But wait… there’s more!

See the “Unused bytes” toward the top right hand corner? Give that a click and you’ll see something like this:

This gives a graphical representation of how much of each script isn’t used (the red part is the unused part).

That page I’m using as an example, I threw together using Elementor when writing this post about how to make a child theme in WordPress, and all I’ve done is put a contact form on it that’s protected with Google’s recaptcha. I haven’t really done very much with it (as you can probably tell), but that is 1.4MB of Javascript, of which about half is actually being used, just from the actions described above alone. Crazy!

When I first saw this, I had a moment of realisation. It’s not that there are entire scripts here that aren’t being used… it’s that there are scripts here that are partially being used.

Whilst this is, in itself, somewhat disheartening (I mean it’s not like I’m going to start writing my own Javascript now is it? I wouldn’t even be using WordPress if I could do that!) there are things that can be done about this. There’s also more that you can find out about this as well. You’d use Google Chrome’s developer tools to take this deeper look in to things.

Before I get started on using Chrome’s Developer tools, I should probably tell you why I’ve mentioned the treemap. I’ve mentioned this so that you can gain and idea of what’s making the Javascript load, and how much isn’t being used. This puts you in the position of identifying what it is that’s causing large portions of unused Javascript in your page output. On a good day, you might take a look at this and think “Oh, it’s that plugin! I’m not using that”. You could then uninstall the plugin. Or, if you are using the heavy Javascript plugin, you might consider finding a plugin that serves a similar purpose without generating as much unused Javascript. Nice and simple. On bad day, things might not be as obvious, or as straightforward to address.

So on to Chrome’s Developer Tools…

To open Chrome’s developer tools, browse to a page on your site (using Google Chrome) then right click on the page, and then click on “inspect”, like this:

And you’ll see a load of information appear!:

Then press Command+Shift+P (Mac) or Control+Shift+P (Windows, Linux, ChromeOS) and the command menu opens:

At the prompt type:

coverage

Then click on “Show coverage”:

And a new section will appear at the bottom of the page:

If you click the record button you should see a list of scripts loaded by the page (you may need to reload the page):

And if you click on a script the section above the list of scripts will change and show you the actual Javascript. It also colour codes which parts of the script are being used and which aren’t being used (red is unused, blue is used):

OK, so I’ve used a CSS file to illustrate this point, but the same can be done for the Javascript (js) files as well.

So that’s how you find out what the unused Javascript is, but what can you actually do about it? Edit the scripts directly? Well, I suppose you could do that, if the scripts are loaded locally from your site, but then again, that could be a lot of scripts, and would your changes be overwritten if you update? Probably.

Also look at the script at the top of the list:

That’s not even loading from my site, it’s loading from gstatic.com so I couldn’t edit that even if I wanted to.

At this point you might be wondering why I’m covering all this. There is a reason, though, honest!

The point is that you need to know what’s doing what. You’re going to need this information so that you can determine a course of action to be able to work out what you can actually do about this.

With regard to Google’s advice on what you can do about “reduce unused Javascript”, here it is:

“Consider reducing, or switching, the number of WordPress plugins loading unused JavaScript in your page.”

Although this sounds vague and unhelpful, they’re not wrong with this guidance. The more plugins you have, the more Javascript you’re likely to have in your page output, and the greater the chance of there being a greater amount of unused Javascript in your page output.

“But, but, but I need that plugin to do the doohickey with the whatdyacallit!”

Do you? And do you need it on EVERY page? That’s what the above helps with, answering just that question.

How to remove unused Javascript on your Wordpres site.

Before we get stuck in to this, I’ll make mention of this now:

THINGS ARE LIKELY TO BREAK.

Yep, that’s right, you’re probably going to break parts of your site when trying to remove unused Javascript.

You would most likely be best to clone your site on to a development URL, or at the very least take a backup (or make sure one is available) and ensure you know how to restore it before continuing.

Although I’ve covered quite a lot of “working things out” above, there can still be quite a trial and error element to removing Javascript from your page output. You’re going to need to make changes and test as you go, and if you make some changes, then further down the line realise something has broken, are you going to know which change to revert?

Now I’ve got that out the way, let’s get started.

First things First – See the Full HORROR.

Disable your caching plugins. Check that they are properly disabled (uninstall them if you have to).

The reason for doing this is because you want to see exactly what’s going on with your site and it’s page output, so that you can tell what’s making Javascript load (as mentioned above). Caching plugins can (if configured to do so) combine your site’s multiple Javascript files in to a singular file, and minify them to remove unnecessary characters and whitespace. If this combining and minifying is taking place, it makes it harder to work out what Javascript is being generated by which aspect of your site.

Disable unused plugins.

I’ve already made mention of uninstalling plugins. If you have any plugins in place that you’re no longer using (or if you no longer require the functionality they provide), go ahead and uninstall them. 

This can also help with “reduce server response time” as a removed plugin’s code won’t be called when a page is requested, where as an installed plugins code will (even if you’re not using it to actually do anything on site pages).

Not all site builders are created equal.

Different site builders will add differing amounts of unused Javascript to your site’s code.

Quite a few people that cover this topic mention Elementor being bloated and adding too much unused Javascript. I’ve mostly used the free version of Elementor, and I’ve been able to address unused Javascript to a reasonable degree (enough to get good performance audits in https://pagespeed.web.dev/). Then again, I don’t use a huge amount of Elementor’s functionality, and I tend to use different plugins for galleries, contact forms and pretty much anything else that isn’t an image or standard page formatting (paragraphs, titles, bullet point lists etc) to separate out functionality by plugin. I’m not really sure if using Elementor’s full functionality would be more likely to make more unused Javascript be loaded by site pages, but there does seem to be some negative noise around Elementor in this capacity (although I haven’t directly experienced this myself). Divi is the other page builder that I’ve read about that can also be Javascript heavy, but as I don’t use Divid myself, I can’t really comment.

Although switching between site builders would mean having to remake page content (for all pages), it may be a measure that you find you have to undertake to be able to completely eliminate unused Javascript. Also, you’re not going to know if your page builder is causing a lot of unused Javascript until you’ve made your site’s pages.

3rd Party Code.

There’s some 3rd party code that you might really need, and be able to do something about, such as Google Fonts and Google Analytics. 

Making your Google Fonts load locally can prevent the 3rd party code aspect, AND the Javascript used when calling Google Fonts externally. There’s a post covering how to make Google Fonts load locally here.

The CAOS plugin can be used to host Google Analytics locally as well. It’s just a case of installing and activating this plugin, then clicking on:

Settings > Optimize Google Analytics > Enter your Analytics ID in the “Data Stream Measurement ID” field > Save changes and update:

After carrying out the above you’ll then, most likely, need to remove how you added the Google Analytics ID originally.

In addition to the above there’s some 3rd party code that you can’t really do much about other than remove the content calling the 3rd party code. I’m talking about things that call actual content (not just Javascript) from external sources. These might be page elements such as:

• IFrames (a lot of people use these to display Google Map locations).
• Review widgets.
• Social media feeds.
• Chat and customer support plugins.
• Embedded videos.
• Embedded calendars.
• Pop ups and opt in/out forms.
• Payment gateways.

Quite often these elements won’t just call the content you see from an external source, they’ll also be calling Javascript from the external source. As your browser has to download and process this code for the page to be rendered, this external aspect means that part of the work your browser does to display a page is caused by code that comes from an external source. Due to the code being external you don’t have much control over it.

I appreciate that if you have any of these on your site you might be reading this thinking “but I need those!” (especially the payment gateway if you’re selling online). Some of this code your site will indeed need to operate as you want it to, so you can’t completely remove it, but there are some things you can do about this, just by being a bit sensible about things.

If, for example, you’ve embedded reviews and Google Map locations in the footer of your site, that’s going to cause a lot of 3rd party code to be present on all site pages (and it all adds up!). You could consider putting the Google Map location(s) on your contact page, and having a separate “What our customers say” / “Testimonials” page and putting the reviews on this page alone. Separating the 3rd party code out on to specific pages limits where this code is placed.

You could potentially employ a similar methodology with a payment gateway specific 3rd party script, by only allowing the script on page that it’s actually needed… which I’ll cover next.

Managing Javascript assets (blocking specific scripts).

This is probably the part that you actually wanted to read, as it covers how to get rid of Javascript on your site.

This is also the part that is going to break things, so please make sure you’re either doing this on a staging site, or at least have a backup available to restore from should things not go well.

We’re going to be using the Asset CleanUp: Page Speed Booster plugin to block Javascript and maybe CSS as well.

This can be quite trial and error in approach unless you know exactly what Javascript is used by what aspects of your pages. The rough methodology is:

1. Install and activate this plugin.
2. Enable blocking rules for commonly present Javascript that isn’t always used.
3. Check your site, see if loads OK if it does go to step 5, if it doesn’t…
4. Remove some of the blocking rules set up in step 2, then go to step 3.
5. Scan your home page.
6. Block everything site wide (site breaks when you do this).
7. Incrementally unblock scripts on until your homepage loads as expected.
8. Check the additional pages on your site for aspects that don’t work.
9. Add “on this page” exception rules to allow some of the blocked scripts to run on pages that aren’t functioning correctly to restore the desired functionality.
10. Repeat steps 8 and 9 until all pages load and function correctly.

As you can probably tell there’s going to be a lot of trial and error, testing, checking, unblocking scripts, blocking them again, unblocking other scripts and so on. This can take quite a while to sort out. There’s also going to be a lot of site breaking going on as well.

It’s basically, block scripts, check site (or specific page), unblock scripts to make site load and function OK. This is effectively applied 3 times:

• Initially to commonly present aspects of WordPress that aren’t often used, then,
• To your site’s home page, then,
• To the other pages on your site.

You’ve got quite a repetitive task on your hands, delving deeper in to your site with each repetition.

I can’t specifically tell you exactly what you can and can’t block, as this all depends on what you’ve used to make your site, and how much of the combined respective codebase is actually being used (there as too many variations to cover!).

Let’s start with the “Site wide common unmloads” these are the common aspects fo WordPress mentioned above.

After installing the Asset CleanUp: Page Speed Booster plugin, click on “Asset CleanUp” in the menu on the left hand side, then click on “Settings” and then “Site-Wide Common Unloads”:

You can use the sliders on this page to disable scripts that are commonly present in WordPress that aren’t often used. After enabling some of these (or all of these) rules to unload the respective scripts, you’ll need to click the update button at the bottom of the page to save your changes, and you’ll then need to check your site to see if it still works. You may need to revisit this page and disable some of these rules (to allow some of the scripts to load) if your site’s pages don’t load correctly with all the unload rules enabled.

It can be a bit trial and error (enable some rules, see what happens to your site, disable some rules see what happens to your site) working out what you can disable.

Generally speaking the objective is to enable as many of these rules as you can without affecting the appearance or functionality of your site.

Once you’ve enabled as many “Site wide common unloads” as you can without breaking your site, you’ll need to work out what else can be blocked (or unloaded) to reduce the amount of Javascript and / or CSS that your site includes in page output. 

Now we move on to the 2nd cycle of blocking and checking, and the best place to start with this is your site’s homepage.

To do this hover your mouse over “Asset CleanUp” in the menu on the left hand side, then click on CSS/JS manager:

You’ll then need to wait a moment while the Asset CleanUp plugin retrieves and lists the CSS and Javascript assets used by your site’s homepage.

Once the list has been retrieved, you’ll see about 30-40 (maybe more) “assets” (these might be Javascript or CSS) called by your site’s homepage.

On the same line as each asset, there’s a “Unload site-wide” option:

This “Disable site-wide” option disables the asset across all pages.

If you tick the “Disable site-wide” option for all assets, then click the “update” button at the bottom of the page, the assets won’t load for any of your site’s pages, and your site will then look something like this:

Nailed it!

I’m kidding. If you now select “Tools” in the menu on the left hand side, then click the “Debugging” tab, you can see some URLs that are handy to use when working out what you’ll need to turn back on (the one ending in ?wpacu_debug is the one we’ll be using). 

If you click on the URL ending in ?wpacu_debug then you’ll see your broken homepage load with some additional options at the bottom. The two options I’ve highlighted can be used to disable the unload rules specific to CSS and Javascript, which will at least give you an idea of what’s broken the page (a lack of CSS or a lack of Javascript, or both):

Although using the options mentioned above can give you an idea wether the “Unload site-wide” rules you need to disable are for CSS of Javascript, you might find that it’s a mixture of the two.

Now it’s a case of working out what rules you need to disable for your site to load as it should.

You can disable and enable site wide blocking rules in the CSS/JS manager section. There can be a lot of potential rules that can be applied to block a lot of scripts, so you’re going to need to do a lot of scrolling down on this page.

As you’re in the 2nd cycle of blocking and checking, make sure you’re working on your site’s homepage so that you can get an idea of what needs to be loaded (or not unloaded) for your homepage to function and appear as it should:

Again the objective is to have as much disabled as you can without affecting your site’s homepage’s appearance or functionality.

You’ll need to do something like disable a site wide blocking rule, check your homepage, see how it looks, still broken? Re-enable the site wide blocking rule, disable a different one, check your homepage…. repeat, repeat, repeat.

It’s a good idea to keep some notes about what needs to be allowed and what can be blocked when disabling and enabling site wide blocking rules, as this will save you time in the long run.

Also, you may find that groups of rules need to be enabled for the homepage to load and function as it should. This is because there are “parent” and “child” scripts. The child scripts depend on the parent, so if you unload a parent the child is also unloaded as well. Consequently if your site needs a child script to be loaded to function, the parent script needs to be loaded as well. Luckily, the Asset CleanUp plugin does tell you if the script is dependent on a parent or if the parent has child scripts that depend on it, along with the option to ignore the dependency rule and load the child script anyway:

It’s going to take quite a lot of trial and error to find out what’s needed (not unloaded) and what isn’t needed (so can be unloaded) for your homepage to appear as it should.

Once you’ve removed unblocking rules that prevent your site from loading correctly, you’re going to end up with your homepage loading OK appearance-wise, with a selection of site wide blocking rules in place that don’t affect how your homepage appears.

Appearance is one thing, but functionality is another, so you may need to check that your homepage functions (not just loads as it should). This depends a bit on what you’ve published on your homepage, so I’ll try to add a bit of context to this statement.

On my homepage I’ve got a contact form. Even though the page is displaying OK, the contact form might not function (due to disabled Javascript rules), so I then need to repeat the same process, disabling and re-enabling site wide rules until my contact form functions. You’re likely to need to take a similar approach, but it will differ according to what you’re using on your site’s homepage.

In the end, you’ll have a selection of enabled “disable site-wide” rules, and your homepage both loading OK AND functioning OK.

What you’ve arrived at is a set of “disable site-wide” rules that allow your homepage (and possibly other pages on your site) to both load as it should, and function as it should.

I had to turn off 7 (out of 41) “disable site-wide” rules for my extremely basic homepage to load OK, which goes some way to showing how much CSS and Javascript can be called by a page compared to how much is actually used.

Now you’ve got your homepage sorted out, and a base set of disabled site wide rules in place, you can move on to the 3rd cycle of blocking and checking. This covers all the other pages on your site. You’ve already made your job slightly easier by establishing what needs to be unblocked for your home page to display and function correctly, so you’re not going to be adding any more blocking rules at this point, just removing blocking rules to allow the rest of your site’s pages to load OK. This is handled on a per page basis.

In the Asset CleanUp menu on the left hand side, click on “CSS/JS Manager” then click on “Pages” in the main portion of screen:

In the “Load assets manager for” you can type things like page titles or IDs to find pages. For example, if I want to disable some rules for the Gallery page on my site, I’d type Gallery in this field, wait a moment, then click on the green line of text that appears (which can take a minute):

I’ll then be presented with a list of rules that are disabling CSS and Javascript on this page. Next to each rule there’s a “Make an exception from any unload rule & always load it:” section with an “On this page” tick option. This can be ticked to disable the site wide blocking rule for just the page that you’re working on:

The process of disabling rules until the page both appears as it should, and functions as it should is the same as the one undertaken when getting your home page working.

One page down… now you need to repeat the process checking all the other pages on your site, removing blocking rules where required to ensure all site pages both display and function correctly.

Yes, this can take a while to get on top of. It’s going to involve a lot of disabling (then maybe re-enabling) and checking pages. I say “then maybe re-enabling” because if you disable a blocking rule, and there’s still an issue with one of your site’s pages, there’s no point in that specfic rule being disabled, and the rule being disabled will result in more unused Javacscript.

How far you take this is pretty much up to you. At one end of the spectrum, you could disable as much as possible (without affecting appearance or functionality) across all site pages. At the other end of the spectrum you could simply disable the blocking rules for everything that your site needs to function (although how effective this would be when it comes to blocking unused Javascript is rather questionable).

It’s strongly advisable to check that everything works as it should after blocking any scripts using this plugin.

In conclusion.

• There’s no one size fits all answer when it comes to addressing unused Javascript.
• Javascript is used to provide a variety of site functionality such as animation and user interaction orientated aspects.
• The more plugins and the more Javascript your page builder uses, is likely to result in there being more unused Javascript. on your site’s pages.
• The Javascript your site uses isn’t tailored to what you’re doing or how you’re working, it’s specific to the functionality of a plugin, your site’s theme or the page builder you’re using.
• Javascript isn’t always limited to the page on which a particular function is used.
• Parts of Javascript files that aren’t used contribute to unused Javascript, but as other parts of the same file may be used, so you can’t always completely eliminate all unused Javascript.
• Too much unused Javascript negatively affects pagespeed’s performance audit.
• There are tools available in Google Chrome that can be used to see what Javascript is used and what isn’t.
• Minimising the amount of Javascript files universally can help reduce the total Javascript overhead, which can hep minimise the amount of unused Javascript.
• Plugins such as Asset CleanUp can be used to block Javascript, but this can be a lengthy trial and error process, and it’s imperative to check your site functions as it should do after blocking Javascript.