What Is WP-Cron? How It Can Slow WordPress

Every WordPress site has a scheduler called WP-Cron. It handles scheduled posts, update checks, email queues, backup jobs and other work registered by plugins.

WordPress explains that WP-Cron checks for due tasks when page traffic arrives. That makes it portable on shared hosting, but timing depends on visits. A quiet site may run a scheduled task late. A busy site may check the queue far more often than it needs to.

WordPress normally tries to spawn the work in a separate HTTP request, so WP-Cron is not automatically a performance problem. Trouble starts when loopback requests fail, a plugin registers heavy jobs, tasks overlap, or the queue grows faster than it can clear.

How to tell if this is hurting you

Start with evidence. WP-Cron is one possible cause of inconsistent response time, not the answer to every slow WordPress site.

Check these four things:

1. Look at the scheduled-event list with WP-CLI or a trusted cron-inspection plugin.
2. Check whether the same task is queued many times or stays overdue.
3. Compare PHP-FPM and database slow logs with the scheduled run times.
4. Confirm that WordPress loopback requests work in Site Health.

Backups, imports, mail queues and WooCommerce jobs are common sources of heavy cron work. The right fix may be changing one plugin schedule rather than changing WP-Cron itself.

A reliable fix for suitable sites

When page-triggered checks are genuinely causing trouble, we keep WordPress handling the queue but move the trigger onto a reliable schedule.

Step 1: stop page loads spawning WP-Cron. Add this to wp-config.php:

define('DISABLE_WP_CRON', true);

Step 2: call WP-Cron over HTTPS on a five-minute schedule. The scheduler still asks WordPress to run its own due jobs through the normal HTTP endpoint:

curl --fail --silent --show-error \
  'https://www.example.com/wp-cron.php?doing_wp_cron' > /dev/null

We monitor the HTTP result and alert on repeated failures. The exact interval depends on the site, but five minutes suits most brochure and small-business WordPress installs.

Do not add this blindly. A duplicate scheduler, blocked loopback request or badly behaved plugin can make things worse. Check the existing setup first, then confirm scheduled posts, forms, email and backups still run after the change.

What this changes

Visitors no longer provide the timing signal for scheduled work. WordPress still owns the task queue, and the HTTPS request gives it a predictable chance to run. That is a cleaner boundary than calling wp-cron.php directly with PHP, which can behave differently from a real web request on some hosting stacks.

On Cam Cloud, we review the existing cron setup during migration and use the HTTP approach when a scheduled trigger is appropriate. It is one of the infrastructure details covered by our managed WordPress hosting.

If occasional slowness is the symptom, also check Core Web Vitals in plain English and the other work included in a WordPress care plan. If your current host cannot give you the logs or scheduling controls needed to diagnose it, we can migrate your WordPress site and test the behaviour before switching DNS.