Someone is paying for your backups with their waiting time.
WordPress runs scheduled tasks inside a visitor's page load. Most visitors never notice. The unlucky one waits for your entire cron queue.
SwiftQueue hands that work to a separate background request. Your median page time barely moves — that was never the problem. The 99th percentile is where cron was hiding.
Three moving parts. No magic.
Stop cron running inline
WordPress attaches its cron runner to the tail end of a visitor's request. SwiftQueue removes that hook.
Fire a separate request
A non-blocking loopback call to wp-cron.php, with a concurrency lock so two workers never run the same queue.
Visitor gets their page
The page returns immediately. Scheduled work runs in its own process, on its own time.
If the dispatch fails — a host that blocks loopback requests — cron is handed straight back to WordPress for that request. A blocked loopback degrades to stock behaviour, never to a queue that silently stops.
Every number will be reproducible by a stranger.
SwiftQueue launches with a public benchmark harness that runs nightly in CI and publishes automatically — including the raw per-request data, the conditions of every run, and the scenarios where SwiftQueue doesn't help.
What this is not.
Not a caching plugin. It won't change how fast your pages render. It changes what else is competing for the request.
Won't fix a slow theme or a bloated page. If your homepage takes two seconds on its own, cron was not your problem.
Does nothing visible on a site with no scheduled work. If nothing is queued, there is nothing to move.
Cannot fully fix WordPress's cron storage. Core keeps every scheduled event in one option with no locking. SwiftQueue avoids making that worse, and documents it plainly.