Remove unnecessary plugins on corporate

[jpmckinney]

[jpmckinney]

FYI @beneverard and @georgneu

[jpmckinney]

Deactivated and deleted WP Migrate, which loads on admin requests but isn't needed (last used Nov 2025).

[beneverard]

@jpmckinney I'm busy on another project at the moment but I'm seeing a range of changes here that I don't cannot validate in real time, and your latest comment regarding WP Migrate is incorrect, it's used frequently for copying content to staging and local environments, can this be re-instated please.

[beneverard]

@jpmckinney I'm concerned about the removal of plugins (is this being tested on a staging environment?) as some being removed will fully break the website.

[jpmckinney]

Nothing relevant to the frontend is being removed without testing.

To copy to staging or local, I use a different solution that doesn’t involve a plugin that gets loaded every time by WP Admin and slows down the admin (many requests take 5-10s).

I’ll share the docs in a bit - it’s just a single command.

[beneverard]

I'm a little surprised that this has been removed without consultation, I'd have liked to have had an input given we use this daily (speaking in general terms) as part of our established development process. For me that matters.

Does your research show how much of an impact this plugin had to performance?

[jpmckinney]

I can restore it no problem.

I’ll post numbers when I’m back at my desk.

[jpmckinney]

Do you actually use Site Kit pages via WP Admin? If not I’ll get the snippets rendered on pages without that plugin.

[jpmckinney]

For context, @georgneu had asked me to look into the admin's performance, as comms is planning on doing a number of updates over the next week, and requests were taking 5-10s, which was too slow.

So, I first looked at non-WordPress solutions (all in #568):

• I tuned opcache, because with present settings it was full. With new settings, it has headroom and isn't churning.
• I added a Redis object cache, initially with w3tc, then with Redis Object Cache. With w3tc, WP-CLI bypasses the object cache unnecessarily, which matters for cron events (and for any devops work, including my diagnostics/benchmarking).

(Note that w3tc now warns incorrectly about an object cache - I can make the warning go away, but I'm also considering using an alternative plugin to w3tc that better fits with Cloudflare.)

I also looked at MySQL, but didn't find any bottlenecks there. Using an object cache reduced the numbers of queries, though.

Then, I looked at WordPress solutions that would be completely invisible (still in #568):

• Delete autoloaded options and cron events that belonged to deleted or disabled plugins
• Properly disabled comments and pingbacks, as bots were submitting some, costing CPU

I also checked Apache and Cloudflare and found some things to do (#645), but these weren't major contributors.

Performance is still bad, so all that's left is reducing PHP execution time, which means looking at plugins.

(Note that www.open-spending.eu's admin is fast.)

---

As a relevant side note, OCP's posture is that the priorities are, in order:

• External users' needs
• Internal users' needs
• Devops' needs

Devops-related plugins use CPU cycles on every admin request. Those that can be removed would be the first to go.

---

Regarding WP Migrate, the only trace I saw originally were migrations in Apr 2024, Oct 2025, Nov 2025. Looking again, I see you export to a file, selecting 45 out of 85 tables, and replacing URLs and paths.

Plugins cause PHP to do one or more of: load files, parse files, execute files, load autoloaded options, load other options, etc. WP Migrate is 179 files (1M) and has 1M of options. Small, but I figure might as well cut devops plugins first.

I'll share my command shortly in case you don't mind switching to it so that we can leave WP Migrate omitted. Otherwise, the critical options were exported to the home directory at wpmdb_settings.json and wpmdb_profiles.json.

[jpmckinney]

Now that I have a local deployment I can do more precise timing. With all plugins disabled, the admin is as fast as open-spending.eu (whose plugins are small and fast) - 0.05s to load dashboard on my machine. This reconfirms what I established: the plugins are slow (0.37s to load dashboard) - it’s not OCP having more posts, pages, media, users etc. or a bigger database.

ACF + WPML (and especially the ACFML bridge) contribute the most, especially on page/post lists (1s on my machine). I think all we can do is:

• change the default list length to 10 (or even 5), to save 25-50% of the load time.

I also tested with Kadence Security enabled (a bit more finicky to run locally) and it contributes a flat 0.4s on my machine on every admin screen. Wordfence is lighter. I’ll open a separate issue.

The remaining 15 or so plugins outside the ACF-WPML families don’t contribute as much, but since we can’t cut ACF/WPML, I’ll follow up with any that can be cut to at least save a little time.