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.

wp-asset-clean-up

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 Comments


  1. This sounds like a great plugin. I wonder if WP Engine’s caching machine will conflict with it.

    Report


    1. 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.

      Report


  2. This was exactly my idea for the next plugin I wanted to create. I am glad somebody else did it.

    I will give it a try. Is there a github repo for this, so I can check the code and contribute to easily?

    Report


    1. Thanks for giving it a try! If you have the time and you have an account on wordpress.org, I’d appreciate a rating/feedback.

      There isn’t a GitHub repository created, but I’ve been thinking of creating one and if I do it, I will let you know. The plugin is quite new.

      Report


  3. -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.

    Report


    1. 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).

      Report


      1. But I’ve checked the code behind this plugin and it is a bright gem – very well written, respect to the author Gabriel Livan! When I see things like spl autoloader I am confident I can use it without hesitation. :)

        Report


      2. Thanks, Primoz! Even though WordPress doesn’t encourage much the use of OOP, I prefer to add it on my projects. Also, I don’t like the fact that WP is not using the MVC model (separate the logic from the design). Te default themes have blended the PHP code with the HTML one. I guess they were also thinking about the newbie developers that are using procedural code. I even wrote an article about it here: http://www.bitrepository.com/an-mvc-approach-to-wordpress-theme-development.html

        Report


      3. Yes, obviously my beef is not with the plugin, it is with the mentality it might encourage (O there is a plugin for that, I am not going to bother cleaning up my code)

        Report


      4. 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.

        Report


    2. @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.

      Report


      1. 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?

        Report


    3. 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.

      Report


    4. @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.

      Report


      1. 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.

        Report


      2. 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.

        Report


  4. 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 :)

    Report


    1. 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.

      Report


  5. 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 …

    Report


    1. 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.

      Report


      1. 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?)

        Report


    2. Jeff. Answer Guy is one of the best email capture forms I’ve seen :)

      Usually I feel like punching the screen.

      Thanks

      Report


  6. 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.

    Report


    1. 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!

      Cheers!

      Report


      1. 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!

        Report


      2. @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.

        Report


  7. Just tried this out, and shaved some load time off home page due to scripts that were being run from posts. Nice! :)

    Report


    1. I’m glad to hear that, Danny! Some people told me that they aren’t seen the list of assets loading and I believe there are due to some conditions set in the plugin and WordPress settings. I’ve just updated the version to 1.1.4. Can you please check if also the posts/pages are loading the assets besides the home page? Thanks!

      Report


      1. Hi there Gabriel,

        Yep, a new option box appears on individual Posts/Pages in draft/edit mode, asking what scripts you want to stop loading. Nice work. :)

        Report


      2. Cheers, it should not show you any list if your post has the ‘draft’ status (there is a condition in the code for this) as the list is relevant only for published posts/pages.

        Report


      3. If you have a wordpress.org account and have the time, I’d appreciate a feedback for this plugin. I’m in the beginning and doing my best to get a good reputation. I’ve been a developer for years, but decided recently to contribute to the WordPress community and so far things look promising.

        Report


      4. For sure, I usually try and wait a few weeks to iron out kinks, but always happy to provide reviews for devs. :)

        Report


      5. Yes, they are there and the URL is wrong. As some people might get confused, I will update it to make sure they will show after the post/page is published.

        Report


      6. No worries. :)

        One of the things I noticed it doing is switching off display for the Google Analytics Dashboard for WP plugin.

        This is a little widget that’s displayed on my dashboard area, and just gives me a nice overview of traffic, breakdown, etc, without the deep dive of my main GA account.

        Report


      7. That was because of an undefined JavaScript variable in script.js. Google Analytics Dashboard for WP didn’t like it. I’ve installed both plugins and made tests. As a result, I’ve made sure that the code from script.js is loaded ONLY when that variable is declared, thus removing chances of having “surprises” like you had with the analytics plugin. I’ve updated the plugin to version 1.1.4.2 which fixes this and it’s already live. You can update it and it should show you the widget. Make sure you clear the cache of the browser in case it will load the old version of script.js ;-)

        Report


  8. 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?

    Report


    1. 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?

      Report


      1. From early usage, and seeing the potential, I’d be more than happy to support a premium version of this, especially if it comes with best practices for site management (great for non-coders like me), along with recommended plugins and solutions that maximize performance, and how they do it, etc.

        Report


      2. Update: Now there is an option to unload assets per post type. So, if you want to do it for all pages, no problem! Or for all posts, or for specific custom post types ;-)

        Report


  9. @Gabriel Livan Two suggestions: develop your plugins with WP_DEBUG “true” and do not add functionalities to disable WordPress core scripts, e.g. jQuery et al.

    Report


    1. @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?

      Report


  10. Unfortunatelly, it didn’t work on my test site, either, with HeadwayThemes theme (“We’re getting the loaded scripts and styles for this page. Please wait…” forever) as well as to some other members in WordPress Speed Up Group on several of their testing sites (https://www.facebook.com/groups/wordpressspeedup).

    Report


    1. I believe you’re testing an outdated version of the plugin because that message is not anymore “We’re getting the loaded scripts and styles for this page. Please wait…”. There were a few people here mentioning about it, but after they updated the plugin, they managed to see the asset list. I even had an open thread about it here: https://wordpress.org/support/topic/not-working-1546?replies=9 – and it was marked as “resolved”. Can you just update the plugin and let me know if it has the same problem? Thanks!

      Report


      1. I copy-pasted that message from the discussion as I deactivated the plugin and uninstalled it but it was the last version as I installed it 2h ago directly from WP.org. Sorry, but I don’t have more time to troubleshoot it.

        Report


  11. Will other minification plugins like Autoptimze and WP-Rocket conflict?

    Report


    1. I use Speed Booster Pack and its options to optimize CSS and JS interferes with this plugin’s functionality.

      Report


  12. 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.)

    Report


    1. Just to clarify my question, I am asking how the plugin deals with the situation when the name of the handle of the asset is duplicated across plugins.

      Report


      1. 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.

        Report


    2. 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.

      Report


      1. 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.

        Report


      2. yes, but the number of well managed sites is too low :( most people just upgrade whenever they see the notice

        Report


  13. Hi,

    Great stuff. Especially since it’s a free version. Perhaps someone would be interested that there is already a plugin which does the same thing, but it’s commercial called Gonzales.
    https://tomasz-dobrzynski.com/wordpress-gonzales it has advanced features like loading the scripts only on selected pages and so on.

    Report


  14. Good day all. Doesn’t “Plugin Organizer” do the same thing as well? What is the difference?

    Report


    1. “Plugin Organizer” can help you enable/disable a plugin on specific pages. However, if you have a plugin that you need to load in a page and it loads 10 assets, when you only need 2/3, then you can use “WP Asset Clean Up” to unload the unnecessary .CSS and .JS files.

      Report


      1. Ah very good. Thanks Gabriel :)

        Report


  15. 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

    Report


    1. 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!

      Report


  16. 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.
    Thanks

    Rakesh Lohan

    Report


    1. Hello Rakesh,

      Thanks for trying the plugin. What actually happens when you click the selected checkbox? Is it not deselecting then or when you update the post, they show selected again, even though you deselected them? I haven’t had this problem and no one told me about it so far.

      Regards,
      Gabe

      Report


      1. It’s working perfectly on posts.
        But for homepage when we deselect and save it.
        It still shows selected again.

        Report


      2. Please create me a temporary admin account and email be the details at gabe ( at ) bitrepository [ dot ] [com] and I will check what’s the problem. I want to have this working 100% for you.

        Report


      3. I’ve just tested it on the home page and “tipsy” asset (both .CSS and .JS) remained unchecked once I click “Update”. Can you clear your cache and test again? If the problems is still there, it would be good if you can email me some print screens with the exact steps you’re taking to do the update so I can clearly see how you do it.

        Report


      4. CloudFlare CDN was creating problem.
        Plugin is working perfectly after disabling Cloudflare.

        Report


      5. I can’t go to the Dashboard anymore, I wanted to check if you have a WP plugin that connects to Cloudfare.

        Report


  17. 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, …”

    Report


  18. UPDATE: Now unloading of the assets is possible in the front-end too (I found it easier sometimes to manage) when viewing a page, post or the front-page.

    Report

Comments are closed.