Optimize WordPress by controlling the options autoload setting

If you've ever taken a good look at the WordPress database, you may have noticed that the options table features an autoload column that can assume one of three values: on (or yes), off, or auto.

As the name implies, options that have their autoload value set to on/yes are pre-loaded on every request, while those who are set to off are only loaded whenever they're invoked through a get_option function call.

The good news is that, in both scenarios, the functionality will stay intact, and the system is structured so that it won't break if an option is not part of the pre-loaded group.

In recent years, though, WordPress Core has put some work into how options are loaded, and that's when the auto value was introduced: it allows WordPress to independently determine through a set of heuristics whether the option has to be loaded or not.

In an optimized system, the preferable strategy regarding the loading of the options would be to have the minimum amount of autoloaded options, for both memory consumption and performance reasons.

The problem is that WordPress is a plugin-based system, many of which declare their own set of options in the database, and leave them there even if they are deactivated.

As a result, you may find yourself polluting your options query with data from a plugin that you deactivated two years ago, simply because its options had the autoload value set to on (until June 2024 it was the default), but even if those options aren't automatically loaded, forcing WordPress to spend computation cycles to determine whether to load something or not is detrimental to the request.

If you care about performance and optimization, there are a couple of things that we can do on this subject:

1. If you're managing a WordPress install, consider installing a plugin made by Joost de Valk that allows you to individually set the autoload value for those options still in your database, but that may not be required anymore.
2. If you're a plugin developer, make sure to set your less-needed options to off, and register a deactivation hook for your plugin to clean up its data.

If you don't know, a deactivation hook is nothing else than a function that gets executed whenever a particular plugin is deactivated. For example, this what we're going to introduce in one of our upcoming updates to Advanced Columns:

// __FILE__ is a reference to the main plugin file

register_deactivation_hook( __FILE__, function() {
	global $wpdb;

	// Making sure that Advanced Columns options aren't loaded on every request.
	$wpdb->update( $wpdb->options, array( 'autoload' => 'off' ), array( 'option_name' => 'advanced_columns' ) );
} );

Conversely, we'll activate that option back upon plugin re-activation:

register_activation_hook( __FILE__, function() {
	global $wpdb;

	// Since we consider probable that Advanced Columns options are needed,
	// we set their loading to be automatic.
	$wpdb->update( $wpdb->options, array( 'autoload' => 'on' ), array( 'option_name' => 'advanced_columns' ) );
} );

For those of you wondering, the reason why we're using the $wpdb global object instead of the options API is that, when using the API functions, the value for the autoload column is updated only if the option value itself has changed.

Ultimately, deciding whether to enable autoload for an option is a choice that developers must make based on their assessment of how likely the information in that option will be needed frequently: if you deem that probable, you can keep autoloading stuff, but if you are unsure about that, do your website a favor and begin turning some options off.