Methodology first. Then the numbers.
One run is published below, with its raw data and its unflattering parts left in. Read the method first — it explains why the headline number is about the worst request, not the average one.
The visitor who arrives at the wrong moment.
Two identical WordPress 7.0.4 sites, PHP 8.2, same hardware, same synthetic chore load. One runs stock WordPress; the other adds SwiftQueue. 3,001 requests each at a steady 5 per second for 10 minutes. Times are TTFB — how long until the page starts arriving.
Start with the boring row. For a typical visitor, SwiftQueue changes essentially nothing — it is about 1ms slower, which is the cost of it being there at all. Anyone selling you a plugin that makes the typical page dramatically faster is measuring something else.
| Requests arriving while chores ran | Stock WordPress | With SwiftQueue |
|---|---|---|
| Typical (p50) | 25.7ms | 26.9ms |
| Slow tail (p95) | 36.7ms | 57.7ms |
| Worst 1% (p99) | 835ms | 62ms |
| Single worst request | 835ms | 62ms |
The p99 row is the whole product. On stock WordPress one unlucky visitor waited 835 milliseconds — because on a default install, the visitor whose page load triggers the chore run waits for the server to answer. With SwiftQueue the worst request in the entire ten minutes was 62ms.
The unflattering part, in the same size type: at p95 SwiftQueue was slower — 57.7ms against 36.7ms — and across all 3,001 requests it was consistently a shade slower than stock (p99 45.8ms against 31.0ms). It does real work on every request, and that costs something. The trade it offers is a few milliseconds on many requests to remove a near-second stall from a few.
What this run does not prove.
It is one run, on one machine. Local Docker on a Windows workstation, not a fleet and not a long series. Treat it as a first honest data point, not a law of nature.
The chore load is synthetic. Four fixed tasks — a slow API-style wait, a database writer, a CPU burner, a fast one — chosen and published before any result existed, so they can't be tuned to flatter.
Your hosting is not this container. If your host already runs a real system crontab, the stall this measures may never happen to you in the first place.
Sample sizes differ slightly. 92 during-cron requests on stock, 80 with SwiftQueue, out of 3,001 each. Small samples at the tail; that's why the raw data is downloadable.
Reproduce it yourself — the harness is in the repository:
RATE=5 DURATION=600 bash bench/run.sh
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.