WordPress autoload: Why wp_options slows down your site

WordPress Autoload loads masses of options from the wp_options table into the memory with every page request and thus drives up TTFB, CPU and RAM requirements. If too much autoloaded data accumulates here, this table will slow down your site noticeably.

Key points

I'll summarize the most important facts so that you can immediately assess whether autoloaded options are slowing you down. With every request, WordPress loads all entries with autoload=yes, regardless of whether they are needed. This acts like an invisible backpack that gets heavier with every plugin installed. From an autoload size of around 1 MB, performance quickly drops, which is particularly noticeable on smaller hosts. With a few targeted steps, I can permanently reduce the load and keep the wp_options clean.

• Autoload load: Everything with autoload=yes is saved with every page request.
• Critical size: TTFB increases sharply from ~1 MB; 2-3 MB is considered an alarm range.
• Main driverPlugins, transients, logs and faulty cron jobs.
• MeasurementSQL/WP-CLI shows size and top originator immediately.
• remedyClean up, autoload to „no“, outsource, check regularly.

Why Autoload slows down

Autoloaded options end up in memory with every request, regardless of whether the page currently needs them; this is exactly what eats up memory. Resources. Small values are hardly noticeable, but with many plugins the total quickly grows to hundreds of kilobytes or even several megabytes. From around 1 MB, I regularly see increasing TTFB, slower admin pages and more CPU peaks. On shared hosting, the load multiplies because parallel requests increase the database wordpress additionally. The larger the autoload block, the longer the deserialization takes and the more time your server wastes before the first byte.

How WordPress loads internally (alloptions and object cache)

WordPress combines all autoloaded options into one large block. With the first request, this block is loaded with a single query and stored under the collection key alloptions is stored in the object cache. This reduces the number of database queries, but not the amount of data to be processed: The entire block must be deserialized and kept in memory. With a Persistent Object Cache (e.g. Redis or Memcached), the database load disappears, but the PHP processes still have to unpack the data and keep it in RAM. This means that a large autoload block is also harmful if the data comes from the cache - only the bottleneck shifts from the database to the CPU and RAM.

This is particularly critical for:

• high parallelism (many simultaneous requests): Each PHP worker loads the block separately.
• short process times (FPM/Serverless): The overhead is incurred again for each new process.
• Admin area and cronCaches are bypassed or invalidated more frequently, the autoload block counts every time.

How to find the biggest autoload offenders

I start with a size measurement directly in the wp_options. I get the sum via SQL: SELECT SUM(LENGTH(option_value)) AS autoload_size FROM wp_options WHERE autoload = 'yes';. Values over 1 MB are critical, from 2-3 MB it becomes dangerous, especially with traffic. I then sort by size: SELECT option_name, LENGTH(option_value) AS bytes FROM wp_options WHERE autoload = 'yes' ORDER BY bytes DESC LIMIT 20;. This is how I identify large arrays, old Transients and plugin entries that often do not need to be autoloaded; a short Step-by-step instructions helps to reliably evaluate the results.

Advanced diagnostics: counting, grouping, recognizing patterns

In addition to the total size, I also check the number and origin of the entries:

• Number of autoloaded options: SELECT COUNT(*) FROM wp_options WHERE autoload='yes';
• Top namespaces (heuristically via prefixes): SELECT SUBSTRING_INDEX(option_name,'_',1) AS ns, COUNT(*) AS cnt, SUM(LENGTH(option_value)) AS bytes FROM wp_options WHERE autoload='yes' GROUP BY ns ORDER BY bytes DESC LIMIT 10;
• Transients that are falsely autoloaded: SELECT option_name FROM wp_options WHERE autoload='yes' AND option_name LIKE '_transient_%' ESCAPE '';

With these queries, I can quickly find statistics caches, page builder artifacts or log remnants, for example. Patterns are often clearly recognizable: several thousand small entries from an analytics plugin or a few very large arrays from a builder.

Limits and measures

For a quick assessment, I use fixed thresholds and use them to organize the next Steps off. This allows me to make decisions without wasting time on gut feeling. The table helps with classification and provides clear options for action in each area. I stick to it because it works reliably in many projects. Especially when resources are scarce Clarity in less than a minute.

Autoload size	Risk	Recommended measure
0-500 KB	low	Document status, check occasionally
500 KB-1 MB	medium	Check largest entries, delete unnecessary ones
> 1 MB	high	Identify top originator, autoload flag set to „no“
> 2-3 MB	critical	Systematic cleanup, remove transients

Clean up safely: step by step

I back up the database before every change, because a complete backup protects me from Errors. With WP-CLI it's quick and easy: wp db export. I delete expired transients: wp transient delete --expired and all of them only if necessary: wp transient delete --all. I specifically remove orphaned plug-in options, for example with wp option delete my_plugin_option. For large entries that do not have to be autoloaded, I implement the flag: wp option update option_name 'value' --autoload=no; then I check the front end and the Backend thoroughly.

Safety net, tests and rollback

After each change, I check these areas in this order: home page (as a guest), a deep subpage, login/logout, admin dashboard and saving a post. I also trigger Cron: wp cron event run --due-now and check the error log. If something breaks, I reset specifically: wp option update option_name 'value' --autoload=yes or set the backup. For large arrays, I export their content in advance with wp option get option_name > backup.json, I can restore it at any time.

What I do not set to „autoload=no“

WordPress uses some options extremely early in the bootstrap or with every request processing. I don't blindly change their autoload flag, even if they are large:

• siteurl, home: Basic URLs, required early.
• permalink_structure, rewrite_rules: Essential for request resolution; if they are not in alloptions, additional database hits follow.
• template, stylesheet: Theme determination.
• blog_charset, timezone_string and other core defaults.

Basic rule: I leave core options and those that are needed on almost every request autoloaded. I concentrate on large, rarely used plugin entries, cache artifacts, logs and old transients.

When options must remain large

Some data may be large, but it does not have to be stored in memory for every request. land. For extensive configurations, I use my own tables instead of wp_options; this keeps the autoload quantity small. User-related information belongs in the user meta, not in global options. I save static content such as long CSS/JS strings as a file and load them specifically. When saving, I set autoload directly to „no“, for example with add_option('name', $data, '', 'no');, to avoid unnecessary Loading to avoid.

Developer guide: Patterns that scale

As a developer, I avoid huge „mega-options“ that collect everything in an array. A narrow core set (autoload=yes) plus targeted lazy loads (autoload=no) is better. Practical patterns:

• Split options: my_plugin_core (small, autoload=yes) and my_plugin_cache_* (large, autoload=no).
• Targeted caching: Frequently required subsets with wp_cache_set() cache instead of having large options autoloaded.
• Using transients correctlyBy default, do not save autoloaded and retrieve consciously; only very small, frequently used transients autoloaded.
• Stop option growth: Do not store logs or unbounded caches in options; enforce maximum size and TTL.

Prevention instead of repair

I keep my plugins lean and deactivate what doesn't bring any clear benefit, so the autoload block remains small. Once a month I check the size with SQL or WP-CLI and document the values. Under Tools > Website status, I monitor notes on automatically loaded options. For highly frequented sites, it is worth using hosting that database wordpress efficiently and keeps wp_options clean. A collection of tried and tested Tuning strategies helps me to recognize problems early and prevent them from becoming serious in the first place.

Automation: small jobs, big impact

I schedule a regular cleanup. A nightly cron job (or a server cron running WP-CLI) removes expired transients and logs the autoload size to a file or table. This allows me to see trends before users notice them. Example process (simplified):

wp transient delete --expired
wp db query "SELECT NOW(), SUM(LENGTH(option_value)) FROM wp_options WHERE autoload='yes';" >> autoload_stats.log

A small health check that saves the top 10 entries with date is convenient. A glance at the log is enough to assign outliers to a specific time - usually after a plugin update or a new function.

Practical example: 60-minute cleanup

In one project I found 5,500 autoloaded options with a total of around 2 MB; the page returned the first byte after about 1.900 ms. After backup, transient deletion, top 20 check and flag adjustments, the loading time was halved to around 500 ms. CPU utilization dropped from 89 % to about 2.5 %, and the backend responded much faster. The procedure was simple: measure, clean, test, document. This is exactly the routine I use regularly to monitor the growth of the wp_options permanently.

Typical causes and fixes

Page builders like to write large cache arrays in options that I prefer to keep in files. discard. I save statistics as non-automatically loaded transients and retrieve them specifically. Logs belong in rotating files, not in wp_options. Failed cron jobs cause old transients; here I adjust intervals and timeouts. These simple changes quickly reduce the amount of autoloads and keep them stable in the long term stable.

Influence of caches, FPC and hosting

An upstream full-page cache (FPC) primarily protects anonymous visitors. But wherever the cache is bypassed - logged-in users, shopping cart, checkout, admin, cron, WP-CLI - the autoload block takes full effect. A fast database server conceals the I/O load, but CPU time for deserialization and RAM consumption remain. Especially on small instances with few FPM workers, a large autoload block leads to queues and timeouts, even though the data comes „from the cache“. The aim is therefore always to keep the block itself small, not just to make the source faster.

Monitoring and key figures

I track TTFB, First Contentful Paint and backend load time before and after each Cleanup. At the same time, I document the autoload size, the number of autoloaded options and the largest entries. A small sheet with date, size and TTFB is sufficient for clear trends. For maintenance, I use monthly SQL queries and a short Maintain database-checklist. This allows me to recognize outliers early on and keep the database wordpress permanently slim.

Multisite: Two construction sites at a glance

In multisite setups, there is autoload load both per site and at network level. I therefore check the wp_options of each site (table prefix per blog) and additionally the network options. Large, globally used arrays affect all sites. Proceed as in the single setup: measure, identify top entries, outsource large values or switch to autoload=no if they are not needed for every request. A reduction is immediately noticeable, especially in the network admin.

Common misunderstandings - briefly clarified

• „Redis solves the problem.“ It reduces the DB queries, but not the size of the autoload block. CPU and RAM costs remain.
• „FPC makes autoload irrelevant.“ Not for logged-in users, Cron and Admin. The FPC advantage does not apply there.
• „Deleting all transients is dangerous.“ It is safe, but only leads to new build-up. Use in a targeted and planned manner.
• „A large block is ok if there are few entries.“ The sum of the bytes and the deserialization is decisive, not the number alone.

Test plan after cleanup

• Front endHome page, random archive and detail page, as guest and logged-in user.
• FunctionsSearch, contact form, shopping cart/checkout (if store).
• AdminDashboard, post list, saving a post/product, plugin page.
• BackgroundExecute scheduled cron events, check error log, randomly measure TTFB.

Summary for quick decisions

Autoloaded options are a silent performance killer, which I can solve with a few clear steps. capture. I measure the size, remove old transients, set unnecessary entries to autoload=no and outsource large data. I then test the frontend and backend and note the measurement points. With an hour of focus work, I often reduce the autoload load by 30-70 % and halve the loading times. If you repeat this routine every month, you can keep the wp_options fast and the site is noticeably responsive.