If you’re trying to get good pagespeed results, this is one of the more annoying/frustrating issues to sort out.
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.
- 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)
You’re most likely using WordPress so that you don’t have to write code (aren’t we all?).
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.
- 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.
The page above mentions two things that can slow your site down, here’s the first:
Make sense so far?
The second sentence on the Google page linked to above reads:
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!”
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?
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”:
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).
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.
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:
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):
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.
“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.
Before we get stuck in to this, I’ll make mention of this now:
THINGS ARE LIKELY TO BREAK.
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.
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).
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.
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.
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.
- 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.
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.
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.
- Install and activate this plugin.
- Check your site, see if loads OK if it does go to step 5, if it doesn’t…
- Remove some of the blocking rules set up in step 2, then go to step 3.
- Scan your home page.
- Block everything site wide (site breaks when you do this).
- Incrementally unblock scripts on until your homepage loads as expected.
- Check the additional pages on your site for aspects that don’t work.
- 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.
- 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.
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:
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:
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).
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.
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.
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):
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.
It’s strongly advisable to check that everything works as it should after blocking any scripts using this plugin.