Measure multilingual performance responsibly
A useful performance comparison isolates the cost of multilingual rendering from page caches, CDN distance, different templates, and unrelated content. One fast load or one slow administration request is not enough evidence.
Define the question first
Choose one of these questions:
- How much does an uncached target route add to the equivalent source render?
- Does a persistent object cache improve repeated target renders?
- Does a translation edit invalidate only the expected runtime output?
- Does the full-page cache serve source and target paths independently?
- Does an archive scale acceptably when it displays many localized objects?
Do not combine all five into one measurement.
Choose comparable routes
Use one published canonical post with:
- the same template in both languages;
- complete title, excerpt, body, and required metadata translations;
- the same media and taxonomy relationships;
- no visitor-specific output;
- no remote shortcode or third-party script that changes between runs.
Compare its source and target URLs. Do not compare the source homepage with a translated product page or two posts with different layouts.
Control the environment
Record:
- WordPress, PHP, POM Translate, theme, and relevant plugin versions;
- whether a persistent object-cache backend is active;
- whether POM Cache HTML or Progressive JSON is enabled;
- whether a CDN or reverse proxy is in front of the origin;
- the test location and authentication state;
- the exact URLs and active locales.
Use a signed-out session. Disable browser-language redirection during route comparison so a request does not unexpectedly measure a redirect.
Do not enable debug output on a production response merely to collect timing data. Use a staging environment or approved observability tooling when deeper inspection is required.
Separate cold and warm behavior
Measure at least three states:
| State | What it shows |
|---|---|
| First uncached WordPress render | Source queries, translation preparation, skeleton assembly, theme and plugin work |
| Repeated WordPress render with warm object caches | Reuse inside or across WordPress requests |
| Full-page or CDN hit | Delivery that may bypass WordPress and POM Translate entirely |
Label each result correctly. A CDN hit cannot demonstrate that POM Translate’s renderer became faster.
Use a repeatable sequence
- Bypass or clear the CDN for the test URLs.
- Purge the relevant source and target full-page entries.
- Request each route once to confirm correct content and prime normal dependencies.
- Collect several source-route renders under the same cache state.
- Collect the same number of target-route renders.
- Alternate source and target requests to reduce time-based bias.
- Record response time and server timing available from the approved tooling.
- Use the median and note the range; do not report only the fastest sample.
- Repeat with the persistent object cache warm.
- Test the full-page layer separately after the origin comparison is complete.
Keep machine translation, bulk generation, imports, backups, and cache warmers idle during the run. They are background workloads, not visitor rendering.
Interpret the difference
Some target overhead is expected because the request may:
- resolve a locale prefix and localized slugs;
- load target translation maps;
- reconstruct a body from its skeleton;
- restore protected markup;
- localize links, menus, terms, and metadata;
- emit localized SEO information.
A large difference does not identify which step is responsible. Compare:
- a title-only post with a structured body post;
- a single post with a translated archive;
- object-cache cold and warm requests;
- origin renders with and without a full-page hit.
This narrows the responsible surface without exposing private production diagnostics.
Check correctness alongside speed
Every measured response must also have:
- the intended active locale;
- the correct canonical object;
- no unresolved skeleton or protected markers;
- correct source fallback for deliberately empty values;
- localized internal links and canonical metadata;
- no target content leaking into the source route;
- no personalized or authenticated output in a shared cache.
A fast response in the wrong language is a failed measurement.
Report enough context to reproduce it
A useful performance report includes the test question, environment, route pair, cache state, sample count, median, range, and correctness result. Remove credentials, cookies, customer data, and signed headers before sharing it.
Read What the POM Translate architecture optimizes when interpreting origin results, and How translation changes interact with caches when the origin is current but a public response remains stale.