Autoload Data Optimization
Reduce the autoloaded wp_options data to cut the PHP bootstrap time on every page request.
Metrics
This technique can move up to 33% of LCP's share of the Lighthouse score.
This technique does not move TBT.
This technique does not move CLS.
This technique can move up to 67% of FCP's share of the Lighthouse score.
This technique can move up to 33% of SI's share of the Lighthouse score.
This technique can move up to 67% of TTFB's share of the Lighthouse score.
Overview
WordPress loads all rows from wp_options where autoload='yes' at the start of every single page request, before any template or plugin logic runs. This data is retrieved in a single database query and stored in the object cache for the duration of the request. Over time — through plugin installations, deactivations, and misconfigured option registrations — the autoloaded dataset can grow to several megabytes, requiring the database to read, transmit, and PHP to deserialize large volumes of data on every request regardless of whether that data is ever used.
Impact grade, A+ to D: how much of the Lighthouse score this technique can move. Unaffected: TBT, CLS.
The Problem
A WordPress site that has installed and uninstalled 50 plugins over its lifetime commonly has 5–20 MB of autoloaded data — including options from plugins that no longer exist on the site. Each page request loads this entire dataset from the database: a 5 MB autoload set requires a 5 MB database read, a 5 MB network transfer from DB to PHP, and the CPU time to deserialize every row with maybe_unserialize(). On shared hosting, this single operation can account for 100–400 ms of every page’s TTFB before any theme or plugin code executes.
Performance Impact
LCP
Indirect
faster server response time carries through the waterfall — earlier HTML means earlier LCP
FCP
50–400ms
PHP bootstrap time reduced by eliminating unnecessary autoload deserialization overhead
SI
Indirect
faster server response means content appears in the viewport sooner
TTFB
100–500ms
autoload bloat is a direct, hidden contributor to TTFB that is often overlooked
Risk: Low
only remove options belonging to absent plugins; changing autoload=no for active plugins moves, not eliminates, the query cost
How it works
01
Measure current autoload size
Query the database to see current autoload data volume:
SELECT ROUND(SUM(LENGTH(option_value))/1024/1024, 2) AS autoload_mb FROM wp_options WHERE autoload='yes';. Anything above 1 MB warrants investigation. Group by option name prefix to identify which plugins contribute the most.02
Identify and remove orphaned options
Orphaned options belong to plugins that have been deactivated or deleted. Query for option names matching known plugin prefixes from plugins no longer in the plugins directory. Common culprits: old security plugins, abandoned SEO plugins, and removed page builders. Delete these rows with
DELETE FROM wp_options WHERE option_name LIKE 'old_plugin_%';03
Unregister unnecessary autoloading from active plugins
Some active plugins store large datasets (transients, log data, statistics) with
autoload='yes'. Usewp_cache_add_global_groups()or update the option withautoload='no'via direct DB query for data that is only needed on specific admin pages or when explicitly requested.04
Register your own options correctly
When adding options in custom code, always pass
falseas the third argument toadd_option()for data that does not need to load on every request:add_option('my_plugin_logs', [], '', 'no');. The fourth parameter is the autoload flag — it defaults to'yes'.
Code Example
# Check current autoload burden
wp db query "SELECT ROUND(SUM(LENGTH(option_value))/1024/1024,2) AS mb, COUNT(*) AS rows FROM wp_options WHERE autoload='yes'" --allow-root
# Typical problem output:
# +-------+------+
# | mb | rows |
# +-------+------+
# | 8.23 | 1847 |
# +-------+------+# Find largest autoloaded options
wp db query "SELECT option_name, ROUND(LENGTH(option_value)/1024,1) AS kb FROM wp_options WHERE autoload='yes' ORDER BY LENGTH(option_value) DESC LIMIT 25" --allow-root
# Change autoload status for a safe option (e.g., a statistics row)
wp db query "UPDATE wp_options SET autoload='no' WHERE option_name='my_plugin_stats'" --allow-root
# Remove orphaned options from a deleted plugin
wp db query "DELETE FROM wp_options WHERE option_name LIKE 'deleted_plugin_%'" --allow-rootUse the Query Monitor plugin’s Options panel or the Autoload Manager plugin for a GUI view of autoloaded data with size breakdowns. Take a database backup before any DELETE operations.
Limitations
- Many autoloaded options are required by WordPress core and active plugins — indiscriminate deletion breaks functionality. Always identify the owning plugin before deleting an option row.
- Changing
autoload='no'for an option that a plugin reads on every page load only moves the problem — the plugin now performs an individual database query on every request instead of reading from the preloaded set. Understand why the option is autoloaded before changing it. - Autoload bloat returns over time as new plugins are installed. Make autoload size checks part of your regular database maintenance schedule.
Common Mistakes
Deleting all wp_options rows from inactive plugins without verifying they are truly orphaned
Some plugins share option name prefixes with other plugins, or store options used by child plugins. Before deleting by name pattern, verify the option_name prefix belongs exclusively to an absent plugin by checking the plugins directory.
Using autoload=’yes’ for transient-like data in custom plugin development
Transients, logs, aggregate statistics, and other data with high write frequency or large size should never be autoloaded. Use add_option('my_data', $value, '', 'no') and accept the individual query cost only when the data is actually requested.