Skip to content

Analyser

Autoloaded options analyser

WordPress loads every autoloaded option early in each request. Paste the list from WP-CLI and see the total, the largest rows and the prefixes they share, before you decide what to change.

Run this with WP-CLI on the site (or staging) and paste what it prints. The article's SQL query works too.

wp eval 'echo "option_name,size_bytes\n"; foreach ( wp_load_alloptions() as $name => $value ) { echo $name, ",", strlen( is_string( $value ) ? $value : serialize( $value ) ), "\n"; }'
If the list has no header, its sizes are in

Nothing you paste leaves this page: the analysis runs in your browser.

The report appears here.

Example

Autoloaded options worked example

Paste this illustrative sample into the analyser. acme_forms is a fictional form plugin invented for this example.

+----------------------------+------------+
| option_name                | size_bytes |
+----------------------------+------------+
| acme_forms_entry_log       | 305880     |
| rewrite_rules              | 214532     |
| cron                       | 188120     |
| widget_custom_html         | 96410      |
| wpseo_titles               | 41280      |
| theme_mods_storefront      | 28650      |
| acme_forms_settings        | 12044      |
| woocommerce_permalinks     | 1406       |
+----------------------------+------------+

The analyser reports 8 options totaling 888,322 bytes, shown as 867.5 KB. The status is critical because the total is over Site Health's 800 KB limit. That Site Health check was added in WordPress 6.6.

OptionSizeShare
acme_forms_entry_log305,880 bytes34%
rewrite_rules214,532 bytes24%
cron188,120 bytes21%

These are the three options at or above 150,000 bytes, so the analyser flags them as large. In WordPress 6.6+, 150,000 bytes is the default for wp_max_autoloaded_option_size when an option is saved without an explicit autoload choice.

How to read the report

Start with the total. At 888,322 bytes, this example is already beyond the Site Health limit, so reducing the autoloaded set is worth investigating. Then inspect the largest single rows. Here, three options account for most of the total.

Next, look at prefixes. The largest groups are acme at 317,924 bytes across 2 options, rewrite at 214,532, cron at 188,120, and widget at 96,410. A repeated prefix can point you toward one plugin or feature.

What large options usually mean

A plugin log or history stored in an autoloaded option is a strong candidate for review. In this sample, acme_forms_entry_log is the clearest example.

A large rewrite_rules option can follow from many custom post types or registered rewrite rules. Deleting rewrite_rules is not the fix. WordPress rebuilds the option from the rules registered by themes and plugins, so you need to find what is generating the excess rules.

A large cron option usually means many scheduled events. Run wp cron event list and inspect the hooks, schedules, and ownership before changing anything. If admin requests are also slow, use the slow WordPress admin guide to check related causes.

Transients can be stored in wp_options when there is no persistent object cache. Do not treat every transient row as an autoload problem, but do identify which component creates unusually large or numerous values.

How to reduce autoloaded options

  1. Back up the database and work on staging.
  2. Find the plugin or theme that owns each large option, and where it is read.
  3. Change the autoload flag through WordPress rather than a direct SQL update: wp_set_option_autoload_values() (WordPress 6.4+) also invalidates the caches it should.
  4. Measure peak memory and uncached TTFB again, and test the owner's admin and front-end flows.

Measuring and reviewing autoloaded options explains each step and the WordPress 6.6 changes.

Find out which plugin owns an option

Send me the largest rows and I will say which ones I would look at first, and how to change them safely.