Methodology first. Numbers when they're real.
No benchmark runs have been published yet. This page documents how they will work before the first one exists, so you can judge the method before you're asked to trust a result.
Distribution, not averages.
SwiftQueue's claim is narrow: scheduled work moves off the requests visitors wait on. Averages hide that entirely — most requests never coincide with a cron run, so the mean barely moves.
Two identical WordPress sites, same hardware, same content, same synthetic cron load. One difference: stock WP-Cron versus SwiftQueue. Reported:
| Metric | What it tells you |
|---|---|
| p50 | The typical visitor. Expected: little to no change — and we lead with that. |
| p95 / p99 | The unlucky visitors. This is where cron collisions live. |
| max | The single worst request in the run. |
| during-cron subset | Only the requests that landed while a cron run was executing — the honest core of the comparison. |
Scenarios where SwiftQueue won't help — published anyway.
No scheduled tasks
Nothing queued means nothing to move. Expect no difference, and the run will say so.
Very low traffic
Cron rarely collides with a visitor when there are few visitors.
Server crontab already configured
If you've set DISABLE_WP_CRON with a real crontab, you already solved the core problem.
Only fast tasks
Sub-50ms tasks barely register in a request. The problem is slow tasks, not all tasks.
The rules the harness runs under.
The harness is public. Fork the repo, press run, get comparable numbers.
Raw data ships with every chart. Per-request timings, downloadable.
Conditions on the same screen as the number. Host, PHP, WordPress, plugin set, request rate, duration.
Results publish automatically from CI. Nobody reviews them first. A regression shows on the chart.
No named-competitor comparisons. The baseline is stock WordPress, which is the honest one anyway.
Scenarios are fixed in public before results exist. Tuning the scenario until the number looks good is how benchmarks become lies.