Website performance is one of the most critical factors for the success of any eCommerce business. In WooCommerce stores that serve an international audience, it’s common to rely on popular translation plugins like WPML (WordPress Multilingual). However, store owners and developers often discover a frustrating issue: WPML’s String Translation component can significantly slow down their sites, causing front-end load times of up to 12–15 seconds. This performance drag isn’t just cosmetic—it directly impacts user experience, SEO, and conversion rates.
TLDR
If your WooCommerce site is suffering from painfully slow page loads and you’re using WPML, the culprit might be the String Translation module. Some of its database queries can create serious bottlenecks. This article breaks down why that happens and outlines the precise performance tuning strategies that helped reduce page load time from 12–15 seconds to under 2. By optimizing database indexes and using selective translation loading strategies, drastic improvements can be achieved without ditching WPML entirely.
Understanding the Problem: WPML String Translation and Performance
The String Translation component of WPML allows users to translate interface texts, plugin strings, and theme-related strings directly from the WordPress backend, without editing language files. While incredibly convenient, this module adds noticeable overhead, especially for WooCommerce stores with several products, themes, and plugins running concurrently.
Here’s what tends to happen:
- WPML stores translated strings in the database under the wp_icl_strings and wp_icl_string_translations tables.
- Each page load, especially on the front end, triggers multiple JOIN queries to those tables.
- As the number of strings and languages grows, these queries become more complex and less efficient.
- The database becomes a performance bottleneck due to missing or insufficient indexing and unoptimized cache usage.
For WooCommerce sites, page load times of 12–15 seconds aren’t uncommon under these conditions, even when other optimization best practices are in place like caching and minified assets.
How We Discovered the Culprit
On a multilingual WooCommerce store with roughly 10,000 products and support for four languages, every product page was taking well over 12 seconds to load. Server-side caching didn’t help, and neither did a CDN. Something deeper was at play.
With the help of tools like Query Monitor and New Relic APM, we discovered that several slow SQL queries were coming from the WPML String Translation plugin. Specific queries affecting the wp_icl_strings and wp_icl_string_translations tables were running 2–4 seconds each and triggered several times per page load!
The structure of the problematic queries often looked like this:
SELECT st.value, st.status FROM wp_icl_strings s JOIN wp_icl_string_translations st ON s.id = st.string_id WHERE s.name = 'some_plugin_field' AND s.context = 'some_plugin_context' AND st.language = 'de'
This type of query, executed multiple times per page view, created a compounding effect that tanked performance. We now had a target for optimization.
The Performance Tuning Techniques That Worked
Several strategies were applied to mitigate this drag without sacrificing WPML functionality. These include both database optimizations and WPML settings adjustments:
1. Adding Custom Database Indexes
The first and most significant improvement came from adding a few indexes to the WPML table columns that were being queried frequently. Specifically:
- Index on
wp_icl_strings(context) - Index on
wp_icl_string_translations(language) - Combined index on
wp_icl_string_translations(string_id, language)
These indexes drastically improved SELECT query speed, reducing some queries from 2+ seconds to under 100 milliseconds. You can add these using phpMyAdmin or a direct SQL command like:
ALTER TABLE wp_icl_strings ADD INDEX idx_context (context); ALTER TABLE wp_icl_string_translations ADD INDEX idx_language (language); ALTER TABLE wp_icl_string_translations ADD INDEX idx_string_id_lang (string_id, language);
2. Disabling Auto String Translation (When Not Needed)
WPML allows for “Auto Register Strings” which captures any string that runs through a WP translation function. While this might seem helpful for completeness, it leads to a bloated database. We disabled this feature under:
WPML → String Translation → Auto Register Strings → Disabled
Only specific strings that were missing translations were then added manually, reducing unnecessary entries drastically.
3. Reducing Translation Scope
We noticed that WPML would load thousands of irrelevant translations on every page load, even those not used on that particular page. To overcome this, we enabled the option:
WPML → String Translation → Translate texts in admin screens → Remove unnecessary text domains
By pruning unused theme and plugin domains, WPML’s workload on each page was hugely reduced. The result was faster and leaner page loads.
4. Caching String Translations
Although WPML does offer some internal caching mechanisms, we extended this by using the free object cache plugins like Redis Object Cache. We also implemented persistent object cache through Redis, which helped cache translation strings between page loads.
With page caching handled through a plugin like WP Rocket and object caching via Redis, we saw resource usage drop and translation loads become dramatically faster.
5. Upgrading the Server Stack
Although not a direct WPML fix, ensuring your hosting environment supports faster PHP versions (PHP 8.1+) and has resources customized for database-heavy operations (like higher MySQL query limits and memory per query) makes a huge difference.
Moving to a cloud VPS with custom-tuned MariaDB settings allowed the site to better manage complex JOINs and high concurrency.
The Impact of These Optimizations
We measured performance before and after each optimization. Here’s what the impact looked like:
- Before: Average page load 13.8s, TTFB 4.5s
- After indexing: Page load down to 6.2s
- After reducing scope: Page load 3.2s
- With Redis + server tuning: Final page load 1.8s, TTFB 0.7s
The improved speed significantly enhanced customer experience and dropped the bounce rate by 27%. Significantly, no WPML features were lost in the process—multilingual product filtering, translations, and SEO functions remained untouched.
Conclusion: Balancing Functionality and Performance
WPML is a powerful tool, especially when running a WooCommerce store targeting global markets. However, like many plugins that rely heavily on database queries, it needs careful performance management. The core problem with String Translation isn’t the functionality—it’s the lack of optimization for scale.
By applying targeted database indexes, managing which strings are translated, disabling auto-registration, and leveraging Redis and PHP 8, the most critical performance bottlenecks were resolved. These strategies offer a path forward for store owners experiencing slow page loads without abandoning WPML or resorting to reinventing their site’s multilingual structure.
Pro tip: Always test optimizations on a staging site and monitor with tools like Query Monitor and New Relic before pushing changes to production.
For any WooCommerce store owner using WPML, addressing these query performance issues could be the key to turning a sluggish site into a high-performing global storefront.
