WordPress Autoloaded Options: Measure Before You Change Them

WordPress autoloaded options are rows from the options table that WordPress normally loads together during startup. A large total can be worth investigating, but a size report alone cannot tell you that those rows caused a slow page, which plugin owns a row, or whether changing its autoload behavior is safe. Start with Site Health, inspect only option names, byte sizes and autoload flags, then confirm each candidate with the code or maintainer that uses it. Never delete an option or change its flag just because it is large.

The autoload-size analyzer can summarize a sanitized, value-free report in your browser. It totals only the rows you supply and highlights the largest normally autoloaded options; it does not inspect your live WordPress installation or decide which settings to change. Never paste a database dump or any option_value into the tool.

What autoloading does—and what a size report cannot prove

WordPress normally fetches autoloaded options together through wp_load_alloptions() and keeps them in the options cache. Options can hold settings used by WordPress core, a theme, plugins, a must-use plugin, or custom code. Loading a setting on each request can avoid separate lookups when that setting is genuinely needed broadly. Loading a large value that is rarely needed may do avoidable work.

That trade-off is application-specific. A large autoloaded value is a review candidate, not proof of a performance defect. Its impact depends on what reads it, whether the request reaches PHP at all (for example, a full-page cache may serve it), the database and object-cache setup, the request path, and other work. A small aggregate does not guarantee fast pages; a large aggregate does not prove that autoload is the reason a visitor is waiting. Use real page or application measurements to investigate a reported slowdown rather than treating one database number as a speed score. For a separate diagnostic path, see how to find the slow phase before upgrading hosting.

WordPress Site Health (since 6.6) includes an Autoloaded options test. The default warning limit is 800,000 bytes (800,000 B); WordPress documents that limit as filterable, and its optimization handbook describes keeping the total under 800 KB as a general aim. This is an advisory built-in check, not a universal performance threshold, a ranking rule, or a guarantee that anything below it is fast. A site can customize the check, and Site Health calculates the aggregate from options WordPress loads, not from a browser speed test. See the Site Health test, its filterable limit, and the WordPress optimization handbook.

Check your WordPress version before interpreting flags

The autoload column has not always used the same vocabulary. WordPress 6.6 changed the Options API so an omitted autoload choice can be decided dynamically. On a standard core path, current default autoload values are yes, on, auto-on and auto. auto follows WordPress’s dynamic default behavior; it is not a promise that every such row must remain autoloaded. Values such as no, off and auto-off are not in that default set. WordPress 6.7 deprecated the older API strings yes and no, but continues to accept them for backward compatibility. Existing rows were not all converted in a one-time database migration, so legacy values can remain on a newer site. The autoload-value filter can remove entries from that default set, and other runtime filters or custom code can affect the loaded result. Check the actual values rather than assuming every row says yes or no.

The 6.6 change also introduced a default 150,000-byte per-option heuristic when the API chooses autoload behavior dynamically; the wp_max_autoloaded_option_size filter can change it. That is distinct from the 800,000-byte Site Health aggregate limit. Neither number says that a particular setting is safe to turn off. The 6.6 notes explain the new values and behavior; the current autoload-value function reference, 150,000-byte filter reference, and wp_set_option_autoload() reference document the default list, filter and API history.

For a quick triage, record the exact WordPress version, whether the site is Multisite, and whether it uses a persistent object cache. In WP-CLI, wp core version displays the core version without making a setting change. If you do not have shell access, use the WordPress administration screens or ask your host. On Multisite, each site can have its own options table; network-wide settings use site/network-option APIs and are stored separately in wp_sitemeta by default (Options API). Do not inspect a guessed table or assume that a --url argument makes a raw database query target the right site's table.

Start with Site Health, then collect only three columns

1. In the dashboard, open Tools → Site Health → Status and note the Autoloaded options result and its displayed size. If it reports a problem, treat that as a reason to investigate—not as a command to delete or toggle anything. If Site Health and a direct query disagree, record the difference and ask a WordPress developer or host to explain it; core and custom filters, a stale cache, and the measurement method can matter.
2. If a per-option list is needed, work with an administrator who has the right database access. A read-only SELECT does not modify the database; take a restorable backup before any later change. Confirm the correct site and table prefix first. WordPress's usual prefix is wp_, but it can be changed. wp db prefix can show the configured prefix; on Multisite, identify the target site's own options table. The WP-CLI database-query documentation notes that --url does not retarget a raw wp db query, so select the intended table explicitly.
3. Run a SELECT-only query that returns the option name, the stored value's byte length, and the autoload flag—never the value itself. Replace wp_options with the exact options table for the site you intend to inspect:

SELECT option_name,
       OCTET_LENGTH(option_value) AS size_bytes,
       autoload
FROM wp_options;

For a tab-separated report with the required header, run the same SELECT with WP-CLI from the WordPress directory. Confirm the table name first:

wp db query "SELECT option_name, OCTET_LENGTH(option_value) AS size_bytes, autoload FROM wp_options;" --batch --column-names

wp db query can execute arbitrary SQL; this example is read-only because its statement is a SELECT. Do not substitute a write query. The WP-CLI reference documents MySQL argument passthrough; the MySQL client reference documents --batch for tab-separated rows and --column-names for headers. Do not use --skip-column-names: the analyzer requires the header. Review the output locally and remove any terminal decoration or diagnostic messages before using it.

This unbounded query can scan every option row. On a large table or a busy production database, ask the host or developer to review timing and resource limits first. The report may exceed the analyzer’s 500-row or 100,000-byte input limit; use a trusted local analysis instead of dropping rows and calling the result complete. If you deliberately inspect a smaller sample, label it partial and use Site Health for the runtime aggregate. No command in this guide was run against a customer installation.

OCTET_LENGTH() reports bytes in the stored database string (see the MySQL and MariaDB references). For a normal WordPress option row, that gives the stored serialized/text value length without revealing its contents. The Site Health method measures values returned by wp_load_alloptions(). Core can also fall back to loading all options if its autoload query returns no rows. A direct SQL sum is therefore a useful database snapshot, but it is not guaranteed to reproduce a customized runtime result: WordPress filters, a custom autoload-value list, or cached data may change what is loaded. The core autoload loader and Site Health size calculation show what those WordPress functions measure.

If the site uses a different table prefix, a typical Multisite table name can look like wp_3_options; use the actual site-specific table, not this example. Network-wide settings are outside this site-options report; WordPress documents that Multisite network options are stored in wp_sitemeta by default. If you are not certain which site/table is correct, stop and ask the administrator or host instead of trying nearby tables.

Sanitize the report before using a browser tool or sharing it

Keep only these fields:

• Option name (or a redacted name if it reveals a customer, account or other private identifier)
• Stored size in bytes
• The exact autoload flag as stored

Do not include option_value, even partially. Values can contain credentials, tokens, license keys, private URLs or customer information. Do not upload a SQL export or full database dump. Review option names too: they can expose an email address, customer ID or internal project. If needed, replace sensitive names only in the report copy with unique labels such as redacted_001, and keep the mapping private for the administrator. Do not alter option names or values in WordPress to make a report fit the analyzer. Keep reports private and delete temporary copies when no longer needed.

Use the exact analyzer format

Paste simple, unquoted CSV or TSV with exactly these three columns, in this order: option_name,size_bytes,autoload. The TSV form uses a tab between the same header names. Include the header and at least one data row; use one delimiter consistently. Do not paste SQL statements, an ASCII table, option values or extra columns.

The accepted limits are 100,000 UTF-8 bytes for the entire input, including the header, and 500 data rows. Do not add blank lines between records. A header with no data is an error.

• option_name: 1–191 characters, using only ASCII letters, digits, underscore (_), period (.), colon (:) or hyphen (-). Names must be unique in the report.
• size_bytes: a base-10 whole number from 0 through 100000000. Use digits only, without thousands separators, units, signs, decimal points, scientific notation or leading zeros other than 0 itself.
• autoload: one of yes, on, auto-on, auto, no, off or auto-off. Preserve the stored flag; the analyzer accepts these flags without regard to letter case.

These are tool-format restrictions, not WordPress validity rules. A real option name outside this narrow character set is not thereby corrupt or invalid. Do not rename or delete it in WordPress. Review unsupported names or flags locally with a developer; an unknown flag, duplicate name, extra column, malformed row or SQL dump produces an error rather than a partial result.

This fictional CSV matches the illustrated rows below and contains no option values:

option_name,size_bytes,autoload
demo_plugin_alpha_settings,410000,on
demo_theme_options,300000,auto
demo_connector_cache,205000,auto-on
demo_admin_last_seen,100000,off
demo_form_map,20000,auto-off

The analyzer counts yes, on, auto-on and auto, excludes no, off and auto-off, and displays the supplied row count, normally autoloaded count, supplied byte total and up to the 10 largest supplied autoloaded rows. An accepted list containing only excluded flags returns zero counted rows and zero bytes, with an explicit empty result—not a clean bill of health for the site. A partial export cannot establish the full aggregate, and the analyzer does not apply your site’s WordPress filters.

The analyzer processes this text in the browser without uploading or saving the supplied input. It does not connect to a live database, query DNS or change options. Use Clear to remove the input and results. Local processing does not make sensitive data appropriate to paste: keep option values and private identifiers out of the report.

Read the largest rows as leads, not a deletion list

Here is a synthetic example. The option names are fictional; no site or plugin was tested. Sizes are bytes from a hypothetical value-free report.

Using WordPress's default 6.6+ list, 3 of these 5 supplied rows count as normally autoloaded, totaling 915,000 bytes (410,000 + 300,000 + 205,000). The 100,000-byte off row and 20,000-byte auto-off row do not count. That is 0.915 MB in decimal units, about 0.873 MiB, or 893.6 KiB as rounded in the analyzer. The supplied total exceeds the default 800,000-byte Site Health limit, but it is not a live Site Health result: this example does not establish a complete site export, the site’s filter settings, page speed or which rows are safe to change. The data is illustrative, not a benchmark or customer test.

For each large row, ask:

1. Who owns it? Search the active plugin, theme, must-use plugin or custom code for the option name and calls such as get_option(), add_option() or update_option(). Check the plugin's documentation or ask its maintainer. A prefix that resembles a plugin name is only a lead, not proof. Check for custom or abandoned code too.
2. When is it read? If it is needed on every public request, turning off autoload may trade one startup load for extra database reads. If it is only needed on one admin screen, a maintainer may decide a different loading pattern is appropriate. The report does not tell you how often the code reads the value.
3. Can the value be reduced or refreshed safely? A large cache, index or generated setting may have a supported rebuild or cleanup route; a configuration blob may be essential. Do not infer that “cache”, “transient”, or a plugin-looking prefix means disposable data.
4. Is there a supported fix? Prefer a plugin/core update, documented setting, or a maintainer-reviewed code change. WordPress has an API for changing autoload behavior without rewriting the option value, but that is a developer-level change that must be checked against the site's WordPress version and the option's usage. Do not run direct SQL to change the flag or remove a row.

If ownership or purpose is unclear, send the maintainer or host the WordPress version, the exact flag, the sanitized option name and byte count, the Site Health aggregate, and a description of the affected request. Do not send option values, database credentials, or an unredacted SQL dump.

Test a proposed fix and keep a recovery path

Before any supported change, make a fresh backup of the database and the site files if the change also affects code or plugin configuration. WordPress's backup guidance explains that files and database are separate parts of a normal site backup. Store a protected copy outside the publicly served document root or in a host's private/off-site backup storage; confirm the location is not web-accessible (WordPress's test-driving guidance distinguishes a nonpublic path from a public web directory). Restrict access and encrypt it where appropriate. Confirm that the backup is complete and that you know how to restore it. For detailed cPanel backup and isolated test-restore advice, see cPanel website backups and a safe WordPress test restore.

Test first on staging or a private clone using the same relevant WordPress, PHP, theme, plugin, and cache setup. Check normal pages and the workflow that uses the option—such as login, forms, scheduled jobs, REST/API integrations or checkout. Compare the same requests under comparable cache and traffic conditions before and after, and use your existing real-user or application monitoring if the symptom is visitor-facing. Change one thing at a time. Do not treat a passing Site Health total as a performance benchmark or a page-speed score as proof that a database setting caused the change. The WordPress auto-update backup and rollback guide has a broader recovery checklist.

If a change causes errors, restore only from a known-good, tested recovery point with the site's operational context in mind. Restoring a database can discard newer orders, users, form submissions or other records, so do not blindly restore a whole live database on a busy store. Stop the change, preserve current evidence, and coordinate a targeted rollback with the developer, host or plugin maintainer. If there is no tested backup, no staging site, the option belongs to custom code, or the site is a Multisite/commerce installation you do not administer, do not experiment on production—escalate first.

A careful next step

Start with Site Health, then use a value-free, version-aware report to find rows that deserve a maintainer’s attention. The autoload-size analyzer helps total and rank the supplied data; it is not a replacement for checking the complete loaded set and the site’s actual workload. Review ownership, protect a tested recovery path and verify any supported change before applying it to production. Do not buy a larger hosting plan or remove settings on the basis of one aggregate number.