Background of the issue:
We are experiencing significant slow performance when the WPML plugin is activated. This issue has persisted despite following all the recommendations provided in a previous support ticket (link: https://wpml.org/forums/topic/string-translation-slow-website/). We engaged three professional developers to conduct a comprehensive code review of our templates and identify potential conflicts. Unfortunately, they did not find any issues within the theme that could be causing this problem. To further investigate, we consulted with a hosting company specializing in WordPress. They created a staging site and performed a thorough inspection and profiling of our website. Their performance team unanimously agreed that the issues stem from the WPML plugin. Below are the profiling results they provided: [0x00007f2dc1a14eb0] similar_text() /home/porcelan/www/wp-content/plugins/wpml-string-translation/classes/slug-translation/new-match-finder/wpml-st-slug-new-match-finder.php:103 [0x00007f2dc1a14de0] find_the_best_match() /home/porcelan/www/wp-content/plugins/wpml-string-translation/classes/slug-translation/new-match-finder/wpml-st-slug-new-match-finder.php:14 [0x00007f2dc1a14d50] get() /home/porcelan/www/wp-content/plugins/wpml-string-translation/classes/slug-translation/class-wpml-rewrite-rule-filter.php:37 [0x00007f2dc1a14c80] rewrite_rules_filter() /home/porcelan/www/wp-content/plugins/wpml-string-translation/classes/slug-translation/RewriteRules/Hooks.php:52 [0x00007f2dc1a14c10] filter() /home/porcelan/www/wp-content/plugins/sitepress-multilingual-cms/inc/absolute-links/absolute-links.class.php:485 [0x00007f2dc1a14ac0] all_rewrite_rules() /home/porcelan/www/wp-content/plugins/sitepress-multilingual-cms/inc/absolute-links/absolute-links.class.php:445 [0x00007f2dc1a149d0] initialize_rewrite() /home/porcelan/www/wp-content/plugins/sitepress-multilingual-cms/inc/absolute-links/absolute-links.class.php:100 [0x00007f2dc1a144c0] _process_generic_text() /home/porcelan/www/wp-content/plugins/sitepress-multilingual-cms/inc/absolute-links/absolute-links.class.php:656 [0x00007f2dc1a14440] convert_text() /home/porcelan/www/wp-content/plugins/sitepress-multilingual-cms/classes/utilities/class-wpml-translate-link-targets.php:31 [0x00007f2dc1a143c0] convert_text() /home/porcelan/www/wp-includes/class-wp-hook.php:324 [0x00007f2dc1a142e0] apply_filters() /home/porcelan/www/wp-includes/plugin.php:205 [0x00007f2dc1a14200] apply_filters() /home/porcelan/www/wp-content/plugins/acfml/classes/Field/FrontendHooks.php:27 [0x00007f2dc1a14130] convertTargetLinks() /home/porcelan/www/wp-content/plugins/sitepress-multilingual-cms/vendor/wpml/fp/core/functions.php:17 [0x00007f2dc1a140b0] WPMLFP{closure}() /home/porcelan/www/wp-content/plugins/sitepress-multilingual-cms/vendor/wpml/fp/core/Either.php:207 [0x00007f2dc1a13f80] map() /home/porcelan/www/wp-content/plugins/sitepress-multilingual-cms/vendor/wpml/fp/core/Either.php:257 [0x00007f2dc1a13f10] chain() /home/porcelan/www/wp-content/plugins/sitepress-multilingual-cms/vendor/wpml/fp/core/Promise.php:24 [0x00007f2dc1a13e90] resolve() /home/porcelan/www/wp-content/plugins/sitepress-multilingual-cms/vendor/wpml/wp/classes/Hooks.php:50 [0x00007f2dc1a13df0] WPMLLIBWP{closure}() /home/porcelan/www/wp-includes/class-wp-hook.php:324 [0x00007f2dc1a13d10] apply_filters() /home/porcelan/www/wp-includes/plugin.php:205 [0x00007f2dc1a13c10] apply_filters() /home/porcelan/www/wp-content/plugins/advanced-custom-fields-pro/includes/acf-value-functions.php:118
Symptoms:
The primary problem is an additional 5-10 seconds of loading time when the plugin is enabled.
Questions:
What can be done to resolve the significant slow performance when the WPML plugin is activated?
Are there any additional steps or configurations we should consider to improve the loading time?
2 - Can I reproduce the performance issue simply by reloading any page or the dashboard in the backend or do I need to do this with specific pages/posts ?
3 - You mentioned that you see a loading time increase of 10 seconds with WPML activated
a. What are your results when you leave WPML activated but instead switch your theme to a standard theme such as twenty24
b. What are your results when WPML and any 3rd party plugin that is essential to have the site working are activated? (Sometimes certain 3rd party plugins + WPML can have some incompatibility causing this )
1. I have re-run the process as per the guide, but unfortunately, it did not resolve the issue.
2. The problem is isolated to the frontend and occurs regardless of the page.
3. The loading time increases significantly when the String Translation plugin is activated.
a. Switching to another theme, such as Storefront, resolves the problem.
b. None of the third-party plugins are causing issues or crashing WPML. I have tested
multiple scenarios without identifying any issues.
While it seems logical to suspect our custom theme as the source of the problem, but after extensive debugging and research by both our team and external developers for the last couple of weeks have not revealed any bugs or issues within the theme. All of them agreed and asked me to create a ticket on WPML.
We have successfully implemented many projects over the past years, with the same tools, same devs, same theme! It's the first time facing this issue.
Thank you for walking through these steps and confirming them with me.
Given that the issue is resolved when switching from the custom theme to a standard WP theme, it strongly suggests that the theme's code is the root cause. Otherwise, such a significant difference wouldn't be observed.
Based on the information, it is logical to believe this issue is due to a conflict between the theme and WPML's code.
Since you hired a team to test this further, what was their opinion? Did they find any specific issues with the theme?
The shared information was solely on WPML's code which when the theme is not present does not have this issue.
I'd be happy to escalate this to our development team for review, but please note that we cannot support custom themes as per our policy.
Every developer who has taken on this task agrees that the issue originates from the WPML String Translation plugin. FYI, all tests and profiling indicate the plugin as the problem. Please see the attached images and logs from another server, which also confirm that this is not a theme issue but rather a plugin fault.
As the authors of the theme, we have had multiple developers thoroughly inspect the issue and the theme itself. None of us, including myself, have found anything wrong, nor any unusual queries or other issues.
To be honest and clear, using an empty storefront theme doesn’t really convince me that the plugin is functioning correctly. This is why we continue to contact support, as we are not getting anywhere by looking at the same aspects repeatedly.
We kindly request your support or the involvement of tier 2 support to take a closer look at this issue. We are out of options. All we need is to find what is causing this massive delay in loading.
I am happy to investigate this further but I will note again that our support is limited when it comes to custom themes and custom work overall.
I would like to request temporary access (wp-admin and FTP) to your site to test the issue.
(preferably to a test site where the problem has been replicated if possible)
**Before we proceed It is necessary to take FULL BACKUP of your database and your website. Providing us with access, you agree that a backup has been taken **
I often use the Duplicator plugin for this purpose: http://wordpress.org/plugins/duplicator/
You will find the needed fields for this below the comment area when you log in to leave your next reply.
The information you enter is private which means only you and I have access to it.
NOTE: If access to the live site is not possible and the staging site does not exist please provide me with a duplicator package created with the duplicator plugin.
I believe the issue here might be more related to woocommerce rather than WPML String Translation alone. With WPML String Translation deactivated WooCommerce Multilingual does not work and activating it essentially turns the multilingual part of the WC store 'on'
These are some benchmark reports on loading time with WPML String Tranlsation deactivated:
Front end -- 11.27
Admin dashboard -- 11
Store front end -- 11.8s (Displays product categories)
Here they are with String Translation deactivated:
Front end -- 15.22
Store front end -- 24.95s
WPML + WPML ST + Custom Theme deactivated and switched to Twenty23
Store front end -- 5.5s ----> Most likely because nothing loads, the product categories are being pulled by the custom theme.
same thing with the front end homepage, which does not make this test very reliable.
-------------------------------------------
Unforutnately I cannot proceed with these tests as the server is triggering a 504 Gateway Time-out Error after I deactivated the following plugins from step #2
1. Go to WPML->Settings-> Taxonomies Translation -> Review the taxonomies from Bathtub Components - Type (pa_aksesoyar-mpanieras-typo) and on.
Essentially all the ones that are set to Translatable use translation if available or fallback to default language switch to Translatable switch the setting Translatable only show translated items
This setting is known to increase the resources required and can cause performance issues.
After changing these settings, what are your results?
2. Deactivate the caching plugins for now (Once you turn them back on we recommend using only one caching plugin rather than 2)
WP Super Cache
WP-Optimize - Clean, Compress, Cache
Autoptimize
Redis Object Cache
WP Query Monitor (known to interfere with performance issues)
Thanks for the clear explanation of the steps you've followed.
I tried your suggestion on the translatables but didin't really made a diffrence.
The 504 issue has been resolved on the staging environment. Your expertise in continuing to investigate this matter would be incredibly valuable, as I am unsure of the next steps. I would greatly appreciate your assistance.
