wp_options Autoload Audit: Measure What WordPress Loads on Every Request

A wp_options autoload audit answers a narrow but important WordPress question: what configuration data is being loaded before the request has even reached the page, plugin screen or checkout operation the visitor actually needs?

Autoloaded options are not automatically bad. WordPress, themes and plugins use them for settings needed during startup. The problem appears when large, obsolete or poorly designed values join that startup path on every request. The wrong response is to sort the table by size and start deleting. The safe response is to measure, identify ownership and test one reversible change at a time.

Autoload Is a Startup Decision, Not a Junk Label

The wp_options table stores core, theme and plugin settings. An autoload decision tells WordPress whether an option belongs in the group loaded during startup. A large value may be legitimate because an active component needs it. A small value may still be obsolete. Size is evidence for investigation, not a deletion instruction.

Stored autoload values also vary across WordPress history. Current APIs and WP-CLI understand modern values while older rows may still contain legacy forms. Do not build a cleanup around one assumed database value. Ask WordPress which options are currently treated as autoloaded.

Measure the Total Before Judging Individual Rows

WP-CLI provides a read-only total for the active site’s autoloaded options:

wp option list --autoload=on --format=total_bytes

Record the command, time, environment and result. The number needs context: a persistent object cache can change how often the database is queried, but it does not turn unnecessary configuration into good ownership. Compare the total with uncached request behaviour, PHP memory pressure and the actual problem being investigated.

A database inventory can show which values exist without deciding which stored labels count as active autoload values:

SELECT autoload,
       COUNT(*) AS option_count,
       SUM(LENGTH(option_value)) AS total_bytes
FROM wp_options
GROUP BY autoload
ORDER BY total_bytes DESC;

Use the real table prefix for the site. This query is an inventory only; WP-CLI remains the safer way to ask the running WordPress version which options it considers autoloaded.

List the Largest Options Without Assuming They Are Wrong

After the total, list the largest active candidates:

wp option list \
  --autoload=on \
  --fields=option_name,size_bytes \
  --orderby=size_bytes \
  --order=desc \
  --format=table

Capture the top rows, then ask what each option belongs to. Names often provide a clue, but prefixes are not proof. Search the active codebase, plugin documentation and controlled configuration history. Check whether the component is active and whether the option is read before deciding that it can stop autoloading.

Prioritise rows that combine three signals: meaningful size, unclear ownership and no confirmed active requirement. A large option with a known owner may be lower risk than a smaller row left behind by a removed component. The audit ranks questions; it does not manufacture certainty.

Find the Owner Before Changing the Value

Every candidate needs an owner and a reason. Classify it as WordPress core, active plugin, active theme, custom code, removed component or unknown. Unknown is a stop condition, not permission to experiment on production.

• Confirm whether the related plugin or theme is active.
• Search code for reads and writes of the exact option name.
• Check whether the value contains a cache, index, ruleset or essential configuration.
• Record whether the data is serialized or otherwise structured.
• Identify who can verify the affected feature after a change.

Editing serialized data manually is especially dangerous because lengths and structure matter. Use the owning application’s supported method or WordPress-aware tooling whenever possible.

Separate a Backup From a Rollback Plan

A backup is a copy. A rollback plan explains how to restore the specific option, who will do it and how quickly the affected feature can be checked. Before changing anything, export the exact row and confirm there is a current database backup that can be restored.

wp option get example_option --format=json

Some options cannot be represented neatly as JSON. The point is to capture the original value through a method that preserves it, not to force every row through one command. Record the original autoload state as well.

Write the rollback command before the forward change. The operator should know the exact value and autoload state to restore, the person authorised to restore it and the feature that proves the rollback worked.

Change One Option and Test Uncached Requests

Select one candidate with clear ownership and a defensible reason. Use the supported WordPress function or tool to change its autoload behaviour. Do not alter ten rows and then try to guess which change caused the failure.

Test the homepage, login, administration screens, forms, checkout or booking paths, scheduled tasks and the feature owned by the option. Clear only the caches required for a valid test. Compare the same uncached request measurements taken before the change, then watch error logs and application behaviour.

Watch for Object Cache and Multisite Context

A persistent object cache can make option access faster, but it does not remove the need to understand what is loaded and retained. Include cache configuration in the evidence so a database improvement is not confused with a warm-cache effect.

Multisite adds another boundary. Network-wide settings can live outside the individual site’s options table. Confirm whether the investigation concerns one site or the network before changing anything.

Turn the Audit Into Ongoing WordPress Ownership

An autoload problem often reveals a wider maintenance problem: old plugins, abandoned experiments and custom code have left configuration nobody owns. The durable fix is an option register for large or unusual values, a review after major plugin changes and a before-after measurement during migrations.

NinjaWeb can connect this work to managed WordPress hosting, web hosting and wider business-system support. The value is not deleting rows. It is knowing what WordPress loads, why it exists and how to change it without gambling with the live site.