[PROMOTION] SwiftQueue: async WP-Cron with published, reproducible benchmarks — including the pre-launch run where my own plugin was the bottleneck
Hey r/WordPressPlugins — dev here, launching today after about a month of building. Disclosure up front: this is my plugin.
The problem (you all know it): wp-cron piggybacks on page requests. The request that trips a due event pays for the spawn — and depending on hosting and what's queued, sometimes for the work itself. Add WooCommerce and Action Scheduler and the unlucky visitor is occasionally the one trying to check out.
The caveat before the pitch: if you already run DISABLE_WP_CRON with a real system crontab, the core problem is solved and you don't need the engine half of this plugin. My homepage says the same thing. What it still adds in that setup: it detects the silent failure where the constant is set but the crontab never materialized — no error anywhere, scheduled posts and order emails just quietly stop. It watches for actual external hits to wp-cron.php instead of trusting configuration, and raises it in Site Health with the exact fix.
What the engine does: non-blocking loopback spawns behind a proper concurrency lock (timestamped claim row, shutdown-handler recovery so a fataled worker can't wedge the queue), priority lanes so housekeeping can't starve urgent hooks, a hard "no background work" gate on WooCommerce checkout requests, and Action Scheduler queue visibility without ever running DELETEs against another plugin's tables.
The part you might actually enjoy: I built a benchmark harness before launch — two identical containers, constant-arrival-rate load, cron execution-window tagging, TTFB percentiles. The first valid run showed my plugin made during-cron tail latency worse than stock WordPress — roughly 1s p95 against ~60ms. The "fire and forget" dispatch was quietly blocking the calling request for a full second, while telemetry cheerfully logged every spawn as non-blocking. Fixed it, re-measured: the request that triggers scheduled work went 820ms → 8ms (median), and the slowest 1% during background work went 835ms → 62ms. Typical requests are ~1ms slower — that's the real cost of the due-checks, and I'd rather tell you than have you find it in a profiler.
Raw per-request data, the harness, and the methodology are published here, including the scenarios where the plugin doesn't help: https://getswiftqueue.com/benchmarks
Model: the core engine is free and GPL — the whole engine, not a trial. It's currently awaiting WordPress.org review; until that lands the free build is a direct download on the site. Pro ($49/yr, single site) adds the priority lanes, checkout gating, task run/defer/cancel controls, alerts, and multisite.
Try it without installing anything: there's a WordPress Playground sandbox that boots in your browser tab, and a live demo streaming real spawn telemetry with measured latencies: https://getswiftqueue.com/demo
Would genuinely value technical criticism, especially of the benchmark methodology — that page exists to be argued with. If you spot a hole in how I'm measuring, I'll fix the harness and republish.