Whenever you unload certain CSS/JS files, you expect to either see an immediate increase in the Google PageSpeed Insights / GTMetrix score or not loaded when you test the page in Incognito (visiting it as a guest, while you’re not logged-in). However, this doesn’t always happen. Here are a few known causes:

1) You’re using a caching service such as Cloudflare or a page caching such as WP Rocket and its caching hasn’t been cleared

Although you prevented certain useless CSS/JS files from loading (reducing the number of HTTP requests), and they are not loading while you test the page (being logged-in) and the page is lighter as it should be, the situation might not be yet the same when your visitors visit the page or when you test the website through a tool that measures the page speed score. This is likely because your visitors are accessing an old version of that page due to the page caching (whatever number of layers it might have). If you’re using WP Rocket and Cloudflare (and you also have the page caching enabled there), then you have to make sure that whenever you make a change in Asset CleanUp, the page caching is fully cleared in whatever services you might be using. It’s not recommended to use too many page caching solutions one of the reasons being the fact that it’s harder to manage all the page caching layers (e.g. you have to make sure they are all cleared correctly at the same time).

Remember: If you’re using Cloudflare’s Cache Everything, make sure it’s not showing to your visitors, the pages that are meant to be shown to the logged-in admin (e.g. with the admin bar showing at the top). If you have content that is the same for both users (and the top admin bar, toolbar, is not shown), then it should be fine, otherwise, it’s very likely you need to use the option “Bypass Cache on Cookie”. Read this following post for more information about this: https://www.namehero.com/startup/why-cloudflare-cache-everything-isnt-a-good-idea/

One way to know if the Asset CleanUp’s changes were applied, is to apply a unique random string (that you never used before) to the target URL. For instance, if you optimized the homepage, you can append to the URL something like this: https://www.yourdomainnamehere.com/?wpacurandomstr12345. This will force (in most cases, unless the page caching service is ignoring certain query strings, it shouldn’t) the loading of a new page, never loaded before and if you notice the changes are applied correctly there (no more useless CSS/JS that you marked for unloading), then it’s a matter of time until all the pages will have the new changes because the caching hasn’t been cleared yet.

2) You forgot to deactivate “Test Mode”

If you’re optimizing a page and you’re not sure whether the changes you applied are alright (e.g. you might be worried that you have marked for unloading a file that might be needed to load after all in specific scenarios), it’s recommended to enable test mode. This way, all the changes will be applied to you, the logged-in administrator. However, if you left the “Test Mode” enabled and visit the page in Incognito (or when you’re not logged in), then no Asset CleanUp changes will be shown to the guest visitor (e.g. in case you have unloaded the wrong CSS files). If everything is alright on your end, then you can deactivate “Test Mode” and the plugin’s changes will be visible to everyone.

There is a way to skip test mode and have the page loaded with the changes you made by appending /?wpacu_skip_test_mode&a_random_str__here to the targeted page. Note that this is relevant just to test Asset CleanUp’s changes, and not to be used on Google PageSpeed Insights or other tools as the page will be non-cached and things like page caching and other ones like Combine CSS/JS will not take effect because of the query string (e.g. WP Rocket doesn’t cache pages with this type of query string). Basically, appending query strings are to be used to determine if there are changes applied to the page, and not to determine the page score (the page has to be cleared of query strings for that).

3) You have added loaded exceptions somewhere that you forgot about, keeping the CSS/JS files loaded on the targeted page

Case scenario: You know that you have a CSS file that you don’t need on most pages. You marked it for site-wide unload, but added a rule to load it based on the RegEx. It could be that the CSS file will not load on any page, except the pages that contain the word ‘product’ in the URI. Perhaps you forgot that your target URL contains “product” and the CSS file has to load. In this case, you need to change the RegEx rule or use a different rule to reach your goal.

4) You applied the following rule when edited the post/page and forgot about it: “Do not apply any CSS & JavaScript settings

Just make sure that you do not have this within the “Asset CleanUp Pro: Options” meta box. It can happen accidentally, perhaps you intended to tick the option above which is “Do not combine JS files on this page” or you have applied the rule to the targeted page a long time ago and forgot about it. Things like that do happen once in a while as the plugin has lots of options and it’s easy to forget about old rules.

5) The targeted page is part of the ones where Asset CleanUp should not trigger at all via the option “Do not load the plugin on certain pages”

Sometimes, in pages that are meant to be uncached, such as the “Cart” or “Checkout” page, it’s better to prevent Asset CleanUp from triggering any rules (read more here: https://www.assetcleanup.com/docs/how-to-exclude-the-plugin-from-loading-on-certain-pages/). Hence, the option “Do not load the plugin on certain pages” from “Settings” -> “Plugin Usage Preferences” is there to help you with this. Perhaps one of the rules set there (e.g. the RegEx type) in the text-area is also capturing the targeted page.

Was this post helpful?