In short, no! Due to the nature of the web pages and the way the CSS/JS code is connected to them, there’s no tool that would predict with 100% accuracy without any manual intervention if a certain asset is loading on a page without having any of its code triggering on that page.
Now, there are tools such as Coverage from Google Chrome that can help you out in watching in real-time what portion of the code is needed or not while you navigate on that page.
Coverage only shows the unused percentage of the CSS at the moment of the page loading. In order to make sure that all used CSS is reported, certain actions on the page have to be performed including:
- Hovering over the links
- Expanding a mobile menu
- Resizing the browser window to mobile view as there could be media query rules that would trigger just for mobile
- Loading content asynchronously (without page reload via AJAX calls in the background) which has layouts that are calling CSS code that was initially reported as unused
It’s likely that after you do all these (depending on the website you’re working on, it might not retrieve portions of the page without page reload via button clicks) then you will notice that the percentage of the used CSS is getting higher. That’s pretty much the right percentage of used/unused CSS.
Coverage from Google Chrome is quite accurate in detecting the right unused CSS. However, sometimes, it doesn’t detect fonts that are used within @font-face and it marks them as unused when in fact are used and font (usually icon types) loaded within CSS pseudo-classes. This shows that no tool is perfect and sometimes something reported as 100% unused can be in fact needed. Fortunately, this is very rare, but it does require you to be aware of it.
What you can do is go through the CSS & JS manager and mark the CSS that is shown as 100% unused to be unloaded from that page. After the unload, check the page if everything loads in the same way. Then you continue to the next CSS having a 100% unused percentage and so on. This is the trial and error you have to go through to make sure the page loads exactly the same way.
One WordPress core CSS library is the Gutenberg one that is loading site-wide when in fact it might not be needed anywhere. There’s a special post dedicated to it. You can check it out to understand how it’s determined that the file isn’t needed: https://www.assetcleanup.com/docs/how-to-check-if-gutenberg-blocks-css-file-is-needed-or-not/
What about unloading JavaScript files? Is it as easy to determine the used/unused code?
JavaScript files will almost always report used code in a certain percentage on Coverage because it doesn’t work the same way as the CSS one. While CSS rules are directly related to the styling of the page, JavaScript code is read and marked as used even though it’s not needed on a page. For instance, you might have a few global variables (set via “var”) in a file that is meant to be used inside a function. The browser is reading them and their values are kept for later use on the client-side, but that particular function might never trigger on that page at all. The function is marked as unused which is correct, but the variables are marked as used even if they aren’t later referenced on that page. The same goes for JavaScript comments. While they are not needed (e.g. a file can just contain comments if the developer forgot to place JS code in it), they are reported as used by Coverage which can be confusing.
To illustrate this better, I’ve attached a print screen that you can check (you can zoom the image by clicking on it as it will load on a new window for easier reading):
This example is from the file /wp-content/plugins/elementor/assets/lib/swiper/swiper.min.js which is often loaded on all the pages of a website, when in fact, it’s only needed on some of them. There’s even a special post about how it can be unloaded correctly using Asset CleanUp: https://www.assetcleanup.com/docs/how-to-unload-swiper-from-elementor/ – You can notice that the used JS which Coverage reports is the declaration of the variable which is always recorded by the browser in case it would ever be called. However, the actual functions are in fact not called, anything within function() { and } is marked with red. The same goes for the JS comments that were just previously mentioned. They are always showing as part of the “used” code, just like you can notice from the print screen below:
In conclusion, although part of the JavaScript file will always have code that is loaded & interpreted by the browser, it doesn’t mean it will ever be used or needed on that particular page. Even the JavaScript from Contact Form 7 which is loaded site-wide and you know it’s not needed on the homepage (for instance), has “used” code reported by Coverage. When it comes to JS files, you have to know if you need that file to load or not on the targeted page. If you know it’s not needed, you can unload it and then test the functionality of the page.
If you check the dedicated unload tutorial related to Swiper that was just mentioned earlier, you will notice whenever it needs to be kept loaded on a page. If you’re unsure of anything, it’s always recommended to consult with a developer as it’s easy to mess things up if you unload the wrong file. For instance, if you have lots of scripts that depend on jQuery on a page and you unload the jQuery library (which is recommended to keep it loaded in most situations), then this will break the functionality for all the dependant scripts and you will likely end up with a webpage that doesn’t work well (e.g. the mobile menu burger button will not work at all when clicked).
What about large CSS files that are downloaded by the browser, when in fact over 90% of their code is never needed?
There are situations especially with theme files (e.g. Divi’s main style file) where you will notice that over 90% of the code is never used on the homepage or other pages of your site. For instance, the file could be 500 KB in size, when not more than 50KB will ever be needed. That means the extra 450 KB is adding up the total page size and to a negative score for “Remove unused CSS” in Google PageSpeed Insights. Now, chasing every KB is really tricky and hard to maintain in the long term, especially if your page has lots of changes (e.g. new layout added with new CSS styling). However, in some situations, it’s still good to reduce the total page size even by half (e.g. remove 250 KB of unused CSS) and keep some unused CSS there just in case. You need to think about whether it’s worthwhile or not to spend the time creating an alternative lighter CSS file. There’s a hook that you can use to do that in Asset CleanUp and it’s explained here: https://www.assetcleanup.com/docs/how-to-load-an-alternative-lighter-version-of-a-file/