[Resolved] slow load times when wpml string translations is enabled
This thread is resolved. Here is a description of the problem and solution.
Problem: The client reported slow load times when the WPML String Translations plugin is enabled. They noticed that disabling the plugin significantly speeds up the page loads. They also mentioned using the Index WP MySQL For Speed plugin, which only slightly improved the situation. The client was concerned about the storage of translation files and the potential impact of custom actions on performance. Solution: We recommended the following steps to troubleshoot and potentially resolve the issue: 1. Use the Query Monitor plugin to compare performance with and without WPML plugins enabled to help identify slow queries. 2. Ensure all WPML plugins are updated to the latest versions. 3. Test in a minimal setup by switching to a default theme, such as Twenty Twenty-Four, and disabling all plugins except WPML and ACF. Then, gradually re-enable the theme and other plugins to check if a specific component is causing the issue. 4. If the issue persists with only WPML and the default setup, it might be a WPML-specific issue, which we will investigate further. 5. Check with the hosting provider to review server load, cache, or configuration differences, as the local environment was much faster than production. 6. If applicable, provide a staging site or a duplicator package for further investigation. 7. Since the issue related to a read-only languages directory mentioned in the Pantheon errata does not apply (as translations are being generated and stored), there is no need to apply the workaround in wp-config.php. 8. Removing the
after_setup_theme
action could help improve performance if it was doing additional processing on every request.
If these steps do not resolve the issue or if the solution seems outdated or irrelevant to your case, we highly recommend checking related known issues at https://wpml.org/known-issues/, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins. If needed, please open a new support ticket at WPML support forum for further assistance.
This is the technical support forum for WPML - the multilingual WordPress plugin.
Everyone can read, but only WPML clients can post here. WPML team is replying on the forum 6 days per week, 22 hours per day.
Slow load times when WPML String Translation is enabled can sometimes be related to theme or plugin conflicts, or heavy database queries.
To better understand the cause, I recommend the following checks:
- Use the Query Monitor plugin to compare performance with and without WPML plugins enabled enabled (this can help identify slow queries)
- Make sure all WPML plugins are fully updated to the latest versions (4.9.2 is latest)
Test in a minimal setup:
- Switch to a default theme (e.g. Twenty Twenty-Four)
- Disable all plugins except WPML and ACF
- Then gradually re-enable your custom theme/plugins to identify if something specific is causing the slowdown
Since you are using a custom setup, this will help isolate whether the issue is coming from WPML itself or from an interaction with other components.
Let me know your findings and I’ll be happy to assist further.
Are there recommended settings to test or even disable related to string translations? I wouldn't want to scan theme templates for any new items to translate or anything of that nature. I think tweaking these settings first might be more helpful than the recommend steps given that the slowness starts right when the plugin is enabled and ends when the plugin is disabled.
Sure, we can try that steps, I just assumed since it is a custom setup it would be easier to check on that, as it most likely could be the reason of the issue.
Anyway, please follow next:
[ ] - So the first step is to make sure that your site is adequately resourced. The minimum requirements for WPML (https://wpml.org/home/minimum-requirements/) are very much a minimum, and larger sites should have more memory and server resources to function well.
[ ] - Use PHP 8 (performance improved a lot compared to PHP 7), but not the most recent versions (at the time of writing, PHP 8.2 versions) because it takes time for themes and plugins, and WordPress itself, to catch up and ensure compatibility.
[ ] - Caching is invaluable. You can use page caching plugins such as Super Cache, W3 Total Cache, or WP-Rocket, and preferably also object caching, for example via Redis and a plugin like https://wordpress.org/plugins/redis-cache/.
[ ] - Do not use any kind of SSL-helping plugins. They produce significant overhead by redirecting every request. To use https properly, just convert all links in the database using a safe search-replace plugin such as Better Search Replace or via WP-CLI.
[ ] - Consider using the plugin Index WP MySQL For Speed (https://wordpress.org/plugins/index-wp-mysql-for-speed/). WordPress table indexes are not optimised, and this plugin updates the table indexes to improve performance.
[ ] - Don't have debugging plugins like Query Monitor active in production, they add overhead. (Likewise make sure Xdebug is not active on your production server.) Review your list of plugins more generally to ensure you are only using plugins that are actually needed. (That includes WPML Media, which is only needed if you need to display different images when showing translated content; it is not needed to translate image texts such as captions.)
[ ] - Naturally, you page weight should be as low as possible, which means optimising assets such as JavaScript and CSS files, as well as compressing images.
More specifically, relating to WPML:
[ ] - Consider disabling "display as translated" (Fallback mode) from post types and taxonomies (in which case content will only be shown on secondary languages where translations exist; the resulting queries are much simpler).
[ ] - Try disabling the setting to "Adjust IDs for multilingual functionality" at WPML > Languages > Make themes work multilingual. Recommended themes should not need this setting.
[ ] - Turn off "Track where strings appear on the site" in String Translation if it is active.
[ ] - From the troubleshooting page (via WPML > Support) at wp-admin/admin.php?page=sitepress-multilingual-cms/menu/troubleshooting.php try the "Cleanup and optimize string tables" and "Clear invalid strings" options. It might also be helpful to "Remove ghost entries from WPML tables".
Hello,
I'm still seeing slowness, see hidden link. We recently added Index WP MySQL For Speed plugin but that seems to maybe slightly help with the issue. The admin page loads are even slower when logged in. Any other recommendations or things to search for maybe with Query Monitor plugin? One thing I did notice is when wpml string translation plugin is disabled, the page loads are super fast.
If the issue is still happening, the best next step is to follow the initial approach and try to isolate the cause. This will help us determine if there is a conflict with custom code or another plugin.
As mentioned earlier, please try the following:
Use the Query Monitor plugin to compare performance with and without WPML plugins enabled, as this can help identify slow queries.
Make sure all WPML plugins are updated to the latest versions.
Test in a minimal setup by switching to a default theme such as Twenty Twenty-Four, and disabling all plugins except WPML and ACF. Then gradually re-enable your theme and plugins to see if a specific component is causing the issue.
Thanks I'm taking it step by step. I also noticed a ton of text-domains that I don't really need. Maybe this extra is causing this issue? How can I get rid of these as I only have two domains setup, see translations. Would I use 'remove strings by domain'?
There's also a ton of packages wp/wp-admin/admin.php?page=wpml-package-management of kind ACF field group. Can I remove these as well?
And on wp/wp-admin/admin.php?page=sitepress-multilingual-cms%2Fmenu%2Ftheme-localization.php, for localization options, do I need to check any of these options?
Also noticed local version much quicker (under 3 sec) than on server (7 sec).
The issue mentioned in that thread was fixed a while ago in the ACFML plugin, so it should not apply to current versions.
Regarding your case:
Removing unused text domains or strings can help slightly, but it usually does not have a major impact on performance. The same applies to ACF packages you can clean unused ones, but they are typically not the root cause of slowdowns.
The key here is to isolate the problem:
- Test with a default theme + only WPML plugins active
- Then enable other plugins one by one to see if the slowdown appears
If the issue happens only with WPML + default setup, we can investigate further as a potential WPML issue. Otherwise, it is likely coming from a theme/plugin conflict.
Since your local environment is much faster than production, I would also recommend checking with your hosting provider they can review server load, cache, or configuration differences.
If needed, feel free to share a staging site or duplicator package and we can take a closer look.
1) At this point I’m not fully certain , so the best next step would be to check this directly. Would it be possible for you to provide a staging site or a Duplicator copy of the website so I can investigate further?
2) Regarding the Pantheon errata you mentioned, that issue was related to cases where WPML could not save translation files (.mo), due to a read-only languages directory. Based on what you described, this does not seem to be the case on your site, since translations are being generated and stored.
Because of that, you do not need to apply that workaround in wp-config.php.
I'm working on removing add_action( 'after_setup_theme', 'we_language_affiliate_dir_setup' ); since it seems like my conf is setup for a specific dir like:
Yes, that makes sense. If the language directory is already defined directly via `WP_LANG_DIR`, then removing the `after_setup_theme` action could definitely help performance if it was doing additional processing on every request.
