On this page
Autoload bloat means rows in wp_options marked autoload=yes that WordPress loads on every request. When a page builder or leftover plugin stores megabytes there, each cache miss, wp-admin load, and cron run pays a heavy cost before useful work starts. LiteSpeed can hide the problem on a warm full-page cache, but a missed page still unpacks that data into PHP memory. On shared hosting with CloudLinux LVE, that often looks like a memory fault when the real issue is oversized autoload data.
How to measure autoloaded size
Work on staging first so you can see the pile without risking the live site. WP-CLI gives a clear list of what loads every time:
wp option list –autoload=on –fields=option_name,option_value –format=tableThat output is noisy, so pair it with a SQL sum of LENGTH(option_value) where autoload is yes. phpMyAdmin can run the same SUM query if you prefer a browser. You want a few options that are hundreds of kilobytes each, not hundreds of tiny rows. Common culprits are page-builder CSS caches, abandoned plugin settings, stats dumps, and serialized transients that never expired.
Putting Redis in front of an 8 MB autoload does not fix the PHP side. Redis will hold the blob, and PHP will still unpack it into memory on every request that misses or bypasses full-page cache. CloudLinux LVE then reports memory pressure that is really an autoload problem.
Change autoload on staging first
For a named option you have identified, set autoload to no, or delete the option if the plugin is gone. Do not run a blanket UPDATE wp_options SET autoload='no' without a WHERE clause. After the change, load wp-admin and a few front-end templates, then only promote the fix to production. Some plugins re-set autoload on the next save; that is a plugin bug, and the lasting fix is removing the plugin rather than fighting it every week.
WP Toolkit will not warn you that autoload is fat. You have to query it yourself. A multi-megabyte autoload on a CloudLinux account often shows up as memory faults and a ticket that asks for a VPS when the real work is removing the leftover plugin and its option rows. Remove the plugin, remove or reflag the option, then confirm the SUM dropped.
If the site is still slow after cleanup
Once autoload size is sane, a remaining slow query may still be a table scan. Run EXPLAIN on that query before you add RAM or move plans. See EXPLAIN a query before you buy RAM for the next step.
Tagged
Was this article helpful?
Be the first to rate this article.



