A large autoload total is a performance signal, not a deletion list. WordPress loads autoloaded options early on many requests, so oversized values increase database transfer, memory use and object-cache pressure across front end, admin and cron.
Measure the largest options and total footprint
Record option name, size and autoload state. Compare uncached request time and object-cache behaviour before making changes so you can prove whether the autoload set is actually contributing to the slowdown.
Find the owner of each candidate
Map every large option to core, a plugin, theme or custom code. Check whether that component is still active and whether the value is current. An unfamiliar option is not automatically orphaned.
Distinguish configuration from cached application data
Large permanent settings may be legitimate; large feed responses, logs or transient-like payloads usually need a different storage strategy.
Object cache changes the symptoms, not the ownership question
If Redis is involved, compare the object-cache diagnostic. A cache can hide database cost while still carrying an oversized global object.
Clean only data with a proven lifecycle
Back up the database, use the component’s supported cleanup when available and change autoload behaviour for data that does not need to be global. For suspicious values in the same table, the separate guide to unexpected payloads in wp_options explains a different incident path.
Verify with the same measurements
Recheck total autoload size, request memory, query time and cache behaviour. Required settings and scheduled tasks must remain intact, and the component must not immediately recreate the oversized data.
WP REPAIR INCIDENT STANDARD
How to narrow the fault without guessing
The total size is a signal, not a deletion list. Each option belongs to core, a plugin, a theme or custom code and may be critical.
Measure total autoload size and list the largest option names.
Map each option to the component that reads or created it.
Check whether the component is active and the value is current.
Compare object-cache hit behaviour and uncached query time.
What must be verified
- Autoload size and request memory meet an agreed baseline.
- Required settings and scheduled tasks remain intact.
- The offending component no longer recreates oversized autoload data.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
Is the total autoload size a reliable list of what's safe to delete?+
No. The total size is only a signal that something is bloated — each individual option still needs to be mapped to the plugin, theme, or custom code that created it before deciding whether it's safe to remove.
Can a deactivated plugin still be slowing down every page load through autoloaded data?+
Yes. Removed or deactivated components frequently leave behind large autoloaded settings that WordPress continues to load on every request even though nothing active reads them anymore.
Is running a generic SQL delete based on option size a reasonable way to clean this up?+
No. Deleting rows based only on size or name patterns risks removing data a plugin still depends on — proven orphaned data should be removed through the component's own supported cleanup process where one exists.
Why would a plugin store cache or log data as an autoloaded option instead of a transient?+
Some plugins misuse the options table to persist data that should be a transient or non-autoloaded value, which causes that cache or log data to be loaded into memory on every single page request instead of only when actually needed.