In this video post I’m talking about Plugin Load Filter which is a free plugin from the WordPress repository. It allows you to deactivate unnecessary plugins on individual pages and posts to speed up your site.
I group these plugins together as they focus on deactivating plugins, but there are others that prevent loading unneeded scripts and disable other unused WordPress functionality.
First a warning
It is very easy to break your site with these plugins and sometimes not be aware. You do need to put a bit of work in to reap the benefits and if you have a good cache plugin you may hardly notice the front end speed improvement. Additionally, if you plan to use Plugin Load Filter for WooCommerce I found it breaks the ajax “add to cart” loading on shop pages (if you have this turned on). Worth checking any WooCommerce extentions using Ajax too!
Also, of course, with freebies, and potentially endless configurations, there is a limit to the support we can expect on such plugins. In this case, the author is not familiar with WooCommerce and being Japanese has limited English.
That said, with my basic set up I see enough advantages of using Plugin Load Filter to make the downsides worth while.
Why I’m using Plugin Load Filter?
Much of this is related to things I’ve mentioned in earlier videos. Recently I set up a new boilerplate site to start all projects. It included on-boarding videos and project management within the site we are developing. The plugins used for this were only needed in the admin site, but were adding some additional queries to the front end (these were WP Admin Pages PRO, WordPress Editorial Calendar and Better Notifications for WP).
Also recently I had been measuring the back-end resources used by favourite plugins. In particular I had a dilemma over Gravity Forms. It’s an incredibly powerful plugin that has worked faultlessly for me for many years. But many sites I make only have one basic form and there are much lighter alternatives. The Plugin Load Filter solves that issue.
Generally, I found its removing 20-25 queries from the front end of most pages of my boilerplate site. The main advantage to me is in the speeding up of my page builder (Beaver Builder) when logged in and working on the front end. I’m using this plugin with caution knowing that I can centrally deactivate it across all sites (in my case via MainWP) and everything will be back to normal.
Setting up the Plugin Load Filter plugin?
When activated it adds a sub-menu to plugins in the admin navigation. Click though and you get a screen like the one below. This list all the plugins that are active and they default to “Normal Mode”.
From here you can set individual plugins to work on the admin side (“Admin Page”) only or filter by Page (“Page Type”).
Most will probably want to tick the boxes to exclude Post Format Type. They’re not an often used feature of WordPress which was inspired by Tumbr (now owned by Automattic). You save the setting by clicking on the Filter Entry button.
Next you need to go to the tab for Page Type Filter Activation. By default all is not active (grey). This means it is deactivated across the site. However you can turn them to green activate them in all areas or just some. It will pick up on any Custom Post Types running.
Note this third screenshot is from a different site. You will see the blue tab colours is not showing on on the site there was a few alignment issue with the UI.
Lastly we can activate or deactivate plugins from the back-end of individual posts of pages. Above I had set WooCommerce to be active everywhere and Gravity Forms to be deactivated. On this contact page I am able to reverse this.
URL Filter for Experts
For simplicity I skipped over the section that allows you to deactivate the REST API, Heartbeat and Ajax. The main reason is I am not an expert! But also wonder if there are better ways than trying to set all these plugin by plugin:
Disable WP REST API by Jeff Star allows you to turn this off for non logged in users who may not need it. The reasons for doing this are: to conserve server resources, minimise potential attack vectors and prevent content scraping.
- The Heartbeat API was added in WordPress 3.6. It allows your browser to communicate with the server. You will have seen this in action if you have ever been working on the same page as another and get a notification saying so. The downside is it is checking every 15 seconds and these execution are increasing CPU use. There are various snippets to allow you to disable or reduce the number of calls. It is probably safe to do this on most site where there is only one user. This is on my list of things to test. Particularly the Heartbeat Control plugin:
- Ajax is something that makes sense to adjust on a plugin basis. I have heard of issues with some plugin using admin-ajax.php incorrectly creating spike. My understanding is if admin-ajax.php doesn’t show up on the waterfall of a speed test there’s not an issue (at least in terms of front end speed). If it does you need to deactivate and reactivate each plugin to find the culprit. In terms of the back-end the Heart API uses admin-ajax.php so possibility that is the main area of concern.
If you deactivate and reactivate the plugin go to the main setting screen and save again (the Filter Entry button). This should see it is fully working again.