---
title: How to Fix ‘Autoloaded Options Could Affect Performance’ in WordPress
description: Safely reduce oversized WordPress autoloaded options using ownership checks, runtime evidence, snapshots, rollback and before-and-after verification.
url: https://wpstack.online/2026/09/13/fix-autoloaded-options-could-affect-performance-wordpress
date_modified: 2026-09-13
author: Aditya Bhimrajka
language: en_US
---

**Short answer:** the “Autoloaded options could affect performance” warning means WordPress is loading a large amount of option data at the beginning of requests. Do not respond by deleting the largest rows. Measure the total, identify who owns each option, determine whether it is needed on most requests, take a recoverable snapshot, and change only the options you can justify.

WordPress added this Site Health check because autoloaded data can quietly grow as themes and plugins are installed, reconfigured, or removed. The warning appears when the total autoloaded footprint crosses the threshold used by WordPress. It identifies avoidable work, but it does not tell you which option is safe to change.

## What an autoloaded option is

WordPress stores site configuration in the `wp_options` table. The table prefix may be different on your installation. Some options are marked for autoloading, which lets WordPress retrieve a collection of commonly needed settings early in the request instead of issuing a separate query for every value.

Autoloading is useful for small settings required on most pages: the site URL, active plugin list, theme settings, widget configuration, rewrite rules, and other runtime configuration. The problem begins when large or rarely used data joins that collection. An admin-only report, expired cache, abandoned plugin configuration, or unbounded log does not need to occupy memory on every unrelated frontend, REST, AJAX, admin, and cron request.

WordPress 6.6 introduced new autoload values and logic for large options. It also added a Site Health warning when the total autoloaded data exceeds 800 KB. The official [WordPress Core development note](https://make.wordpress.org/core/2024/06/18/options-api-disabling-autoload-for-large-options/) explains why unnecessary autoloaded data can affect performance and why developers should choose the autoload behavior deliberately.

## What the warning does—and does not—prove

The warning proves that the measured footprint crossed a WordPress threshold. It does not prove that autoloaded options are the only reason a site is slow. A page can also wait on PHP work, a remote API, uncached database queries, a page builder, an overloaded server, browser JavaScript, fonts, or large images.

Treat the warning as an actionable diagnostic lead:

- **It is relevant:** autoloaded data participates in a broad set of WordPress requests.
- **It is not a verdict:** reducing it may produce a modest improvement or a significant one, depending on the site.
- **It is not deletion advice:** an option can be large and still be essential.
- **It needs a baseline:** without before-and-after measurements, you cannot show that a change helped.

## Before changing anything

1. **Take a current database backup.** Confirm that you know how to restore it. A backup that has never been tested is only a hope.
2. **Use staging when possible.** Copy representative data and reproduce the warning there before touching production.
3. **Record a baseline.** Capture the total autoloaded bytes, the largest options, a few representative server response times, peak memory, and relevant error logs.
4. **Account for persistent object caching.** Redis or Memcached can change the cost profile and can retain stale option caches if a tool updates the database incorrectly.
5. **Choose a rollback point.** Know which snapshot or database backup represents the last known-good state.

## A safe diagnostic workflow

### 1. Measure bytes, not just rows

Start with the total byte size and rank individual options by their stored size. The number of rows is useful context, but 1,000 tiny values can be lighter than one multi-megabyte serialized array. Focus first on the largest contributors and the cumulative footprint.

Record at least:

- option name;
- stored byte size;
- current autoload state;
- suspected owner;
- whether the owner is active;
- whether the value is read during normal requests;
- the proposed action and rollback method.

### 2. Identify ownership

Names often contain a plugin or theme prefix, but naming is only a clue. Search the active codebase for calls that read or update the option. Check the plugin’s documentation and uninstall behavior. An unfamiliar name is not automatically abandoned, and a deactivated plugin’s option is not automatically safe to delete.

Classify each candidate as WordPress core, active plugin, inactive plugin, active theme, previous theme, custom code, or unknown. Unknown options should receive more investigation, not more confidence.

### 3. Determine whether the option needs autoloading

The right question is not “Is this value large?” It is “Does normal WordPress execution need this value on most requests?”

| Observed use | Likely decision | Reason |
| --- | --- | --- |
| Small setting read on nearly every frontend request | Keep autoloaded | Avoiding repeated individual retrieval can be beneficial. |
| Large configuration used only on one admin screen | Consider offloading | It can still be retrieved when that screen needs it. |
| Active plugin data with uncertain access patterns | Investigate or keep | Guessing can break runtime behavior. |
| Confirmed orphan from a removed plugin | Consider deletion after backup | Deletion is appropriate only after ownership and non-use are established. |
| Logs, queues, or an expanding cache stored in one option | Fix the source design | Offloading reduces broad request weight but does not stop unbounded growth. |

### 4. Prefer offloading before deletion

Changing an option from autoloaded to non-autoloaded leaves its value in the database. Code using `get_option()` can still retrieve it when needed. That makes offloading a narrower and usually more reversible experiment than deleting the row.

Deletion is a different decision. It removes the stored value and may cause a plugin to lose configuration, regenerate defaults, reschedule work, or fail. Do not combine “stop loading this everywhere” with “erase this data” as if they were the same operation.

### 5. Change a small batch

Do not modify dozens of uncertain options in one operation. Start with one or a small group of high-confidence candidates. Record exactly what changed, clear the relevant WordPress and persistent object caches through supported APIs, then test the workflows owned by those options.

### 6. Verify the result

Re-run Site Health and recalculate the autoloaded footprint. Repeat the same requests used for the baseline with comparable cache state, user role, URL and input. Check:

- frontend pages and templates;
- login and wp-admin;
- checkout or membership flows;
- REST and AJAX features;
- scheduled tasks and background processing;
- plugin settings connected to the changed options;
- PHP and JavaScript errors.

A smaller footprint is evidence that the database state changed. Stable workflows and improved request measurements are evidence that the change was useful.

## How to inspect autoloaded options without guessing

The fastest investigation is a two-pass audit. The first pass establishes scale: total bytes, largest rows, growth since the last measurement, and whether the warning occurs on production, staging, or both. The second pass establishes meaning: ownership, read frequency, regeneration behavior, and business consequence. Keeping those passes separate prevents a common error—treating a list sorted by size as a deletion list.

### Use a read-only database query as supporting evidence

If you are comfortable with SQL, run read-only queries through a trusted database tool or WP-CLI. On current WordPress versions, multiple values can mean that an option participates in autoloading, so do not assume that only the literal value `yes` matters. Use WordPress APIs or the current core function that defines accepted autoload values when constructing an inventory.

```
SELECT option_name,
       LENGTH(option_value) AS stored_bytes,
       autoload
FROM wp_options
ORDER BY stored_bytes DESC
LIMIT 50;
```

This query is deliberately broad: it shows the largest rows before applying an autoload interpretation. Replace `wp_` with the real table prefix. Do not paste an `UPDATE` or `DELETE` version into production. The result still needs WordPress-version context, owner research, and functional testing.

Next calculate the aggregate using the autoload values recognized by the installed WordPress release. Compare the database number with Site Health or a WordPress-aware tool. A discrepancy can reveal a stale cache, an incorrect SQL filter, a different table prefix, or a Multisite scope mistake.

### Translate bytes into understandable numbers

Store raw bytes in the audit record, then display kilobytes or megabytes for people. Avoid rounding too early: several values shown as “0.1 MB” may differ substantially. Also distinguish stored bytes from PHP memory. A serialized value can occupy more memory after WordPress retrieves and unserializes it, especially when it contains large nested arrays and strings. Database size is therefore a consistent comparison measure, not a promise of exact runtime memory cost.

## Build an ownership dossier for each serious candidate

For every option that materially contributes to the total, create a short evidence record. A useful dossier answers six questions:

1. **Who writes it?** Find calls to `add_option()`, `update_option()`, settings APIs, migrations, and vendor-specific storage wrappers.
2. **Who reads it?** Search for `get_option()`, but account for dynamically assembled names and wrappers.
3. **When is it read?** Frontend bootstrap, one admin screen, a cron callback, checkout, REST, or only activation?
4. **Can it be regenerated?** A cache may be rebuildable; credentials, license state, or editorial configuration may not be.
5. **What happens if it is absent?** The owner may recreate a safe default, lose settings, repeat a migration, or fail.
6. **Is growth bounded?** A value that expands on every run needs a source fix even if it is removed from autoloading.

Search both active and inactive plugin directories when available. An option may belong to code that is currently deactivated, and custom deployment tooling may live outside the normal plugin directory. For commercial plugins whose source is encoded or unavailable, consult the vendor and test a cloned site. “No search result” means ownership is unresolved, not that the row is unused.

## Separate four different remediation decisions

| Decision | What changes | Main risk | Verification |
| --- | --- | --- | --- |
| Keep autoloaded | Nothing | Ongoing broad request cost | Confirm frequent use and acceptable footprint |
| Stop autoloading | Loading strategy only | Extra query/cache lookup where used | Test owning paths and total footprint |
| Replace or split data | Owner’s storage design | Migration and compatibility errors | Versioned migration, rollback, load test |
| Delete data | Value is removed | Lost settings or repeated initialization | Restore test and owner-specific regression |

These are not interchangeable optimizations. A frequently read 900 KB value may need a redesign rather than simply setting autoload off. A 300 KB abandoned cache may be safe to delete after proof. A small but rapidly growing log may deserve urgent source remediation even though removing it barely changes today’s warning.

## A production-safe change procedure

### Prepare the experiment

Pick a low-risk traffic window, confirm monitoring, and write down the exact acceptance criteria. Include the expected byte reduction, the workflows that must continue, the maximum acceptable latency on the option’s owning screen, and the rollback trigger. Export the selected option names, values, and autoload states separately from the general backup so a narrow reversal is possible.

### Exercise representative behavior before tracking

If you use runtime access tracking, warm the site normally first, then exercise anonymous pages, logged-in pages, wp-admin, checkout, REST, AJAX, CLI, cron, and integrations relevant to the candidate. A short quiet tracking window can incorrectly label valid options as unused. Seasonal and monthly jobs require code evidence or longer observation because waiting for them in staging may be impractical.

### Apply one defensible change

Use a WordPress-aware interface that updates the option and invalidates its individual and aggregate caches. Record the operator, time, previous state, new state, and reason. Avoid simultaneous plugin updates or deployments; otherwise a regression cannot be attributed cleanly.

### Test cold and warm cache states

Run the verification once with normal warm caches and once after a controlled cache clear. A change may appear successful because an old object-cache value remains available. Conversely, the first request after invalidation may be slower while caches rebuild. Measure enough requests to distinguish a one-time rebuild from steady-state behavior.

### Observe for the owner’s full operating cycle

Keep immediate smoke tests short, but retain the rollback data through at least one meaningful cycle: a scheduled synchronization, daily report, renewal, backup, checkout, or editorial publish. Review logs for warnings about missing array keys, invalid settings, repeated database writes, or options being recreated with their former autoload state.

## Worked case: a 2.4 MB reporting option

A membership site receives the Site Health warning and finds one reporting option responsible for 2.4 MB of the total. The name belongs to an active analytics plugin. The value contains daily aggregates for the plugin’s admin dashboard; code search shows it is read only when that report screen loads, while a nightly job updates it.

The team first clones production to staging and captures the option plus the complete database. Deleting the row makes the plugin rebuild months of aggregates, causing a long cron job, so deletion is rejected. They change only the autoload behavior through a WordPress-aware tool. Anonymous pages, member login, account pages, checkout, REST, and cron all pass. The analytics screen performs one cached lookup and remains within its response-time budget.

After a cold-cache test and two nightly aggregation cycles, the option remains non-autoloaded and the Site Health warning clears. The team documents the plugin version and alerts on future size growth. The outcome is defensible because it connects ownership, access pattern, business behavior, and measurement; the same 2.4 MB size without those facts would not justify the change.

## When the warning is not the main performance problem

If reducing autoloaded data produces little measurable improvement, do not keep deleting rows to force a dramatic result. Compare server timing with browser timing and inspect slow database queries, remote HTTP waits, PHP worker queues, cron overlap, object-cache health, page-builder workloads, and frontend asset delivery. The autoload warning can be worth fixing while another bottleneck still dominates user experience.

Prioritize by breadth and consequence. Autoload overhead affects many PHP requests, so a safe reduction has broad value. But a five-second remote API timeout on checkout or saturated PHP pool may deserve the first incident response. A good performance plan can hold both facts at once.

## What to include in the change record

Close the work with a record that another administrator can use months later. Include the Site Health message, WordPress and PHP versions, database prefix and environment, total autoloaded bytes before and after, selected option names and sizes, ownership evidence, runtime paths tested, cache state, monitoring window, and the location of the recoverable snapshot. Record options that were investigated but deliberately retained so the same research is not repeated during the next audit.

For each changed value, note whether the action was an autoload toggle, owner-level redesign, or deletion. Link links to any vendor ticket or code change. State the precise rollback trigger and whether rollback was rehearsed. If a plugin update later restores the old behavior, this record turns an unexplained regression into a quick comparison.

Finally, set a follow-up measurement rather than a permanent “fixed” label. Review the total after the next major plugin rollout and on a regular interval appropriate to the site’s change rate. A stable brochure site may need infrequent checks; a store with many integrations needs closer observation. The goal is controlled growth and explainable decisions, not a magic byte count.

## Using Autoloaded Options Manager

[WPStack Autoloaded Options Manager](https://wpstack.online/wpstack-plugin/autoloaded-options-manager/) packages this workflow inside WordPress. It shows real byte sizes, attributes likely ownership, highlights large contributors, and integrates with Site Health. Its Safety Analyzer combines time-limited runtime access tracking with static code inspection to classify candidates as Safe, Caution, or Keep.

The plugin creates a snapshot before toggles, bulk actions, deletions, and restores. It also invalidates per-option and aggregate WordPress caches when an autoload state changes, including sites using persistent Redis or Memcached object caches.

A practical sequence is:

1. Open **Tools → Autoloaded Options**.
2. Save the total footprint and largest contributors as your baseline.
3. Run the Safety Analyzer during representative site activity.
4. Review ownership and the Safe, Caution, or Keep verdict.
5. Offload one high-confidence candidate.
6. Verify its owning workflow and the wider site.
7. Continue in small batches, retaining snapshots until the changes are accepted.

The tool reduces guesswork; it does not eliminate the need for judgment. Static scanning cannot understand every dynamic option name, custom loader, or external integration. Runtime tracking can only observe workflows exercised during the tracking window.

## Common mistakes

- **Deleting the largest option first:** size indicates impact, not safety.
- **Targeting a row count:** there is no universal “correct” number of options.
- **Editing SQL directly:** direct changes can bypass cache invalidation and safety checks.
- **Running only the homepage:** an option may belong to checkout, cron, REST, or an admin workflow.
- **Ignoring the source:** a plugin that keeps appending data will recreate the problem.
- **Claiming success from Site Health alone:** validate real request behavior as well.

## Related WPStack guides

- [Autoloaded Option Count vs Size: What Actually Slows WordPress?](https://wpstack.online/2026/09/13/wordpress-autoloaded-option-count-vs-size/)
- [Which WordPress Autoloaded Options Are Safe to Disable?](https://wpstack.online/2026/09/13/wordpress-autoloaded-options-safe-to-disable/)
- [WordPress 6.6+ Autoload Values Explained: on, off, auto-on and auto-off](https://wpstack.online/2026/09/13/wordpress-66-autoload-values-explained/)

## Frequently asked questions

### Is 800 KB of autoloaded data always slow?

No. It is the WordPress Site Health threshold for raising attention, not a universal latency boundary. Hardware, cache configuration, traffic, PHP workers, and request behavior affect the observed cost.

### Should I delete options belonging to inactive plugins?

Not automatically. Confirm ownership, decide whether the plugin may be reactivated, review its retention policy, and take a backup. Offloading and deletion solve different problems.

### Will changing autoload to off break get_option()?

No. The value remains available through `get_option()`. WordPress retrieves it when requested instead of including it in the broadly loaded collection.

### Does Redis make autoload cleanup unnecessary?

No. Persistent object caching can reduce repeated database work, but unnecessary data can still consume cache and PHP memory and must still be loaded into the request when WordPress builds the option collection.

### Can a cleanup plugin know with certainty that every option is safe?

No. Dynamic names, custom code, conditional workflows, and external integrations limit automated certainty. Use ownership, static evidence, runtime observation, staging, snapshots, and functional testing together.

### What should I do if the warning returns?

Compare the new inventory with the previous one. Identify which option grew or appeared, then correct the plugin or workflow generating the data. Repeated manual cleanup is not a substitute for fixing unbounded storage.

## Action checklist

- Back up the database and define a restore path.
- Measure total bytes and rank the largest options.
- Identify ownership and runtime use.
- Keep critical and uncertain options unchanged.
- Prefer reversible offloading before deletion.
- Change small batches and invalidate caches correctly.
- Test the owning feature and representative WordPress requests.
- Fix the source when an option continues growing.

## References

- [WordPress Core: Options API changes and large autoloaded options](https://make.wordpress.org/core/2024/06/18/options-api-disabling-autoload-for-large-options/)
- [WordPress Developer Reference: `wp_autoload_values_to_autoload()`](https://developer.wordpress.org/reference/functions/wp_autoload_values_to_autoload/)
- [WordPress support example: diagnosing a multi-megabyte autoload warning](https://wordpress.org/support/topic/autoloaded-options-could-affect-performance-2/)