Performance Architecture
Engineered from the ground up so multilingual never means slow.
3-Layer Cache
In-memory, persistent (Redis/Memcached), and database caching layers. On a warm cache, most translation lookups are served from memory.
Batch Preloading
When WordPress loads a list of posts, PerfLocale loads all translation data in a single efficient request instead of one query per post.
Some of that work waits until a page needs it. Translated slugs for categories, tags and other terms are queued, then fetched together in one batch the first time one of them is read, which is when a link to a term is built. A page that reads terms without linking to them usually runs no slug query for them. Block-theme global styles, templates and template parts are left out of the post slug batch, because pages do not link to them.
Smart Query Optimization
Language filtering is added directly into WordPress database queries, so one query does the work of many. On paginated archives it also skips WordPress’s older, full-scan way of counting results in favour of a cached count, so deep pages of a large site stay fast.
Keeping Per-Page Work Small
On-demand loading, batched lookups, and layered caching keep PerfLocale’s own work per page small. Sites over roughly 2,000 translation links should run a persistent object cache to keep it that way. Real-world page speed depends mostly on your theme, hosting, and other plugins.
Background Processing
Long-running operations — XLIFF imports, WPML / Polylang / TranslatePress migrations, full-site string scans, bulk machine translation — move off the request path automatically. Small operations still run inline so you see the result immediately; large ones queue and the admin redirects to a live PerfLocale → Jobs page with progress, cancel, retry, and per-job error visibility.
The system picks Action Scheduler when WooCommerce or the standalone AS plugin is loaded (battle-tested, persistent, has its own admin UI), and falls back to WP-Cron otherwise. Either way, the dispatch decision, retry-with-backoff, per-type concurrency cap, and pause-queue toggle behave identically. State lives in a dedicated perflocale_jobs table with typed columns and indexed status / type / owner lookups — no public pageview ever queries it, so frontend visitors pay zero cost for an active queue. An hourly watchdog sweeps stuck jobs, a daily task clears stale locks and old job rows, and interrupted jobs resume when the plugin is activated again, so the system stays healthy without operator attention. Full wp perflocale jobs CLI surface for headless / CI workflows. Read the full Background Jobs doc →