WordPress · Performance
Your site stays fast. Here's exactly how.
mindy-sync is a content-syncplugin — it mirrors your published content to Mindy's knowledge base. We treat your site speed as a hard constraint, not an afterthought. Every visual and architectural decision in the plugin is also a performance decision.
Nothing heavy runs while your visitors or editors wait
The only work on a request someone is waiting on is trivial. Everything expensive is pushed off the critical path.
Zero front-end footprint
mindy-sync enqueues no scripts or styles on your public pages and does no work on a page view — your front-end performance budget is completely untouched.Saving a post stays instant
On a publish or edit, the plugin does one thing on that request: a single in-memory note of what changed (just an id — never the content body). Every capture hook runs under a 5 ms budget— it's literally “just an array push” — and logs a warning to itself if it ever exceeds that. The editor never waits.The database write happens after your page is sent
Staged changes are flushed once per request on WordPress'sshutdownhook — after the response has gone to the browser — as a single batched INSERT, never one write per change. A bulk edit of dozens of items is still one row-write, off the critical path.All real work and every network call run in a separate background process
Building the payload, signing it, and sending it to Mindy run inside Action Scheduler— the same battle-tested background-job engine WooCommerce runs on millions of high-traffic stores — on its own request lifecycle. Your editor saves and your visitors' page loads never block on Mindy, the network, or our servers' availability.
The guardrails that prevent bloat and runaway load
Background work is bounded, predictable, and fails safe. Here's what keeps it from ever spiking.
Coalescing
Save the same post five times in a row and we deliver once — superseded duplicates are dropped at claim time.
Bounded batches
The dispatcher claims at most 25 changes per 60-second tick, with a concurrency cap — steady, predictable load, not spikes.
Constant-time scanning at any catalog size
A full re-sync walks content with keyset pagination (id > last_id, ~50 rows at a time) — O(batch), not OFFSET— so it's as light on a 50,000-post site as a 50-post one, and runs off the request hot path.
Exponential backoff
If our endpoint is slow or down, retries space out (1m → 5m → 30m → 2h → 12h, five attempts max) instead of hammering anything.
Instant kill switch
Two independent off-switches are checked at the top of every background tick — flip either and the plugin stops immediately: no claim, no SQL, no network.
Fails safe
Background errors never bubble into your site's responses; a failed sync degrades quietly and retries — it cannot take your page down.
The short version
On a request someone is waiting on
The only thing mindy-sync ever does on a request someone is waiting on is a sub-5 ms in-memory note. Everything else happens after the response, in a queue built to run on the busiest WooCommerce stores on the planet.On the request
A sub-5 ms array push — an id, never the body.
On shutdown
One batched INSERT, after the response is already sent.
In the background
Payload, signing, and delivery — bounded, retried, kill-switchable.