WP Asset Clean Up Plugin Removes Unused Styles and Scripts

photo credit: SergioMonsalve - cc
photo credit: SergioMonsalvecc

In 2010 Google patented its methods for using resource load times in ranking search results. The published patent describes how Google factors in page speed when presenting results:

A search result for a resource having a short load time relative to resources having longer load times can be promoted in a presentation order, and search results for the resources having longer load times can be demoted. The demotion can, in some situations, result in a search result for a resource having a short load time being presented earlier in the order than a search result for a similarly-relevant resource having a longer load time. Thus, for two resources that, apart from load times, appear to equally satisfy a user’s informational needs, the user will often select the resource that will likely load the most quickly of the two, resulting in a better user experience.

In other words, when it comes to competing resources that might seem otherwise similar, the one that loads faster gets a higher ranking. Prioritizing site speed is not only important for Google rankings, it’s also critical to providing the best experience for visitors.

The new WP Asset Clean Up plugin addresses an often overlooked aspect of improving loading times. The plugin allows you to selectively remove unused styles and scripts from any page or post on your site. Once activated, the plugin detects all assets loaded and displays them on the post/page editing screen. You can then select the assets that are not needed for that page.


I tested it and found that it works as expected. It’s especially handy for home pages and content like “about” and “contact” pages where you don’t need to load as much functionality.

WP Asset Clean Up is developer Gabriel Livan‘s first free plugin on WordPress.org.

“I’m sure you’ve used themes / plugins in the past that were loading lots of assets (.css and .js files) in the front-end in pages where you only needed half of them or even less,” Livan said. “Many people have articles about making WordPress faster, but they often overlooked this part of removing the unused files. Often these are minified by caching plugins, but using the plugin I’ve developed, the minifying will be even smaller.”

As long as plugin/theme authors have properly enqueued their assets, WP Asset Clean Up will be able to detect them so that you can select them for removal. The plugin helps you decrease the number of HTTP requests loaded but can also be useful for minimizing script conflicts. You can download WP Asset Clean Up from WordPress.org and use it in combination with your favorite caching plugin to improve performance.


75 responses to “WP Asset Clean Up Plugin Removes Unused Styles and Scripts”

    • Thanks, looking forward to improve the plugin and make it become popular. I’ve been downloading freebie plugins for years. It’s my turn to give back.

      Regarding, WP Engine’s caching machine, it shouldn’t conflict at all, as if their engine is smart enough and follows the standards (it should be for a company of their level), then the caching will work fine.

      I’ve tested it with W3 Total Cache and WP Rocket and as expected, it worked fine. The caching is made after all the plugins are loaded and the assets enqueued/dequeued which is normal.

      I will keep an eye on this and make sure there won’t be any conflicts with cache plugins.

  1. -1000

    Instead of plugin authors producing good code, it somehow becomes the responsability of the site owner to clean up the poo, and how can he even know what is needed and what not? Maybe that “unused” CSS is needed to displays error message when ajax fails? And what happens after the plugin was upgraded, are you supposed to repeat the process?

    In any case, the idea that an unused JS files actually slows your site is ridiculous and shows lack of understanding how browsers work and what are the real performance bottlenecks.

    • Yes, enter the ecosystem of WordPress. Most of the code is pretty much crap, I’ve even seen well respected community developers struggling with things like bower and composer.

      The problem is also the WP core itself and its assets loader – it encourages every plugin to add their own bunch of css and js files. And author plugins usually do that globally (site-wide) and not conditionally (only where needed).

      • Sure code quality is mixed across the board. But framing it as ‘most of the code is crap’ is lazy and actually, not the root cause.

        And when you say ‘well respected developers struggle with things like bower and composer’, this is actually highlighting a general painpoint with managing complexity and various scripts from different sources on any platform.

        Let’s respect the problem that developers have to deal with for its true degree of difficulty. It is simply hard to manage dozens of dependencies, scripts and assets and make them load only when needed (regardless of the platform). WordPress is in that respect is one of the hardest environments to code for because each install tends to have a unique environment, with different plugins, a different server situation and so forth.

        It’s tough to optimize in a way that doesn’t cause issues. And it’s tougher now that many sites are piling on clientside javascript functionality which can lead to situations where you don’t know when a script is going to be needed or not without being clairvoyant (if you pull in a fragment of some page asynchronously which relies on a unique script).

        Core’s asset loader does not encourage every plugin to add their own bunch of css and js anymore than cutlery encourages people to eat. It also doesn’t stop from people eating sloppily to continue the analogy.

        But it does create some level of sanity in managing assets, without which things would be a true mess. But if hundreds of assets are being registered and enqueued, it doesn’t matter how good the API is it’s not going to wave away the mounting complexity.

        Having said all that, there is a lack of awareness on how to load stuff only when needed and developers often don’t optimize as much as they can. I wonder if part of this is lack of instructional resources about conditional loading. The other part I think is simply because it takes a fair amount of thought and knowledge.

        Also the scripts and styles API does need to be updated for 2016 and onward, right now it falls short of current needs. It works great for sites that are predictable and where the server does the work. But for js heavy sites, you often want conditional loading capabilities. Right now we don’t have such a solution in core that extends the existing APIs.

        To give an example. One interesting part of the emoji functionality (which I otherwise hate) is that it monitors for emojis on the page before loading stuff using the MutationObserver api. Similar techniques could be used to load css/js for other kinds of usecases.

    • @mark k. – Webmasters / Developers should use their common sense when unloading .CSS and .JS files. If their are not sure if the asset will be used or not, then they could leave it to load. Plenty of themes and plugins are loading assets site-wide. It often takes time and effort to put conditions in the code and make tests and many authors, just don’t bother with it. And I’ve seen very popular themes and plugins loading lots of assets when you only need only half or even none of them to load on specific pages.

      “In any case, the idea that an unused JS files actually slows your site is ridiculous and shows lack of understanding how browsers work and what are the real performance bottlenecks.” – I believe any HTTP request that is prevented from loading (when not needed) is an advantage: less files to load (some of them can be from slow external resources), cleaner HTML code (good if you’re a developer and scan your source code), better visitor retention, cleaner Apache log file etc.

      @Primoz Cigler – Yes, plenty of the code from the ecosystem of WordPress is crap. I’ve seen some that aren’t even using the WordPress way of enqueuing styles and scripts. They are hardcoding it which so annoying. In a future version of the plugin, I will edit the code to also print all the assets that aren’t loaded correctly to notify the admin.

      • Modern browsers use IIRC 17 threads to load assests. As long as the assets are not blocking the cost of the additional requests in terms of page performance is virtually zero. You will get much more boost in performance by using CDN like cloudflare. The plugin is a solution to a problem that doesn’t actually exist or there are better solutions for it.

        And you basically manipulate how the plugin/theme works and this is equivalent to changing the plugin/theme code which might have implications on the stability of the plugin/theme after upgrade. If the plugin author decided he needs a script S on all pages who are you to tell that he doesn’t, without actually reviewing the whole code of the plugin?

    • I agree with Mark K. This is the kind of optimization people do when they have no idea how to do real optimizations. An unneeded asset loading is indeed a concern, but assuming you’ve already done the actual headers for proper browser caching and use cdns and the like, then removing it brings little to no benefit.

      This sort of thing matters once you pass the 10k hits per second mark. Not before that.

    • @mark k. – The site owner or site developer should have an idea when a feature is used. There a couple of time where is difficult for the plugin author to know when a feature/shortcode is used. I have not yet found a way to detect if a widget is being used on a page. I can only know if a widget is being used but that could be on any page. Another example is content saved in metaboxes using a plugin like ACF.

      It is not a simple as it may seem.

      • The API to detect if a widget is being use is is_active_widget. shortcodes are a little more complex but removing a JS/CSS just because you at one point in time do not have the shortcode or widget on page is idiotic because in an hour you might want to have it but what is the chance you will remember to remove it from the “bad assets” list?

        It is actually not hard at all for a plugin or a theme author to write proper code. No excuses should be accepted for bad one. If it is hard to do things properly with ACF then guess what, just don’t use ACF.

        • The API to detect if a widget is being use is is_active_widget.

          The problem with is_active_widget is that it will return true if the widget is active on any page regardless if it is present on the current page or not. http://stackoverflow.com/a/11060324/850651

          …just because you at one point in time do not have the shortcode or widget on page is idiotic because in an hour you might want to have it but what is the chance you will remember to remove it from the “bad assets” list?

          Perhaps it would be best to wait till you have finished making large content changes before you start optimizing it.

          It is actually not hard at all for a plugin or a theme author to write proper code.

          I don’t see how technical constrictions make a plugin bad. We are not talking about code quality. I feel it is not right to just say if a script/style is being loaded on every page then the plugin sucks.

          If it is hard to do things properly with ACF then guess what, just don’t use ACF.

          Most plugin authors want their plugins to work with most other plugins and not restrict user with which plugins they can use it with. The point was not about ACF but custom meta fields themselves. It is very difficult to know when a shortcode is added in meta field.

  2. I did not find any setting in the plugin, but it add a top level menu in admin, I don’t understand why, if there is nothing.

    Anyway I am getting this on any page:
    “We’re getting the loaded scripts and styles for this page. Please wait…”

    So I am still waiting when it will finish his job ;) I will inform you the day when it comes :)

    • The only settings available are on the Home Page and you just have to click on “WP Assets Clean Up” menu link on the left side of the Dashboard.

      If nothing loads even after you refresh the page (sometimes the internet connection can time out after you loaded the edit post/page), then check the “Console” and see what errors you’re getting. It’s likely a plugin or something else is interfering with the AJAX calls that are being made.

      PS: If you could create me an account that allows me to use the plugin on your blog, I can check it myself and let you know the problem. It could be conflicting with other plugin, but I need to be sure.

  3. This SOUNDS like a great idea and I’m sure someone will execute it “better”, soon.

    I did some testing this morning, on the archive of The WordPress Helpers ( http://wordpress.answerguy.com ), choosing that site both becuase it’s frozen and because it’s pretty darned complex.

    The tool never worked; it was given a very long time (over 20 minutes) to discover assets and nothing ever happened, on the two pages the plug-in recognized (blog and home).

    I completely accept that it never working could have been a result of either the site’s complexity or the way the theme is written, or both; that’s just how WordPress is, and that’s fine.

    But think about it: it only recognized a main construct (there are other “pages”), and one archive page of posts (and again, there are others).

    Bad enough if we stop there, but now think about the actual value of a tool like this: yes, it needs to be pointed at specific assets to be meaningful, but that very likely renders it nothing more than the cool idea it certainly is.

    Hoping for more , soon …

    • Thanks for your feedback, Jeff! I wish I could test the plugin on your website as an admin. I’m positive I would make it work and would help other people which have similar sites as well.

      To ensure that no other plugins interfere with it and all the HTML code is loaded, “WP Asset Clean Up” sends an AJAX call to the page through POST and then it gets the list of all assets that was collected and prints it at the bottom of the page. Then the list is fetched and shown in the edit post/page.

      The tool only works with pages/posts (custom post types too) and the home page. Later on, I will update it to include other pages as well.

      What exactly did you mean by “it recognises only one construct”?

      I’ve just released it and it works fine on all my websites. Unless your theme or a plugin prevents some AJAX calls (that are not through admin-ajax.php, otherwise it will get slower), it should work fine. I will definitely check this as there was other person mentioning about it (not showing up the list).

      PS: I am seriously considering adding the list in the front-end too, below the page, that will be visible only to the admins. This way you don’t have to go to the “Dashboard” and it will save you a few clicks.

      • Gabriel, I’m certain you could make it work, but unless the academic exercise feels useful to you I dunno if trying to do that makes sense on a site we’ve stopped updating. THAT SAID: please feel free to contact me on jeff answerguy.com if you’d like me to set you up an admin account to try.

        my “main construct” reference referred to the fact that your tool recognized my home page and the (main) archive. It didn’t recognize other pages OR other archives and we have both. So (exactly 1) page … the “main one”, and exactly one post … the main one. And then, nothing

        (which might well be related to the discovery issue, eh?)

  4. No joy here, either. It’s not finding any assets. I’m using Genesis on all my sites. I’ve disabled the Speed Booster Pack plugin just to be sure. For the Home Page (accessed via the top level Admin menu), it’s either not finding any assets, or just plain not showing up. On one site, as with Jeff and Peter above, it’s spinning away looking for assets and that’s about it.

    I’d sure love to have the features this plugin offers as I have so many scripts and style sheets that just aren’t used on many pages.

    • Thanks for trying it, Scott!

      I’m using Genesis too on one of my websites and it works fine. It looks like some people are having this problem and I need to understand what is causing it. Perhaps a plugin or something in the theme. I’ve tested the script on localhost as well as on all my websites and didn’t have any problem like that. I’m also using plenty of the popular plugins out there.

      If you could load an edit post/page and have a look at the “Network” (when you access “Inspect element”) and tell me if you see any errors (perhaps the AJAX call is not completed), that would be very helpful to me!


      • Gabriel, thank you for your response. I see that the plugin has been updated since this morning. Following your advice, I didn’t see any errors, but I did see *many* requests that were cached. I use Cloudflare, so putting it into Dev Mode to disable caching made it work. I’ll give it another try soon and be mindful of flushing the cache as I experiment. Thanks again!

      • @Scott, it seems that you’re not the only one mentioning about Cloudfare incompatibility. Can you tell me what plugin are you using for Cloudfare? I wish you could create me a temporary admin account for your website so I can check it out. I want to make this plugin work with Cloudfare on too as so many people are using it.

  5. Just thinking out loud – a nice feature (certainly for single posts, where a blog might have them in the thousands) would be to identify script that has been highlighted several times as not used on any posts.

    So, for example, contact form script that isn’t used on posts but shows up. Or appointment plugin script that is only used on one post, and could be allowed to remain, while the rest of the posts remove it (if that makes sense).

    So, a standard check box with the option “Remove from all single posts”, perhaps?

    • Yes, I have it in my mind. Updating manually each post/page can be painful if you have thousands as you said. A list that will show up and you will select the assets that will not load and apply to all of them could be a good idea. Then, you can manually go to edit one or two posts that might need it. Moreover, even better would be to select the posts exceptions that will not be updated, thus saving you more time. One step at a time, a feature like that will be available.

      PS: In your opinion, wow would you see a premium version of this plugin?

    • @Tai, thanks for the comment.

      I usually develop the plugins with WP_DEBUG true, though on this occasion I’ve noticed that it was turned off. There were some notice errors I’ve seen and they will be removed on the next version of the plugin. Good catch!

      In terms of functionalities to disable WordPress core scripts: imagine a clean and light page where no jQuery is needed at all or other scripts loaded by WordPress.

      Why would you not remove it if you really know what you’re doing? jQuery and jQuery Migrate are both fairly big JS files. I know, you’re probably thinking that people by mistake can select it. But thinking this way, many mistakes can be done in the WordPress Dashboard if one is not paying attention to what he/she is doing.

      What I believe would be good is to highlight the WordPress core scripts in the list and to issue a warning to the admin about the possible consequences if that script would be disabled. As a developer, I prefer to have the option to remove any script I want if I don’t need it.

      It’s a good point overall. What do you think about the plugin? Have you tried it on a few pages?

  6. Unfortunately, most of the discussion here has completely missed the point.

    First, dequeuing styles and scripts is not about boosting speed. (It might sometimes have that effect, but it’s not really the reason for doing this.)

    Second, the need to dequeue is not about improving “crap” code. Plugin developers can’t know what else is going to be used on a site on which their plugins are used.

    Third, the notion that this involves “rewriting” a plugin is ridiculous. Would you say that about adding custom CSS that overwrites what is included in a plugin? Of course not.

    Dequeuing is important for keeping posts and pages “clean.” Why does that matter? Because it is an important means of avoiding conflicts.

    In other words, this plugin is designed to provide a tool — note: tool, not master — with which a site owner or developer can turn off certain styles and scripts, so as to avoid them breaking another plugin.

    I run several complex sites and, while I am not a coder, I have learned how to dequeue stuff so that otherwise-conflicting plugins can happily co-exist.

    The alternative would be to go into the plugin’s own code and add conditionals. Now that really would be rewriting a plugin, and those changes would be overwritten on an update. So having a separate dequeuing function is far superior.

    So I like the idea of this plugin. But I have a question:

    When setting up my manual dequeuing, I have noticed that plugin authors often use the same names for their styles and scripts. (scripts.js is a particular favorite.) This means — at least for me, as a non-coder — that I can’t selectively dequeue one of these scripts without dequeuing them all. Is this plugin able to differentiate between assets with the same name? (Of course, if someone is able to tell me how to do it manually, then I’m all ears too.)

      • On my tests, any duplicated handle name will not be printed by WordPress. So the first one that was enqueued by any of the plugins will be taken into consideration.

        If the handle name is different, then it will be printed even if the URL to the script/style is exactly the same.

        Any plugin/theme developer with common sense should use unique names for the handlers anyway, so I don’t see in this to be a problem at all.

    • Third, the notion that this involves “rewriting” a plugin is ridiculous. Would you say that about adding custom CSS that overwrites what is included in a plugin? Of course not.

      I assume you are referring to what I said, this obviously depends on a plugin, and if you can run it in a “no css” mode then I will assume that almost no harm may happen, but plugins which rely on say a P element having a 20px top margin might break if you remove that style rule or change it. The problem most likely will not be apparent when you make the change, but when you upgrade the plugin. JS is obviously even worse in this regard.

      So yes, if you change styling you will need to test every plugin upgrade to still work well with your changes as there is no way a plugin author can test all the possible modifications people might make to the plugin’s CSS.

      • Of course you need to test, @mark k. But that’s to be expected even if you don’t dequeue assets.

        After all, even apart from functionality changes, it’s also quite possible that the plugin author has made a change to his or her CSS or JS that could produce an unexpected effect on a site.

        So, for a well-managed site, dequeuing doesn’t change the upgrade workflow at all.

  7. Hello, Friends,

    I just installed the plugin as I think it is VERY useful. But as an amateur I quickly realised that I would probably need to understand the inside of the WP web site much better to decide which assets I can turn off. Or is there some way how to know even when I am not a WP guru?

    Thank you very much! Pavel

    • Thank you for your feedback, Pavel! That’s a good question and you’re not the first one telling me about indecision regarding which assets to load.

      To me it’s like second nature: I quickly look at the list and then I just select the ones that I know are not loading in that page. That’s because I know which plugins I use and what the theme is loading. I’ve added details to the asset such as the handle, URL, where it loads (BODY or HEAD) and any inline code associated with it. I had the impression that this will enough. I guess it’s not that simple if it’s not your website and you have developers doing the coding for you.

      The plugin will get better and I will provide more details about the assets and even automated tips. It will be more understandable for non-developers. Once I will add more features on the free version, I will likely develop a premium extension as well to make it from good to amazing.

      For now, I suggest you consult a developer (the one who worked on your website ideally) to help you in removing the assets that you don’t need.

      You can remove some of them yourself easily. For instance, “Contact Form 7” plugin. If you know it’s loading only in the contact page, then you can unload its assets (there were 2 files last time I check, a .css and .js file) from other pages. Later on, in a new release of the plugin, there will be an option to unload assets site-wide and only enable them in a few pages you need. One step at a time.

      Good luck in using this plugin and make sure you properly test your uncached pages after you unload assets to make sure you don’t have any errors if you unload the wrong assets by mistake!

  8. Hi,
    First of all thanks for making that type plugin.
    I installed and using this plugin on my website. Everything was great but I found a issue in this plugin. I’m unable to deselect the selected CSS & JavaScripts to make them load again. Please fix this issue.

    Rakesh Lohan

  9. The plugins says “The following styles are loading on this page. Please select the ones that should NOT LOAD”, but I don’t what styles could be unnecessary to load!!

    Much better, if the pluging would have said “The following unused styles are loading on this page, …”


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: