WordPress Says “Autoloaded Options Could Affect Performance”—How to Fix It Safely
WordPress Site Health can report a critical issue saying that autoloaded options could affect performance. The warning is useful, but it does not tell you which option is unnecessary, which plugin owns it, or whether changing it is safe.
The wrong response is to delete the largest rows or switch every autoload value off. Some options are loaded on every request because WordPress, the active theme or a plugin genuinely needs them. The safe job is to identify unused or incorrectly autoloaded data, trace its owner, and verify each change on staging.
What are autoloaded options?
WordPress stores many site-wide settings in the wp_options database table. An option marked for autoloading is fetched early and made available during every WordPress request, rather than requiring a separate database query when code asks for it.
That is efficient for small settings used on most pages. It becomes wasteful when plugins place large page-builder data, cached API responses, logs, expired transients or abandoned configuration into the autoload set even though most requests never use them.
The official WordPress performance handbook recommends keeping the total size of autoloaded options under 800 KB. WordPress Site Health uses that total as a warning signal, not as proof that one specific option should be removed.
Why the warning can affect more than page speed
Autoloaded data is involved before WordPress renders a page. An oversized set can increase the initial database work, memory consumption and the amount of data stored in a persistent object cache. Depending on the stack, symptoms may include:
Slow time to first byte on uncached requests.
A WordPress dashboard that feels slower than the public site.
Higher PHP memory use across front-end and admin requests.
Large alloptions cache objects that are expensive to fetch or invalidate.
Intermittent slowdowns after plugin updates or scheduled jobs.
Performance that improves temporarily after disabling one plugin.
If the slowdown is mainly inside the dashboard, compare the warning with Webcurry’s WordPress admin performance diagnostic. A slow admin can also come from remote API calls, database queries, cron or AJAX rather than autoloaded data.
Before changing anything: build a rollback point
Create a database backup and confirm you know how to restore it. Work on staging whenever possible. Record the WordPress version, PHP version, active theme, plugins, object-cache status and the Site Health warning before editing the database.
A backup that cannot be restored is not a rollback plan. If your existing backups are unreliable, resolve that first with the WordPress backup restore failure checklist.
Do not experiment in phpMyAdmin on a busy production site. Options can change while plugins run, and deleting a required row can break logins, URLs, scheduled jobs, licences, payment integrations or theme settings.
Step 1: measure the total, then find the largest contributors
Start with WordPress Site Health under Tools. The total tells you whether the autoload set is large, but optimisation decisions require a per-option list.
Use a trusted host diagnostic, the Performance Lab plugin from the WordPress Performance Team, WP-CLI, or a read-only database query to list autoloaded option names and sizes. On modern WordPress versions, autoloaded values are not limited to the older yes value; core supports values including on, auto and auto-on. A query that checks only autoload = 'yes' can therefore miss data.
WordPress introduced new option functions in version 6.4 and refined autoload behaviour in 6.6. The WordPress 6.6 developer note explains the current values and the safeguards for newly updated large options.
Export a simple audit sheet with the option name, byte size, autoload state, likely owner and decision. Sort by size, but investigate context before acting. Ten medium abandoned options can matter as much as one very large row.
Step 2: identify who owns each large option
Option names often include a plugin, theme or vendor prefix. Search the site’s codebase and documentation for the exact name. Then inspect the feature that created it.
Is the responsible plugin or theme still installed and active?
Does the value look like settings, a cache, a log, a queue or generated CSS?
Is it needed on every public and admin request, or only on one settings screen?
Does the plugin provide its own cleanup, reset or cache-purge control?
Was the row left behind by a migration, staging copy or removed plugin?
Does the option have a recent update timestamp elsewhere in the plugin’s data model?
Never infer ownership from a vague prefix alone. Two plugins can use similar names, and custom code may depend on an option created years earlier.
Step 3: classify the option before deciding
Settings used on most requests
Small site URLs, rewrite settings and core configuration may be sensible to autoload. Removing autoload can replace one shared query with repeated individual queries. Leave required settings alone unless the component’s developer recommends a different state.
Feature-specific settings
A large option used only on a rare admin screen, import tool or report may not need to autoload. The correct fix is normally for the owning code to save it with autoload disabled. Ask the plugin vendor or patch custom code rather than repeatedly editing the database after every update.
Caches and generated data
Generated CSS, API caches and computed data may be safe to regenerate—but only through the owning plugin’s purge or rebuild action. Deleting the row directly can produce an outage if regeneration fails, requires credentials or runs only on a scheduled task.
Orphaned plugin or theme data
An option from software that is no longer installed may be removable after a verified backup and dependency check. Uninstall routines are preferable because one component may store related rows in several tables.
Transients and logs
Expired transients should be handled through WordPress APIs or reliable maintenance tooling. Logs and queues should not usually be autoloaded, but deleting an active queue can lose background work. Determine whether the data is disposable, pending or legally relevant before cleanup.
Step 4: change one owner or option at a time
Use the least destructive fix available:
Purge or rebuild data through the plugin’s own interface.
Update or replace a plugin version that writes oversized autoloaded data.
Disable an unused feature that continually recreates the option.
Ask the vendor whether the option can safely be stored with autoload disabled.
For custom code, update add_option() or update_option() to pass an explicit autoload decision.
Remove genuinely orphaned data only after backup, staging verification and dependency checks.
Do not bulk-update every row above an arbitrary size. WordPress 6.6 dynamically avoids autoloading newly updated options over 150,000 bytes when code has not explicitly required autoloading, but that safeguard does not prove that every existing large option is disposable.
Step 5: verify with uncached and cached requests
After each change, clear only the relevant caches and repeat the same tests. Check Site Health, front-end pages, wp-admin, scheduled jobs, forms, login, search, checkout or bookings—whatever the affected plugin controls.
Compare uncached server response time before and after.
Watch PHP error logs and browser network failures.
Confirm object-cache hit behaviour and memory use if a persistent cache is active.
Open the plugin’s settings and perform its main workflow.
Reload several different page types, not only the homepage.
Wait through at least one scheduled cycle if cron or queues are involved.
If one plugin appears responsible, use Webcurry’s controlled plugin slowdown isolation process rather than deactivating random components on production.
Persistent object cache: helpful, not a cleanup substitute
Redis or Memcached can reduce repeated database work, and WordPress notes that persistent object caching helps options load more efficiently. However, the entire autoload set may be held as a large alloptions object. Oversized or frequently invalidated data can still waste memory and network transfer between PHP and the cache server.
Treat an object cache as part of the measurement. Do not use it to hide abandoned data. After changing autoload behaviour, purge the relevant group carefully so the old alloptions object does not make the test misleading.
Common fixes that create new problems
Deleting all transients without checking active queues or sessions.
Setting every large option to non-autoload because it appears near the top of a report.
Running a cleanup plugin without reviewing its deletion list.
Editing WordPress core functions instead of the plugin or custom code that writes the option.
Assuming the warning explains every slow request.
Testing only a cached homepage and declaring the problem solved.
Making a production database change without a tested restore path.
If the database becomes unavailable after a change, the WordPress database connection recovery guide can help separate credentials, server availability and damaged-table problems.
A practical autoload audit workflow
Confirm the Site Health warning and note the total autoloaded size.
Create and verify a database restore point.
List autoloaded option names and sizes using a current, read-only method.
Investigate ownership and purpose for the largest contributors.
Use the owner’s cleanup or configuration method where available.
Change one item at a time on staging.
Test uncached response time, admin workflows and the affected feature.
Monitor whether the option returns after cron, cache rebuilds or plugin updates.
Document the final owner, decision and rollback step.
Conclusion
The Site Health warning is a starting point, not permission to clean the wp_options table aggressively. The safest optimisation removes data that is abandoned or incorrectly loaded on every request while preserving options that genuinely save queries.
Measure the total, identify the owner, understand the value, use the component’s supported cleanup path and verify one change at a time. That process improves performance without turning a manageable warning into a broken production site.
Frequently asked questions
What does “Autoloaded options could affect performance” mean?
WordPress detected that the combined size of options loaded automatically on every request exceeds its Site Health threshold. It signals investigation, not automatic deletion.
What size should WordPress autoloaded options stay under?
The official WordPress performance handbook recommends keeping the total under 800 KB. Treat this as a practical guideline; ownership and usage still determine what can safely change.
Can I delete the largest row in wp_options?
Not safely without identifying it. A large row may contain required theme, plugin, licence, queue or generated data. Trace its owner and use the component’s supported cleanup process.
Should every large option have autoload disabled?
No. An option needed on most requests may benefit from autoloading. Disable it only when its usage pattern and owning code justify a separate lookup.
Can a plugin recreate an option after I remove it?
Yes. If active code writes the option, it may return during page load, cron, cache generation or a settings save. Fix the source rather than repeatedly deleting the symptom.
Does Redis solve oversized autoloaded options?
It can reduce database work, but it does not make unnecessary data free. Large alloptions objects can still use memory and add cache-transfer or invalidation cost.
Is it safe to edit autoload values in phpMyAdmin?
Direct edits carry risk and should not be the first choice. Use staging, a verified backup and owner-specific guidance, then change one option at a time if a direct edit is genuinely required.
Why is wp-admin slow even after reducing autoloaded options?
The bottleneck may instead be AJAX callbacks, remote API calls, cron, slow database queries or plugin code. Profile the actual request before continuing database cleanup.
Comments