How to optimize and increase the loading speed of the site with the help of Wp_options table from the database

Clear Wp_options table and auto-load data

Today we are going to take a look at the wp_options table in our WordPress database. In general, this area includes all the functions of WordPress and the database, which is often ignored.

Due to the automatic loading of data in WordPress themes and plugins, not paying attention to this table (especially in the most visited and old websites) can slow down the pages and also slow down the site and as a result your website SEO.

Check out the tips below to learn how to check, troubleshoot, and clear the wp_options table.

 

What is the wp_options table and what are its functions?

The wp_options table contains all the data related to the performance of your WordPress website, such as:

Website URL, WordPress URL, admin email, default category, number of articles per page, time format and…
Settings for widgets, plugins, and skins
Temporary data stored

The following are in the wp_options table, one of which we highlighted, which plays a big role in website performance:

  • option_id
  • option_name
  • option_value
  • autoload (auto load)

One of the most important things to know about wp_options is knowing about a section called autoload. This section contains two variables, yes or no. Which is basically used to control the wp_load_alloptions () function. Autoload data is data that runs on every page of your WordPress.

Just like disabling the download of some JavaScript code on some web pages, this section is easily disabled and enabled.

In general, Autoload data is set to “yes” by default in all tables, which is disabled by autoload developers as some plugins do not need to be loaded on all pages.

Experience has shown that having too much autoload in the wp_options table can cause problems on your WordPress website.

Here are some common problems with this category:

  • The data is generally loaded automatically by the plugins themselves and does not need to be loaded on all pages, for example contact form data does not need to be loaded on all web pages, so it is best to set the Autoload data variable to “no”. Give.
  • You are removing plugins and skins, but their custom settings are still in the wp_options table. This means that the website may also automatically load old unnecessary information when it loads.
  • Some developers save their product data in the wp_options table instead of using their own plugin or shell tables. There are arguments for both, for example some developers are not interested in using unique tables for their plugin. However, the wp_options table is not designed to accommodate hundreds of rows of information, and it is best to optimize it so as not to slow down the site.

What is the maximum allowable use of autoload on a WordPress website? This value can vary from site to site, but in general the data size is usually between 300 KB and 1 MB.

When you start looking at the wp_options table, you will see a volume of about 3 to 5 MB, which you must deactivate or delete altogether to optimize the table and autoload data. If you encounter a volume greater than 10 MB when checking, I must say that the situation is critical and you should check the wp_options table immediately. However, this does not mean that if you do not check, you will have problems, but in general, if you start optimizing now, you will prevent future problems and also improve the speed of your site and SEO.

 

Troubleshoot Autoload in the wp_options table

If you have a problem with slow site speed, one of the reasons that could be causing this problem is the existence of queries or automatically loaded data of an old plugin in the wp_options table.

Below we show you how to check the data size of the autoload column in the wp_options table and easily clear the extra data.

 

Check the data volume of the Autoload column

The first thing you need to do is check the amount of autoload column data being consumed on your WordPress website. To do this, log in to phpMyAdmin.

Select your database from the left side of the page and then enter the SQL tab.

After doing this, enter the following command in the editor and click the GO button.

SELECT SUM(LENGTH(option_value)) as autoload_size FROM wp_options WHERE autoload='yes';

Note that we are teaching you how to install the default WordPress, and you may have used a prefix other than wp_ for security reasons. To use the above command, you must enter the prefix you have defined instead of wp_.

Note that we are teaching you how to install the default WordPress, and you may have used a prefix other than wp_ for security reasons. To use the above command, you must enter the prefix you have defined instead of wp_.

The displayed size of the autoload_size function is based on bytes. Every 1000 bytes is equal to 1 KB and every 1000 KB is equal to 1 MB. So in the image below, our WordPress autoload_size size is 249025 bytes, which means 0.25 MB. In general, this amount of volume is an ideal volume for a website. If your test result is less than 1 MB, you do not need to worry about anything.

For easy conversion of bytes to megabytes, just search for “byte to mb” in Google so that you can do the conversion in a rich Google answers.

Therefore, if the autoload_size size of your website is more than 1 MB, it is recommended that you follow SEO teaching in the continuation of this article to improve the SEO and speed of your website in this way.

You can also use several different commands for more specialized reviews.

The following command displays the size of autoload_size in kilobytes, the number of autoload queries, and the first 10 autoload commands of the database.

SELECT 'autoloaded data in KiB' as name, ROUND(SUM(LENGTH(option_value))/ 1024) as value FROM wp_options WHERE autoload='yes'
UNION
SELECT 'autoloaded data count', count(*) FROM wp_options WHERE autoload='yes'
UNION
(SELECT option_name, length(option_value) FROM wp_options WHERE autoload='yes' ORDER BY length(option_value) DESC LIMIT 10)

If you use the services of the New Relic site, you can use it to find wp_options table query problems. Click Options in the list, you will learn more about queries. In the following example, you can see a handful of autoload data in the wp_options table.

It is safe to say that after a short search we will find that the autoload data of this website is at least 250 MB.

 

Sort Autoload data above

The next step in optimization is to sort the most consumed data in autoload data. You can quickly get a list of the 10 most used data with the following SQL statement.

SELECT option_name, length(option_value) AS option_value_length FROM wp_options WHERE autoload=’yes’ ORDER BY option_value_length DESC LIMIT 10;

Note again that you may have changed your WordPress table prefix during installation to increase security and give it a name other than wp_, for the above command to work, you must replace your table prefix with wp_.

 

Make changes to an autoload data specified in the wp_options table

The next step is to make changes to a high-consumption autoload data.

Redirect 301
As you can see in the image above it is at the top of the 301 redirect list. This query is most likely related to a WordPress SEO plugin and is responsible for transferring pages. In these cases, it is better not to use the plugin to transfer pages and use your default web server tool.

What is the reason for this offer? Because the use of free WordPress plugins to perform page transfer operations may interfere with the operation of the website, requires additional code and resources, and also creates an autoload query on the website, it is recommended that the transfer of pages from Do not use through plugins.

wpurp_custom_template_

The wpurp_custom_template_ query occupies eight positions in the list listed above. In general, you should be able to find the names of these queries and also access the server to access points of the shells and plugins. If you have access, use the grep command below to see if you can find these queries! You can also check these records via SFTP ports.

grep -Ri “wpurp_custom_template_”

Although this method does not work on some servers, we were able to find out by a simple Google search that this query is related to a plugin called WP Ultimate Recipe. This query is an example of the most unnecessary autoload queries in WordPress. So if you have such a plugin in your plugin list, try to remove it completely. In fact, we mean a complete cleanup of the plugin and everything it has ever produced in the database.

um_cache_userdata_

The next type of high-consumption data is related to the data um_cache_userdata_ #, which you can see in a few rows of the list of top 10 autoload high-consumption data.

Given how much data um_cache_userdata_ is at the bottom of the list. We quickly enter our MySQL and call the following 40 high-consumption Autoload queries related to this data.

SELECT option_name, length (option_value) AS option_value_length FROM wp_options WHERE autoload = ‘yes’ ORDER BY option_value_length DESC LIMIT 40;

Or the sum of all the above values related to that prefix:

SELECT ‘sum size in KiB’, ROUND (SUM (length (option_value)) / 1024,0) FROM wp_options WHERE autoload = ‘yes’ AND option_name like “um_cache_userdata_%”

If you notice that there are more queries, you will have to search among plugins and skins again and run the special grep command.

grep -Ri “um_cache_userdata_”

According to our search, we found that this data is related to the famous Ultimate Member plugin, and after a short search on Google, we found an easy way to solve the problems of this plugin. Try to practice the power of search and research with Google so that you can easily find your needs in a targeted search.

In the search we found that there are several ways to solve the problems of this plugin

  • Ultimate Member> Dashboard> User Cache> Clear Cache
  • Ultimate Member> Settings> Advanced> Enable Stop caching user’s profile data> Then save the changes.

Another option for finding autoload options is to click on the editor button, which can show you a list of skins / plugins or a list of their developers’ websites.

Cron Jobs
Another popular option in the autoload section is the frequent use of Cronjobs. In this case, every Cron may be involved, so what should we do when it may crash by clicking the Edit Website button?

For example, a very popular query on WordPress websites is the Cron query called do_pings, which you can find with a simple search to clear these queries. Or make a backup in your database before running.

 

Clear the wp_options table

If you see a lot of the examples we showed you above, now is the time to start clearing all the autoloaded data. It is highly recommended that you try to keep the number of rows in your wp_options table to a minimum. Please try to back it up before deleting or modifying your database. If this is not possible, we suggest you hire a professional.

Like the first thing we told you, to clear the wp_options table you must first log in to phpMyAdmin. Select your WordPress database from the menu on the left and enter the SQL tab. Then enter the following command and click the GO key.

SELECT * FROM `wp_options` WHERE `autoload` = ‘yes’

This command shows you all the data in the wp_options table in which autoload is stored on yes.

By scrolling the rows in order, you will see all the plugins that are not currently installed or in use. For example, in this tutorial we will look at lines of the Jetpack plugin developed by WordPress.

For example, the website does not currently use the Jetpack plugin.

It’s always a good idea to check the documentation provided by the plugin developers before doing anything, sometimes some documentation tells the developer how to clear past tables, or maybe put an option to clear the database in the plugin settings. Sometimes it is better to uninstall and reinstall the plugin once and then check if the database queries have been deleted and then remove it completely if it was deleted. However, in this article we will teach you how to manually clear tables.

For example, in the following command, we call all the autoload data inside wp_options that is specific to the jetpack plugin:

SELECT *
FROM `wp_options`
WHERE `autoload` = ‘yes’
AND `option_name` LIKE ‘%jetpack%’

Then click the Select All button and click Delete to delete the tables completely.

Or you can delete queries directly with the following command:

Now you can clear the autoload data of the table by changing options_name as your plugin or old shell.

Transient cleaning

If you are using a cache, WordPress stores transient records in the wp_options table itself. In general, these types of records should have an expiration time and be cleared over time, although this is not always the case. There are now databases that hold more than a thousand old transient records. Note that transient records are not loaded automatically by default.

You can use the following command to view automatically loaded transient records:

SELECT *
FROM `wp_options`
WHERE `autoload` = ‘yes’
AND `option_name` LIKE ‘%transient%’

However, you can also use the Transient Cleaner plugin to clear transient data from your database.

 

Add an index to Autoload

If clearing the wp_options table data was not enough, you may want to use an autoload index.

This will make the search more efficient.

The test team, called 10 Up, performed several different tests on the wp_options table with autoload records to show how we can improve website performance by adding an index to wp_options queries.

Little Bizzy plugin is a completely free WordPress plugin that can help you a lot by adding an index to autoload the wp_options table using wp_cron for daily reporting.

I hope this article has been useful for you friends, to improve your SEO site, you can read SEO teaching SEO training.

Some images and text are taken from kinsta.

Leave a Comment