Autoloaded data in WordPress refers to options stored in the wp_options table of the database that are automatically loaded on every page load. The autoload column in the wp_options table indicates whether or not an option should be autoloaded.
Starting with WordPress 6.6, autoloaded data is one of the metrics used to determine site health.
When a page loads, WordPress performs a query to fetch all options with autoload set to ‘yes’ and stores them in memory, which is then accessible throughout the WordPress request lifecycle. This data is fetched in a single query during each page load.
This is supposed to be data that is frequently accessed, but too much autoloaded data increases memory usage, which can negatively impact server performance and strain the database. During each page load, WordPress queries the wp_options table to retrieve all autoloaded options. If there are too many autoloaded options, it becomes an complex and expensive query.
If there are too many queries made at the same time and too much data ends up stored in RAM, this can result in high memory usage resulting in the server slowing down or crashing.
Object caching (like using Redis or Memcached) can help mitigate the impact of loading large amounts of autoloaded data. Some hosting providers, like WP Engine, impose limits on the amount of data that can be stored in object cache, often around 1MB. Exceeding this limit can lead to errors, such as 502 Bad Gateway, depending on your server’s configuration.
Long running database queries or high memory usage can lead to timeout errors or server crashes.
Here is a query I use to determine the size of my autoloaded data:
SELECT SUM(LENGTH(option_value)) AS total_size
FROM wp_options
WHERE autoload = 'yes';If you want to see the results in MB, you can use this query:
SELECT SUM(LENGTH(option_value)) / (1024 * 1024) AS total_size_mb
FROM wp_options
WHERE autoload = 'yes';I work on an ecommerce site that uses a lot of plugins. Too many, in my opinion, although each serves a crucial function.
Many of these plugins have autoloaded data.
Using the query above, I see that I have 2.52MB of autoloaded data. That’s about 4x what I’d like it to be. It means that every user on every page begins by querying the database, fetching 2.52 MB of data which is places into an array, and then placing that array in memory. Every single user, on every single page. Autoloaded data is not stored in browser cache. It is retrieved from the database every time every users goes to any page.
The more traffic a site gets, the worse the problem is gonna be.
This query will give me each autoloaded item, in descending order of size:
SELECT option_name, LENGTH(option_value) AS value_length
FROM wp_options
WHERE autoload = 'yes'
ORDER BY value_length DESC;Here are the results:
- mwb_hubwoo_guest_user_cart, 530568
- permalink-manager-uris, 517778
- astra-settings, 419137
- _transient_saswp_nav_menu261, 249756
- wphb_scripts_collection, 96735
- wc_connect_services, 70699
- jetpack_static_asset_cdn_files, 67264
- wccsp_restrictions_global_settings, 39951
- rewrite_rules, 37862
- rank_math_content_ai_prompts, 36437
- groovy_menu_settings_fonts, 31188
- wpseo_taxonomy_meta, 29862
- BeRocket_AAPF_getall_Template_Styles, 25264
The first thing that stands out is that I am autoloading a huge hubspot option, even though we are no longer using hubspot. So this data does not need to autoload. In fact, that row can probably be removed from the database altogether.
The next giant chunk of data comes from the permalink manager, and it really seems crazy big. I looked at the value, and it really is crazy. The site was rebuilt a couple of years ago and the url structure was changed, so there are a ton of redirects and permalinks to manage, but this number still seems crazy. Looking at the value, I see permalinks created in there for actions undertaken in the admin by our marketing department. Nobody needs this stuff, autoloaded or not.
The culprit here is that whoever installed this plugin never actually set any exceptions. Everything is getting a permalink, including admin actions. But the only thing that really needs permalinks are posts and pages the front end user visits. I’m going to set my exclusions like this:
Having done this, I still need to regenerate all the permalinks, so that the new settings take effect. This cuts the file down from 500KB to about 190KB.
The site was recently rebuilt using the Astra theme, which has won praise for its speed. We are using Astra Pro, which comes with a number of modules: Colors & background, Typography, Spacing, Blog Pro, Sticky Header, Site Layouts, Nav Menu, Site Builder, Page Headers, WooCommerce, Easy Digital Downloads, Learn dash, Lifter LMS, and White Lable. On the aforementioned ecommerce site, all of the above modules are turned on through (and including) Woocommerce.
Each module allows for a number of settings: font size, font style, margins, borders, cart behavior, search behavior, various types of sticky menus, etc etc etc. Each module adds to the size of the astra settings json object, which is one of the autoloaded options.
I can’t delete this item – if I do, I will lose all my settings. But I might want to consider whether or not I really need all those pro modules activated. Without them, and all the settings that come with them, I might be able to trim about 20 – 25% of the size from this item. (I know this because I tried it).
Does it need to be set to autoload, though? Basically, it is only needed on pages that require it. Because it is the theme settings, that means every page. If not set to autoload, the page will still need to retrieve it from the database, in an additional call. However, I use nitropack for my cache. All of these pages are going to be cached, as rendered, with these settings, so autoloading the settings is probably not necessary.
After that, there’s _transient_saswp_nav_menu261, at 250KB. A quick glance at the value of that options indicates this is from a plugin called max mega menu, which we are no longer using. I can probably delete that entry, but for now I’ll just set autoload to no.
Once I’ve made these changes, my autoloaded data is .88MB, which means I’ve cut it by almost two thirds.
It’s crucial to test all these changes thoroughly in a staging environment first. Pay particular attention to performance metrics and page speed.