Benchmarks
PerfLocale’s own code time, measured on real multilingual sites — not the full page-load number, which depends on your theme, other plugins, hosting and caching too.
- Median around 1 ms on typical multilingual sites
- 0 of 1,440 samples exceeded 5 ms on typical sites — across no-cache, cold-Redis and hot-Redis
- Large sites (over ~2,000 translation links) need a persistent object cache to stay under 5 ms
Summary
For typical multilingual sites — the configuration most readers of this page actually run — PerfLocale adds about 1 millisecond to a page request. In a 2,880-sample matrix across both site topologies and three cache states, not a single one of the 1,440 typical-site samples crossed 5 ms.
For sites with more than roughly 2,000 translation links, the number depends on whether you have a persistent object cache (Redis, Memcached, Object Cache Pro, etc.). With a warm object cache the plugin stays well under 5 ms; without one, it climbs into the 5–8 ms range. We say so explicitly further down.
What we measured
An mu-plugin profiler wraps every callback whose class lives in the PerfLocale\ namespace and records the time spent inside. We subtract the profiler’s own overhead so the published numbers are the plugin’s actual code time, not the measurement artifact.
Not in scope: WordPress’s filter-dispatch overhead, your theme, other plugins, database, PHP boot, network. Those are still in your real TTFB — the plugin is one slice of the whole stack.
Test setup: a real multilingual site (20 translation groups, 40 linked posts, two active languages) on a stock WordPress install with no extra plugins. Numbers below are the median (typical request) and worst-observed value across 40 measured samples per cell, after 5 warm-ups.
Typical sites (under ~2,000 translation links)
This covers the vast majority of real installs — blogs, small to medium business sites, shops with a few hundred multilingual products. PerfLocale’s built-in caching keeps every translation link in memory; no object cache plugin needed.
| Site type | Cache | Median | Worst observed | Over 5 ms |
|---|---|---|---|---|
| Single-site | No object cache | ~0.6 ms | 2.0 ms | 0 / 240 |
| Single-site | Redis cold (after cache flush) | ~1.3 ms | 4.9 ms | 0 / 240 |
| Single-site | Redis hot (steady-state) | ~0.5 ms | 1.8 ms | 0 / 240 |
| Multisite (subdirectory) | No object cache | < 0.1 ms* | 1.6 ms | 0 / 240 |
| Multisite | Redis cold | ~0.1 ms | 1.4 ms | 0 / 240 |
| Multisite | Redis hot | < 0.1 ms* | 1.4 ms | 0 / 240 |
* On the multisite topology the plugin’s code time on a warm request is below our profiler’s own measurement floor — effectively unmeasurable on this hardware. The numbers above are the average of all six tested configurations per row.
Bottom line for typical sites: the median is roughly 1 millisecond, almost every request lands under 2 ms, and across 1,440 measured samples we did not record a single one over 5 ms in any cache state.
Large sites (more than ~2,000 translation links)
Past a few thousand linked translations the plugin can no longer keep the full link table in memory and falls back to a per-link cache. For those sites a persistent object cache is required to stay under 5 ms:
| Site type | Cache | Median | Worst observed | Over 5 ms |
|---|---|---|---|---|
| Single-site | No object cache | ~7.8 ms | 11.1 ms | 240 / 240 |
| Single-site | Redis cold | ~4.4 ms | 8.7 ms | 46 / 240 |
| Single-site | Redis hot | ~2.2 ms | 3.9 ms | 0 / 240 |
| Multisite | No object cache | ~5.1 ms | 8.8 ms | 135 / 240 |
| Multisite | Redis cold | ~2.2 ms | 4.2 ms | 0 / 240 |
| Multisite | Redis hot | ~0.9 ms | 2.0 ms | 0 / 240 |
Recommendation for large sites: install a free Redis Cache plugin (or whatever your host provides). With Redis warm, even the largest tested configuration sits comfortably under 5 ms. Without one, plan for a higher floor.
Across the six tested configurations
We measure six combinations of the most impactful settings: URL prefix style (slug like /en/ or locale like /en-us/), whether the default language hides its prefix, whether strings translate from files or the database, and whether the language fallback chain is enabled. Numbers below are the median plugin code time with a hot Redis cache — the configuration most production sites run.
| Configuration | Prefix | Hide default | Strings | Fallbacks | Single‑site | Multisite |
|---|---|---|---|---|---|---|
baseline | slug | off | files | off | ~1.5 ms | ~0.7 ms |
locale_prefix | locale | off | files | off | ~1.5 ms | ~0.7 ms |
hide_default | slug | on | files | off | ~1.5 ms | ~0.7 ms |
db_strings | slug | off | database | off | ~1.5 ms | ~0.7 ms |
db_hide_default | slug | on | database | off | ~1.5 ms | ~0.6 ms |
fallback_chain | slug | off | files | on | ~1.5 ms | ~0.6 ms |
The configuration column makes almost no difference. Flipping URL prefix style, hiding the default-language prefix, switching strings from files to the database, or turning on the fallback chain — each costs at most a few microseconds of plugin code time. The dominant factor is your cache state (no-cache vs. cold vs. hot Redis), shown in the tables above; the per-feature column is essentially flat.
That means: pick the URL style and string mode that fit your workflow, your SEO strategy, and your migration plans. Don’t pick them for performance — PerfLocale doesn’t charge you for any of them.
Does it stay fast at scale?
We re-measured with 10,000 posts seeded across two languages on the same test sites. With a persistent object cache, internal hot-path operations stay sub-millisecond even at 10× the data volume:
| Internal hot-path operation | Mean at 10K scale | DB queries |
|---|---|---|
| Detect a post’s language (warm) | ~0 ms | 0 |
| Filtered WP_Query (20 posts in one language) | 0.07 ms | 0 |
| Batch-prime translations for 50 IDs | 0.01 ms | 0 |
| Get 200 strings from the database | ~0.05 ms | 1 |
What this doesn’t mean
- This is the overhead PerfLocale adds to a request, not the total request time. WordPress core, your theme, other plugins, the database and PHP boot all still contribute.
- Numbers from one hardware configuration don’t transfer 1:1 to another. A host with slow MySQL or missing OPcache shows worse numbers across the board — for PerfLocale and for everything else on the site.
- Production sites usually keep caches warm all day. The cold-Redis row above represents what happens immediately after a cache flush, which is rare in normal operation.
- The 5 ms target is a self-imposed bar for the plugin’s own code time. The plugin will function on any WordPress install regardless — it just may be a millisecond or two slower on a large site without an object cache.