Why is WordPress still slow? 7 Hidden causes and fixes

You have compressed the images, activated the cache, and removed the plugins you weren’t using. PageSpeed even seems to agree with you. But WordPress continues to take too long to respond.

The problem with slow WordPress might not be in what the browser downloads, but in everything that happens before: queries that don’t finish, accumulated tasks, options that load unnecessarily, or blocked processes.

Installing another plugin to try to speed up WordPress won’t always solve the problem. Sometimes it just adds more work to a WordPress that already has too much. Here are seven less visible causes, how to detect them, and what you can do to resolve them.

First, find out where the slowness occurs

Don’t start cleaning the database or randomly disabling functions. First, try to locate the problem.

Check if the slowness:

• Affects the entire site or just one page.
• Also appears within the admin panel.
• Is concentrated on products, orders, or WooCommerce processes.
• Occurs continuously or only at certain times.
• Coincides with backups, imports, or email sends.
• Appears before the page starts to display.

The time it takes for the server to send the first byte (known as TTFB) can give you an initial clue. If the wait occurs before the browser starts receiving content, compressing another image probably won’t solve the problem.

What you should check first

Symptom	Possible cause	Where to check it
The entire site takes a long time to start loading	Autoload options or slow queries	Site Health or Query Monitor
Tasks run late or don’t complete	WP-Cron or loopback requests	WP Crontrol or Site Health
WooCommerce delays orders, emails, or subscriptions	Stuck scheduled actions	WooCommerce → Status
The database grows continuously	Transients or plugin remnants	Database cleaning tool
Only one screen is slow	Inefficient or duplicated query	Query Monitor
Slowness appears at certain times	Cron, backups, or automatic processes	WP Crontrol or server logs

Apply one change at a time and measure again. If you modify five elements at the same time, the site may improve, but you won’t know what was causing the problem or how to act if it happens again.

To complete the diagnosis, you can use ConnectiLogs, a tool from cdmon that visually presents server log information and helps detect errors, failed accesses, or suspicious behavior.

Before modifying the database or WordPress configuration, create a backup. If possible, test the changes in a staging environment first.

WordPress loads too many autoload options

What happens?

WordPress stores many of the data it needs to function in the wp_options table, such as theme settings, plugin configurations, and other site preferences.

Some of these options are marked as autoload, meaning WordPress automatically loads them every time someone visits a page, even if they are not needed at that moment.

This is not a problem when there is little data. The site can start to slow down when it accumulates data from plugins you no longer use, deleted themes, or tools that store more information than necessary.

How to solve it?

Go to:

Tools → Site Health → Status

WordPress may show a warning if it detects a large number of automatically loaded options.

To investigate their origin, you can use a tool like Advanced Database Cleaner or perform a query using WP-CLI, available in cdmon starting from the Senior hosting plan, if you have technical knowledge. The goal is not to delete the options that take up the most space, but to identify which plugin or theme created them.

Just because an option is large doesn’t mean it’s unnecessary: it may store important information for the site’s operation.

Especially look for:

• Settings of plugins you no longer use.
• Temporary information that has been stored permanently.
• Repeated data.
• Very heavy configurations from a previous theme.

Once the origin is identified, check if the plugin itself includes a function to clean or regenerate those data. If it is still installed, updating it or reviewing its configuration is usually safer than manually deleting records.

WP-Cron is running too many tasks

What happens?

WP-Cron is responsible for WordPress’s scheduled tasks: checking for updates, publishing posts, sending notifications, running backups, or activating processes for certain plugins.

Unlike server-scheduled tasks, WP-Cron is triggered when someone visits the site. Therefore, on a page with many visits, it can run more times than necessary, while on one with little traffic, some tasks may take a long time to complete.

The problem is usually not with WP-Cron, but with the tasks that some plugins add to this system.

If scheduled posts don’t appear on time, emails are sent late, or the site always slows down at certain times, it’s possible that one of those tasks is running with errors or too frequently.

How to solve it?

You can review the events with WP Crontrol, from:

Tools → Cron Events

The tool shows which tasks are scheduled, when they should run, and how often. Pay attention to:

• Events that should have run and appear delayed.
• Tasks that repeat every few minutes without a clear reason.
• Automatic tasks created by plugins you have already removed.
• Several similar tasks created by the same component.

Don’t delete a task just because you don’t recognize its name. Look up the hook name to identify which plugin created it. If the task reappears after deleting it, it means some plugin or component of the site continues to schedule it.

On sites with high traffic or numerous automatic tasks, it may be more stable to schedule their execution directly from the server, instead of relying on visits.

This change must be done correctly: if you disable WP-Cron without first setting up a task to replace it, posts, emails, and other scheduled processes may stop running.

WooCommerce has stuck scheduled actions

What happens?

WooCommerce and many of its extensions use Action Scheduler, a system that handles executing automatic tasks in the background. For example, it can send emails, renew subscriptions, communicate information to other applications, or update orders.

When these tasks accumulate, WordPress doesn’t always show an error. Instead, you may notice that orders take a long time to update, emails arrive late, or the admin panel becomes increasingly slow.

You can review the queue at:

WooCommerce → Status → Scheduled Actions

Action Scheduler may also appear in Tools → Scheduled Actions, depending on the installed plugins. Its official documentation covers both paths.

Filter the actions by status:

• Pending: waiting to be executed.
• Failed: attempted to execute but didn’t complete successfully.
• In progress: should be processing.
• Completed: have already finished.

Having pending actions doesn’t necessarily imply a problem. The warning sign appears when their number constantly increases, they have been waiting too long, or many fail with the same hook.

How to solve it?

Imagine you find hundreds of failed tasks related to a subscription extension. Deleting them may empty the list for a while, but it won’t solve the problem causing the failures. If you don’t fix the cause, the tasks will accumulate again.

Open one of the failed tasks, locate its name (hook), and check the log to find out why it wasn’t completed. Then:

1. Identify which plugin or extension created the task.
2. Update that plugin and the add-ons it needs to function.
3. Check if it depends on a connection with an external service, such as a payment, subscription, or email platform.
4. Fix the error indicated in the log before running the task again.
5. Verify that pending tasks start to complete and that the queue decreases.

Very large queues may require processing via WP-CLI or technical intervention. Action Scheduler documentation recommends WP-CLI for high loads because it avoids some limitations of regular web requests. You can check their WP-CLI documentation.

In cdmon, access to WP-CLI is available starting from the Senior hosting plan. If your plan doesn’t include it or you don’t have experience using commands, contact the Support team before intervening in the queue.

The database accumulates expired transients

What happens?

Transients allow temporarily storing data that takes longer to obtain, such as the result of a query or the response from an external service. This way, WordPress can reuse them for a while instead of regenerating them every time someone visits the site.

When they work well, they help performance. The problem arises when they expire but are not deleted correctly, or when a plugin generates thousands of them.

There’s no need to clean transients every week. Nor should they be treated as garbage by definition. WordPress and plugins can recreate many of them after deleting them.

If the wp_options table has grown too large, check how many transients there are, how much space they occupy, and which prefixes repeat. A large number linked to the same plugin can indicate where to start investigating.

How to solve it?

With access to WP-CLI, you can delete only the transients that have already expired with this command:

wp transient delete –expired

You can check its operation and available options in the official WP-CLI documentation.

Deleting all transients is also possible, but it shouldn’t be the first option. Some processes will have to rebuild them, and that can cause a temporary increase in server workload.

If they quickly accumulate again, the cleaning will have only hidden the symptom. Check which plugin is creating them and if there is any update, error, or configuration that explains that behavior.

Loopback requests are blocked

What happens?

A loopback request occurs when WordPress connects with its own site to start automatic tasks or check that it responds correctly. It’s, simply put, like the site visiting itself.

If it fails, WordPress may show a warning in:

Tools → Site Health → Status

You can also detect:

• Scheduled events that don’t run.
• Scheduled posts that are delayed.
• WooCommerce actions that remain pending.
• Internal processes that end due to timeout.

WP-Cron, Action Scheduler, and loopback requests are related. If all three show problems at the same time, you might be seeing different consequences of a single blockage.

How to solve it?

Here it’s advisable to read the specific error, not just the loopback warning.

A 401 or 403 error may indicate that a password, a security plugin, or a server rule is preventing WordPress from connecting with its own site. If a timeout appears, it means the server took too long to complete the request. The failure may also be due to incorrect domain, SSL certificate, or web redirection settings.

Check the PHP and server error logs just when the failure occurs. These logs can show which plugin, file, or process is causing the problem.

Also check if any security plugin, maintenance mode, or password protection prevents WordPress from accessing wp-cron.php or the REST API.

If a security measure causes the blockage, don’t disable it permanently. Identify the responsible rule and add an exception only for the connection WordPress needs to make.

A slow query is slowing down a specific screen

What happens?

If the entire site works well except for the order list, a search, the editor, or a specific page, the problem may be in a database query.

Query Monitor allows analyzing the queries executed during the load and associating them, when possible, with the plugin, theme, or function that generated them.

Install Query Monitor temporarily and open the page or section of WordPress that works slowly. Then, review:

• Queries that take much longer than the rest.
• The same query executed dozens or hundreds of times.
• Database errors.
• External HTTP requests.
• The component responsible for each operation.

Don’t focus only on the slowest query. A 200-millisecond query may not be serious if it runs once. Another 20-millisecond query can become a problem if it repeats 300 times during a single load.

How to solve it?

If Query Monitor points to a plugin, check if there is an update or if any of its functions can be disabled. You can also temporarily try another tool that performs the same function and compare the result.

In large stores, it may be necessary to review:

• The amount of information the site processes.
• The number of products or results displayed on each page.
• The filters and searches used by visitors.
• The way data is organized in the database.

Modifying the way WordPress searches and organizes database information requires advanced knowledge. If you can’t identify which plugin or function performs that search or don’t know what it’s for, it’s better to seek technical help before making changes.

A deleted plugin has left residual data and tasks

What happens?

Deactivating a plugin prevents its code from running normally. However, it doesn’t necessarily delete its tables, options, folders, cron tasks, or generated files.

That doesn’t mean all deactivated plugins slow down WordPress. An inactive folder usually doesn’t affect performance just by existing. The problem is the residues that continue to load or process.

Review:

• If there are tasks from the plugin in WP-Cron.
• If it retains autoload options.
• If it created its own tables.
• If it left large amounts of files in wp-content/uploads.
• If it has an option to delete its data upon uninstallation.

How to solve it?

If the plugin is still installed, check its settings before deleting it. Some tools include options like «delete data upon uninstallation,» but don’t activate them by default to avoid accidental losses.

If you already deleted it, you can reinstall it temporarily in staging and use its own uninstallation process. Do this only when you’re sure it’s the same plugin and you no longer need its data.

Don’t delete a table based solely on its name. It could contain orders, forms, statistics, or configurations still used by another part of the site.

Installing another cleaning plugin shouldn’t be the automatic response either. First, identify the specific residues and decide what tool you need to remove them.

How to know if you’ve solved the problem

After correcting one of these causes, repeat the initial test exactly:

• Open the same page or screen.
• Perform the test under similar conditions.
• Check the response time.
• Review if queues and errors decrease.
• Confirm that related functions continue to work.

Don’t just check the homepage. If you’ve intervened in WooCommerce, test an order. Also, if you’ve modified WP-Cron, check that tasks run. If you’ve cleaned data from a plugin, review the functions that depended on it.

The goal is not to achieve an «empty» database, but to eliminate unnecessary work without breaking what WordPress needs.

Frequently Asked Questions