Poor plugin performance can be caused by many things, but there is one thing that will definitely increase your plugin’s performance: conditional loading. Allot of WordPress plugins load their code on every page, or actually on every request.

By loading all your plugin code on every request you are

• decreasing overal site performance
• decreasing security
• increasing the chance on a conflicts with other plugins
• increasing the chance of unexpected behaviour (read bugs)

Obviously this isn’t something you should be doing since it’s really bad practice. Luckily it’s pretty easy to avoid this.

Separate frontend and backend code

The easiest and most effective form of conditional loading is separating your frontend and backend code so you can only load code that will actually be used. Once you’ve separated your code you can load only front- or backend code by using the is_admin() method.

An example on how to do this:

if ( is_admin() ) {
	// Load your backend code
} else {
	// Load your frontend code
}

Only do your admin actions on pages they’re needed

Makes sense right? If you need to setup a database check for an admin page, only do that check on that page. Well, allot of plugins will end up doing this check on every admin page. They’re hooking onto ‘admin_init’ what will result in their action being ran on every admin page load. Not something you want to do, see the above list why.

After you’ve added your menu (or submenu) page, the method you’ve used to do so will return the resulting page’s hook suffix. With this hook suffix you can bind an action that will only be fired when the page loads that you’ve just created.

An example on how to do this:

$page_hook_suffix = add_menu_page( $page_title, $menu_title, $capability, $menu_slug, $function, $icon_url, $position );
add_action( 'load-' . $page_hook_suffix, 'my_callback' );

function my_callback() {
	// This method will only be fired on your page
}

Print admin scripts on a specific admin page

If you’re using above hook (the load-page_hook one) only to print some JavaScript on your admin page, you could also use the ‘admin_print_scripts-‘ hook. Using this hook saves you hooking into ‘admin_print_scripts’ in your ‘load-page_hook’ hook (hookception?). Anyway, long story short, this saves you a hook.

An example on how to do this:

$page_hook_suffix = add_menu_page( $page_title, $menu_title, $capability, $menu_slug, $function, $icon_url, $position );

add_action( 'admin_print_scripts-' . $page_hook_suffix, 'my_callback' );

function my_callback() {
	// Print admin scripts
}

Load admin scripts on a specific admin page

Finally you can also load your admin scripts on a specific admin page. Hook into ‘admin_enqueue_scripts’ and check in your callback if you’re on the correct page.

An example on how to do this:

function my_enqueue( $hook ) {
	if ( 'edit.php' != $hook ) {
		return;
	}
	wp_enqueue_script( 'my_custom_script', plugin_dir_url( __FILE__ ) . '/myscript.js' );
}

add_action( 'admin_enqueue_scripts', 'my_enqueue' );

Please note that to simplify the examples on this page, they’re written in procedural code. I would always recommend you to choose an OOP setup in your plugin.