We are investigating performance on our WordPress site and noticed that WPML appears to generate a large number of database queries during page load.
Even with Redis object cache enabled (phpredis) and a high cache hit ratio (~95%), WPML still performs many direct DB requests. In our profiling, functions such as:
take noticeable time and seem to trigger additional database lookups.
Could you clarify:
1. Why WPML performs so many database queries even when object cache is enabled?
2. Are some WPML queries intentionally bypassing the WordPress object cache?
3. Are there recommended settings or filters to reduce these queries and improve performance?
We are investigating performance issues on our WordPress site and noticed that WPML appears to generate a significant number of database queries during page load, even with Redis object cache enabled.
On the homepage we see about 70 total queries, and approximately 50 of them are cache misses, even though Redis object cache is enabled.
This suggests that many WPML queries may be bypassing the WordPress object cache.
We also noticed that fix_fallback_links() runs on the_content and appears to process many links on the page, potentially triggering additional lookups.
Could you please clarify:
1. Is it expected that WPML performs this number of queries even when object caching is enabled?
2. Are some WPML queries intentionally bypassing the WordPress object cache?
3. Are there recommended settings or filters to reduce these queries, particularly those triggered by fix_fallback_links()?
4. Are there best practices for optimizing WPML performance on sites with many links inside content blocks?
Performance issues like the ones you described are usually related to a large number of database queries being triggered by WPML together with other plugins, themes, or custom code.
To better understand what is causing the slowdown on your site, could you please try the following:
1) Temporarily switch to a default WordPress theme (such as Twenty Twenty-Four).
Disable all plugins except the required WPML components.
Test the performance again and see if the issue still occurs.
2) Make sure to update WPML plugins to latest versions (4.9.1)
This test will help determine whether the issue is related specifically to WPML or if it is being triggered by another plugin, theme, or custom code on the site.
3) fix_fallback_links - yes this can cause issues and we have a ticket to fix in future releases, this means you have set display as translated some CPTs (pages, posts, products etc), you can change them to "Translate only" from WPML > Settings.
Let me know the results and we can continue troubleshooting from there.
SELECT CONCAT(st.language, '#', s.context) AS lang_domain, UNIX_TIMESTAMP(MAX(st.translation_date))
AS last_update
FROM wp_icl_string_translations AS st
INNER JOIN wp_icl_strings AS s ON st.string_id = s.id
WHERE st.value IS NOT NULL AND st.status = 10
GROUP BY s.context, st.language;
This is one of the slow queries, and it's been called on each request. Not chached in redis
Yes, some queries may intentionally bypass the object cache depending on how they are executed, so it is possible that not all WPML queries will be served from Redis.
However, to better determine whether this is the actual cause of the performance issue on your site, could you please check if the suggestion from my previous reply helps?
In particular, it would be useful to confirm whether the issue still occurs under the minimal conditions and with latest versions. This helps narrow down whether the behavior is coming from WPML itself or from an interaction with other plugins, the theme, or custom code present on the site.
We run testing. All those massive queries(145) to wp_icl_string_translations appears on any theme with any combination of plugins. It disappears only when we disabled WPML String Translation
Thank you for the testing and for sharing the results.
Could you please confirm if you have updated WPML and its add-ons to the latest versions (WPML 4.9.2 and related plugins) and if the issue still happens after the update?
If the problem persists,please provide access to a staging site together with the steps to reproduce the issue, so we can check it out further.
Alternatively, you can also share a Duplicator package of the site and we can review it locally.
