There’s one thing here you shouldn’t do:
add_filter( 'pre_site_transient_update_core', create_function( '$a', "return null;" ) );
add_filter( 'pre_set_site_transient_update_plugins', create_function( '$a', "return null;" ) );
add_filter( 'pre_site_transient_update_themes', create_function( '$a', "return null;" ) );
In my testing, this slowed down the admin side of the site significantly on a fresh local install. This is because if the the transients update_core
, update_plugins
, and update_themes
are not found, they go back to object cache for an answer. If you’re not using object cache which isn’t setup by default, the request goes all the way back to the database.
I did some rough benchmarking on a fresh install. A typical admin request calls one of these transients up to 17 times in a single request. When you’re logged in and looking at the front-facing site it can be up to 5. That adds up.
Fortunately, Jason Jalbuena has found a better way:
function remove_core_updates () {
global $wp_version;
return(object) array(
'last_checked'=> time(),
'version_checked'=> $wp_version,
'updates' => array()
);
}
add_filter('pre_site_transient_update_core','remove_core_updates');
add_filter('pre_site_transient_update_plugins','remove_core_updates');
add_filter('pre_site_transient_update_themes','remove_core_updates');
Source: https://jasonjalbuena.com/disable-wordpress-update-notifications/
This works because it does not remove the transient, it only replaces it with values that trick WordPress into thinking the check has happened and nothing needs to be updated.