Any need to deactivate backend plugins in frontend too?

Hi @evalast

many thanks to you for your nice words.

FDP disables the entire plugins, not only the assets, so if a backend plugin adds database queries also on the frontend, by disabling that plugin you will gain in terms of performance. When the page is served by the cache, you have no difference, but when the page is not served by the cache you may notice a difference.
The difference depends on the plugin that you disable. You may have 0 difference, but also a huge difference.

Well-coded plugins that add functionality only to the backend should consume zero on the frontend, but this is only in a perfect world. In the real world, even popular and loved backend plugins add database queries on the frontend.

For example, let’s assume plugins A, B are for the frontend, and plugin C is for the backend.
If on the frontend you disable plugins, A, and B it’s the same as disabling A, B, and C in terms of consumption of FDP. So to decide between disabling also C on the frontend you should consider this:

– How much do I gain in terms of performance? => It depends on plugin C. If it’s perfectly coded, you gain zero, if it consumes something even without doing anything, you may gain something.
– What do I risk if I disable plugin C on the frontend? => Nothing. You have only to win. Maybe you win nothing, but you may win something, and usually, you never lose.
– Does FDP consumes more if I disable more plugins? => No, it doesn’t. The only thing that happens is that FDP writes more data in the database, but usually, this hasn’t a noticeable impact on the database size. The time needed by FDP for detecting the plugins that it should disable is practically the same.

Moreover, if you more plugins you disable, the lower is the risk that a plugin gives you conflicts with other plugins. You also reduce the “PHP surface” that may be exploited by hackers. I mean, if with all plugins active you have 5000 lines of code that are parsed (a completely random number just for an example), the probability that part of this code can be exploited by hackers is higher than having only 1000 lines of code. The same for risks of fatal errors. The fewer plugins you have, the lower is the risk of having conflicts and problems.
The only thing that you should always pay attention to, is to don’t disable plugins that should run because other plugins depend on those plugins. But this is both for frontend and backend. The higher risk that you have when you selectively disable plugins is that.

I suggest you always have a look at the preview (lens icon), and if the page works without problems, disable the backend plugins, and save the options.
I also suggest you perform a speed test without cache, with and without the backend plugin. If the results are different, it means that the plugin consumes something on the frontend.

Take also into account that the quality of a plugin is not constant. You may have a plugin that consumes 0, and the same plugin after an update gives conflicts on the frontend, or for some reason adds queries to the database that was not added with the previous versions.

In my case, I prefer to disable all that it’s not needed. I even don’t ask myself if it is worth it. If I don’t need a certain plugin, I disable it, because I have nothing to lose by doing so.

If you are interested in how much a well-coded backend plugin consumes on the frontend you can read this blog post: https://josemortellaro.com/how-much-a-plugin-that-works-in-the-back-end-slows-down-the-front-end/

So, in short, in a perfect world, I would say it’s the same in terms of performance if you disable backend plugins on the frontend, but in the real world, you may find important differences, depending on the quality of your backend plugins.

I hope it helps.

• This reply was modified 2 years, 9 months ago by Jose.

Hi Jose – thx for the detailed answer. After reading all of your input i think im goin the same path as you by disabling everything i do not need. Im building a ecommerce site and im very selective with plugins – less is more.

How do you update plugins and theme which are depending on others? Should i run a live cloned stagging site to check anything before doing the same on the production site? thx a lot – no need to write as long as before. Im sure im able to understand your short version too. Save your time for more important stuff. best

Hi @evalast you are welcome!

Yes, my answer was a little long ??

Having a staging environment is always a good practice. The higher risk you can have on a website is in my opinion when you update a plugin, the theme, or the core. Better you do it first on the staging environment, and if you have issues you have time to fix them without impacting the live site.

How do you update plugins and theme which are depending on others?

If B depends on A, I first update B, then A, because B cares about A, but A doesn’t care about B (at least usually not, or less).
This doesn’t mean that updating B before A guarantees no issues, but I would say statistically you should have fewer issues.
B and A can be a plugin that depends on another plugin. A plugin that depends on the theme. Plugins and theme that depends on the WP core.