WPML

WPML Performance Triage – Slow Admin, Translation Dashboard Timeouts, Front-End Lag

WPML performance issues (slow admin pages, dragging frontend, the Translation Dashboard timing out) almost always trace back to one of a few common factors. This page walks through them in the order to check, before you assume the problem is WPML itself.

  1. Confirm Where the Slowness Is

    • Frontend slow, admin fine → likely full-page caching configuration or a frontend-heavy plugin.
    • Admin slow, frontend fine → likely wp_options autoload bloat, a heavy admin-only plugin, or an underpowered server.
    • The Translations Dashboard specifically slow → likely a large number of posts in the dashboard query and not enough PHP memory or execution time.
    • Translation operations slow → likely connectivity to translation services; check the Communication log in WPML > Support (see Logs for which log answers which symptom).

  2. Check Server Resources

    Open WPML > Support. The warnings panel at the top flags PHP memory below WPML’s recommended 256 MB. Sites with bigger catalogs need 512 MB or more.

    Other server-resource symptoms:

    • Slow database queries. Large sites with many translations benefit from an SSD-backed database server, sufficient innodb_buffer_pool_size, and indexes on the wp_icl_translations table (these are added by WPML; rare to need manual intervention).
    • PHP execution time. If max_execution_time is below 60 seconds and the Dashboard times out, raise it.
    • CPU. Shared hosting plans often have aggressive CPU limits; check with your host whether you’re being throttled.

  3. Object Cache

    WordPress without an object cache loads many of WPML’s settings from the database on every request. Add Redis or Memcached as an object cache (most managed WordPress hosts offer this; if not, the Redis Object Cache or WP Redis plugins enable it).

    The improvement is usually large. Settings that previously required database hits are served from memory.

  4. Full-Page Cache

    A full-page cache (WP Rocket, W3 Total Cache, hosting-provider edge cache) is the single biggest performance win for frontend speed.

    If you already have one but pages still feel slow, check whether your cache is correctly handling per-language URLs. WPML’s URL structure (whether language-as-directory, language-as-subdomain, or language-as-domain) needs the cache to vary by URL. Most caches do this automatically, but it’s worth verifying that the French version isn’t being served from the English cache or vice versa.

  5. Conflicting or Slow Plugins

    Sites accumulate plugins; some are well-built and some aren’t. To find a slow plugin:

    1. Install Query Monitor (a debugging plugin).
    2. Reload a slow page.
    3. Look at Queries by Component. The plugin with the most expensive queries is the suspect.

    If a plugin is the cause, replace it or disable the feature in it that’s causing the slowness.

  6. Translation Services Slow, Not the Site

    If translation jobs feel slow but the site itself is fine, the bottleneck is between your site and WPML’s translation infrastructure.

    Check WPML > Support > Communication log. The log shows the latency of every API call. If individual calls are taking many seconds, the issue is connectivity (network path, DNS, or your hosting provider’s outbound throttling), not the site. If WPML’s own cache is the culprit instead, the Safe-tier troubleshooting tools include Clear the cache in WPML. When performance investigation needs Support’s eyes, package what you’ve found via Sharing debug information with support.