WordPress & Web Development / Database performance
To address WordPress’s “Autoloaded options could affect performance” warning, inspect the total autoloaded size, identify the largest options and their owners, and test a targeted remedy. Do not delete unfamiliar rows or turn off autoload for everything. Changing when a setting loads and removing the setting itself are different operations.
The useful outcome is a site that keeps working with less unnecessary work during WordPress requests. Clearing the warning is one check, but it does not prove that the original performance problem has been solved. This guide provides a diagnostic workflow for site owners and developers, including commands that list information without changing option values.
Understand what Site Health actually measures
WordPress stores many configuration settings as options. The WordPress optimization handbook explains that plugins and themes define options that can load automatically, and excessive autoloading can affect performance. Autoloading is useful for frequently needed settings; the goal is appropriate loading, not a zero-byte total.
The current Site Health check implementation uses a default threshold of 800,000 bytes. At or above that limit it reports the warning. The threshold is filterable, so a customized installation may differ. The check reports an option count, but its warning condition is based on total size.
That distinction explains why deleting a handful of tiny rows may make little difference. Conversely, one unusually large option can deserve investigation even on a site with relatively few options.
| Observation | What it tells you | What it does not establish |
|---|---|---|
| Large total autoloaded size | There is substantial automatically loaded option data to review. | Which setting is unnecessary. |
| Many small options | The count is high. | That the count alone triggered the size warning. |
| One dominant option | A focused investigation may be worthwhile. | That deleting it is safe. |
| Warning disappears after a change | The reported total is now below the applicable threshold. | That every workflow still works or is measurably faster. |
Why an old SQL query can undercount
Do not rely on a query that checks only autoload='yes' on a modern installation. The current WordPress autoload-value function recognizes yes, on, auto-on, and auto by default, with filtering possible. A report using only the old value can omit part of the data WordPress considers autoloaded.
When two tools disagree, first compare their selection rules, units, target site, and observation time. Avoid changing the database merely to make an outdated report match the dashboard.
Record a baseline and confirm recovery before edits
Open Tools > Site Health and record the exact message, size, count, and date. Note the WordPress version, active theme, relevant plugin versions, and whether the warning appeared after a recent update or configuration change.
Also record the symptom you are investigating. Is the public site slow, the editor sluggish, or a particular administrative screen taking longer? Choose a small set of repeatable tasks so the investigation has an observable goal.
Before database changes, prepare a current backup and a way to restore it. WordPress’s backup guidance distinguishes the database from site files and explains that a typical full restore needs both. Confirm that the database is included rather than assuming a download of the WordPress directory contains it.
Use a representative staging copy for experiments. Our staging-to-live checklist covers deployment scope and avoiding overwriting newer production data. For this task, the eventual live change should be the reviewed option adjustment or vendor fix, not an indiscriminate replacement of the production database.
Record the exact option name, identified owner, current size and autoload state, proposed change, reason, test cases, and reversal method. “Database cleaned” is too vague to help if a setting later behaves differently.
Inspect option names and sizes with WP-CLI
If you have authorized shell access and WP-CLI is available, use the documented option-list command. The following examples list data; they do not delete options or change their autoload settings. Replace the placeholder path with your WordPress installation and run as the account that manages that site, following your host’s instructions.
wp --path=/path/to/wordpress option list --autoload=on --format=total_bytes
wp --path=/path/to/wordpress option list --autoload=on --fields=option_name,autoload,size_bytes --format=jsonThe first command returns the total bytes for matching options. The second produces a report with names, autoload states, and sizes, without requesting the stored values. Review the largest entries using a tool that sorts the numeric size_bytes field. Do not assume the report is already ordered by size.
For Multisite, the command documentation identifies --url as the way to target the relevant site. Record which site you inspected. These examples are not a complete audit of network-wide settings.
If a command or field is unavailable in your installed tool version, check its local help and the current documentation before substituting a database query. Without shell access, ask the host or developer for the same names-and-sizes report. There is no need to request a public dump of option values, which may contain sensitive configuration.
Identify who created each large option
An option name can be a clue, but a familiar prefix is not enough evidence to remove data. Check the relevant plugin or theme documentation, ask its maintainer, or have a developer inspect the code that creates and reads the option.
For each candidate, answer four questions: What component owns it? Is that component still used? Which workflows read the data? What supported method changes or removes it?
Hypothetical example: an option appears to belong to an old reporting plugin. If the plugin is only deactivated while a replacement is evaluated, its settings may still be needed. If the business permanently retired it, the maintainer’s documented cleanup process may be appropriate. The same-looking row can require a different decision depending on the site’s plans.
Do not treat a large value as inherently disposable. It might represent useful configuration, or it might be a symptom of data accumulating in an unsuitable place. If you cannot establish ownership and purpose, keep it on the investigation list and seek help.
| Candidate | Reasonable next step |
|---|---|
| Active component, data needed broadly | Ask whether its size is expected and whether a vendor fix exists. |
| Active component, data needed occasionally | Investigate whether disabling autoload is appropriate. |
| Permanently retired component | Review the supported uninstall or cleanup process and dependencies. |
| Unknown owner | Identify it before changing or deleting it. |
Choose a targeted remedy rather than a blanket cleanup
The WordPress 6.6 Options API developer note describes the tradeoff: frequently used options can benefit from autoloading, while rarely used large values create unnecessary loading. It also documents dynamic handling of large newly added or changed values when autoload is not explicitly forced.
This is not a promise that upgrading automatically rewrites every existing row. The same note says previously stored autoload values were retained rather than converted by an upgrade routine. Investigate the actual current report instead of assuming version changes performed a historical cleanup.
For a reviewed autoload adjustment, developers can use the dedicated WordPress autoload API, which changes autoload behavior without changing the option’s stored value and handles the relevant option caches. Its documentation specifically discusses options used exclusively by an inactive plugin.
Prefer a supported vendor setting, update, or documented API-based fix over a blind SQL update. Preserve the original state and test one candidate or a small, clearly related group at a time. If data is genuinely obsolete, deletion is a separate decision requiring its own ownership and recovery checks.
Avoid changing the Site Health threshold just to hide the message. That changes the reporting boundary, not the amount of data being loaded. Likewise, a lower total is not worth keeping if the change breaks a required workflow.
Test functionality and performance separately
After a staging change, re-run the same size report and Site Health check. Confirm that the intended option was affected and that its value remains intact if the plan was only to change loading behavior.
- Open representative public pages as a logged-out visitor.
- Sign in and test the administrative screen associated with the option.
- Save the relevant component’s settings and reopen them.
- Test forms, checkout, account pages, or scheduled tasks where relevant.
- Review available application logs for new errors.
- Repeat the original slow task under comparable conditions.
Use the same cache state, account type, and task when comparing timings. A warm cached public page and a logged-in settings screen are different tests. Record several observations rather than treating one fast request as proof.
The optimization handbook notes that persistent object caching can make option loading more efficient. That is a separate performance consideration, not evidence that a particular option is unnecessary. Keep the investigation focused and avoid changing several caching layers during the same experiment.
If the targeted change passes, apply that reviewed change through the normal deployment process and verify production again. Keep the reversal instructions available. Do not restore a stale staging database over new orders, enquiries, or content.
Investigate a total that grows again
Recheck after normal activity and after saving the component’s settings. If the option becomes large again or returns to its prior autoload state, investigate the code path that writes it. Repeating manual cleanup may conceal the underlying behavior.
Give the maintainer a concise report: component and WordPress versions, option name, observed size, steps that recreate the growth, and whether autoload was explicitly changed. Share actual values only through an appropriate private support channel when necessary.
Keep performance findings honest. A reduction in autoloaded bytes is a measured database-related result; a claimed improvement in load time needs its own comparable measurements. Neither guarantees a particular search ranking or page-speed score.
If the warning persists because the remaining settings are legitimately needed, document that finding and review the broader slow request. The next investigation might concern an external service or another part of the application. Do not keep deleting settings merely to cross a numeric line.
Frequently asked questions
Does the warning mean my database is corrupted?
The check reports autoloaded size. It does not establish database corruption or identify a specific defective plugin.
Should I delete every option from a deactivated plugin?
First confirm that it is permanently retired, identify dependencies, and check the supported cleanup process. Deactivation alone is not a business decision to discard its configuration.
Why does an old autoload query show a smaller total?
Check whether it selects only “yes” and misses other current autoload values. Also compare the target site, units, and observation time.
Can turning autoload off replace deleting an option?
They serve different purposes. An autoload adjustment keeps the value; deletion removes data. Choose based on the option’s actual use.
Sources and scope
Primary WordPress documentation and current reference code were checked on 25 October 2026. Commands are diagnostic examples, not output from an inspection of your site. The retired-plugin example is hypothetical. No speed improvement or hands-on benchmark is claimed.
Add comment