WordPress has made autoloaded options easier to notice. It has not made them self-fixing. Core still loads autoloaded options into the normal request path, and wp_load_alloptions() caches that set so it can be reused. When the autoload set is bloated, that overhead becomes part of everyday page handling. The Site Health warning matters because it surfaces that cost. It does not tell you whether the real problem is a stale plugin row, an oversized settings array, a poor save routine, a legacy autoload flag, or a cache setup that is hiding part of the symptom.
What the Site Health warning actually tells you
The WordPress performance handbook describes autoloaded options as plugin and theme settings that are loaded automatically on every page load. It also says too many autoloaded options can slow a site down and that you should generally try to keep them under 800 KB. Core ticket #61276 turned that guidance into a Site Health test in WordPress 6.6. When the total size of autoloaded options goes beyond 800 KB, WordPress raises a critical issue. That threshold can be adjusted with a filter, which is useful operationally. But it is still only a threshold. It tells you the total weight is risky. It does not tell you what belongs in autoload and what does not.
Why this is still paid performance work
The important detail is how early and how often this data is loaded. The WordPress 6.6 dev note explains that WordPress loads multiple options with a single query on each page request, and the wp_load_alloptions() reference shows that core loads and caches the autoloaded option set from the options table. In practice, that means bad autoload decisions do not stay isolated. They get folded into the default request path. The Site Health panel will not tell you which rows to change, which ones should stay autoloaded, or whether the right fix is code, cleanup, cache work, or some combination. Someone still has to inspect the rows, trace what is writing them, and decide what is safe.
What changed in WordPress 6.6 and 6.7
Part of the confusion is that WordPress changed the mechanics without turning this into a one-click fix. In 6.6, the default $autoload value for add_option() and update_option() changed from yes to null. Core now recommends three intent levels: true to always autoload, false to never autoload, and null to let WordPress decide. The same dev note explains that WordPress dynamically disables autoloading for values larger than 150,000 bytes unless the option is explicitly set to autoload. It also introduced newer database values such as on, off, auto, auto-on, and auto-off, while older yes and no rows remain supported for backward compatibility. No upgrade routine was planned to rewrite old rows automatically.
Then in 6.7, the changelogs for both update_option() and wp_set_option_autoload_values() marked legacy yes and no autoload values as deprecated. That matters because plenty of sites now run with a mix of older rows, newer rows, and code written around both habits. If custom SQL reads or writes autoload flags directly, the 6.6 dev note explicitly says that SQL should be updated for the newer values. That is one reason this work is not simply clear the warning and move on. You are dealing with current core behavior and historical plugin behavior at the same time.
What real remediation usually looks like
The first job is classification, not deletion. The update_option() documentation says options used across several places in the frontend are good autoload candidates, while options used only on a few specific URLs are better left non-autoloaded. So a large option is not automatically wrong, and a small option is not automatically harmless. The practical questions are usually these:
- Is this option actually needed on every request, or only in a narrow admin or feature path?
- Is the value large because of legitimate configuration, or because a plugin or theme is storing too much in one option?
- Is the row still in active use, or is it leftover data from a removed or replaced plugin or theme?
- Is the cleanest fix a code patch, a one-time database cleanup, a cache adjustment, or a mix of those?
Those answers determine the right implementation path. If a plugin or theme saves an option without clear autoload intent, the better fix may be to patch the save routine so future writes behave properly under modern WordPress. If the database contains stale rows that no longer serve the site, the better fix may be careful cleanup. If the autoload flag itself is wrong, core now provides wp_set_option_autoload_values() as a controlled way to update autoload values for multiple options. That matters because update_option() can only change an existing option's autoload value when the option value changes too. The core setter also handles the related alloptions cache cleanup, which reduces the risk of changing database state without refreshing runtime state.
Why blanket fixes often backfire
WordPress now gives developers more control, but the sources are clear that those controls need judgment. The 6.6 dev note shows that you can force a large option to autoload through wp_default_autoload_value when it truly needs to be available on every page, but it warns to do that carefully. The same note says the size threshold for dynamic autoload decisions can be adjusted with wp_max_autoloaded_option_size, yet increasing that threshold is not recommended because it can lead to slower performance. In plain terms: changing the warning threshold is not the same as reducing the load. The handbook also notes that a persistent object cache can make options load faster and more efficiently. That can be part of the answer, but the handbook still says too many autoloaded options can slow a site and should generally stay under 800 KB.
What this means for GrN clients
For a business site, the value is not in proving the Site Health warning exists. WordPress already does that. The value is in turning the warning into a safe, durable fix. Greg can help with the practical work here: identifying stale or oversized autoloaded options, checking whether they should be autoloaded at all, patching plugin or theme behavior when the save logic is wrong, cleaning leftover database rows safely, and confirming whether cache tuning should support the final setup. The point is not to chase a green dashboard for its own sake. The point is to remove avoidable weight from the request path, keep genuinely always-needed options where they belong, and leave the site aligned with current WordPress behavior rather than old assumptions.
If your WordPress site is showing autoload pressure, treat the warning as the start of the investigation, not the finish line. Modern WordPress gives you clearer heuristics, newer APIs, and a core Site Health threshold. It does not remove the need for judgment. Someone still has to decide what is stale, what is oversized, what belongs in autoload, and what should be fixed in code instead of being papered over with a threshold change or a cache workaround. That is why autoloaded options remain a paid performance fix, not just a warning to dismiss.
Need help with this kind of work?
Need a WordPress autoload audit and a safe remediation plan? Get in touch with Greg.