How can I diagnose a slow WordPress admin?

Over the past few months the admin pages on my wordpress multisite site (around 80 sites) have been taking around 20 seconds to load. I am running the latest version of wordpress (version 4.1).

When I renamed the plugins folder to “plugins-deactivated” the admin area returned to a usual peppy speed of three seconds. However, when I renamed the folder back to “plugins” the site returned to it’s usual 20 load times. I then deactivated all of the plugins and the admin area remained at it’s usual slow speed, even though the plugins were deactivated.

I deleted all of the plugins and re-uploaded them one by one – the admin slowed with each additional plugin, no matter which plugin I uploaded. The obvious conclusion to draw is that WordPress is loading each and every single plugin whether activated or not.

My question – how can I validate this assumption, and also, how can I further diagnose the problem?

Some other facts

1. The site is a wordpress multisite with approx 80 sites
2. It is running on Windows Azure
3. The problem started in the past few months
4. All plugins are activated
5. I am running the query monitor plugin
6. The installation is about eight years old

How can I find where the slowness originates?

Update 1: I have used the Chrome Dev Tools – and about 95% of the load speed is in the initial Get request – which would seem to suggest that the problem is happening on the server, not any of the ancillary load items

Update 2: The mere presence of the Gravity Forms plugin seems to add about 9 seconds to the load time of the site. It is happening when the plugin is deactivated.

Update 3: I have optimized the database to no effect.

I cannot speak to all plugins loading even when disabled, but gravity forms is not designed for heavy usage and could well be contributing significantly to the problem.

I used to work with a large client that used gravity forms and their admin panels ( and submitting forms ) became so slow that eventually they started timing out completely.

I no longer have the details lying around, but the problem with gravity forms at the time was that when a form is submitted, gravity forms does the following:

• Loads every form that has ever been submitted
• Cycles through each one of them until it hits the end
• Uses that last submitted entry and adds one to generate the next unique id

At the time, I created a patch for the client, tested it, applied it, and submitted it to gravity forms … and never heard back. The next few times the client upgraded gravity forms, it had the same problem and I had to re-apply the patch. I finally got them to switch services.

If you are using a lot of plugins that add extra columns to the wordpress admin panels ( e.g. list posts, list pages, etc. ), I’d expect that to be at least part of the problem is that most plugin authors use queries for each item in the system to modify the list rather than modifying the appropriate admin query to include what they seek in the post results.

BIG WARNINGS

• If you are not completely comfortable with php, do not attempt this.
• If at all possible, do this on a staging server first to ensure you don’t break something
• Absolutely be sure to back up any files you are going to edit before editing them … so you can quickly put them back if needed

That being said, the only thing I can think of that could help would be to termporarily hack the wordpress core as follows:

(if running 4.1):

Enable the debug log and disable public display of errors( wp-config.php ):

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

This will create a debug log file in your theme directory.

edit wp-settings.php and find the following in lines 213 to 216:

foreach ( wp_get_active_and_valid_plugins() as $plugin ) {
   wp_register_plugin_realpath( $plugin );
   include_once( $plugin );
}

change it to the following:

foreach ( wp_get_active_and_valid_plugins() as $plugin ) {
   wp_register_plugin_realpath( $plugin );
   $start_at = time();
   if ( WP_DEBUG_LOG ) {
      error_log("Loading plugin {$plugin}\r\n\t Start: {$start_at}");
   }
   include_once( $plugin );
   $end_at = time();
   if ( WP_DEBUG_LOG ) {
      error_log("\t Finished: {$end_at}");
      error_log("\t Total Time: " . $end_at - $start_at . '(s)' );
   }
}

That will only tell you if any plugin is doing something bad when first loaded.

You could temporarily do the same thing around the do_action(‘plugins_loaded’) command found in the same file at line 237, but that would only tell you how long it took for all plugins to load.

To tell how long each one takes, you could hook into plugins_loaded at priority 1, read all plugins_loaded hooks, update them all to have different priorities, and then add your own plugins loaded action to log the time stamp between each interval.

e.g.

set up all plugins so the first using plugins loaded loads at 10, the second at 12, etc … and then add your own plugins_loaded action between each one to log the time and maybe the time taken at each step:

9: started

11: Best Answerecond (timestamp nnnnnnnnnn)

13: 0 seconds (timestamp nnnnnnn)

15: 8 seconds (timestamp nnnnnn)

I know this probably isn’t a ton of help, but it might at least let you know what the culprit is.

By using the above debug commands, you can then carefully make some temporary edits to the core wordpress files to log how long things take without having faulty plugins crash the site by showing errors on the front end.