Skip Navigation

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.

This topic contains 5 replies, has 4 voices.

Last updated by Denise 5 years, 5 months ago.

Assigned support staff: Denise.

Author Posts
May 29, 2016 at 2:05 pm #892280



How much longer before WMPL FINALLY! works on the poor performance? In the meantime, Polylang is by far faster and simpler to use than WPML and this at a fraction of the costs!

And no, there is no analytics to be made from your end on our WP + WooCommerce webstore.

Thanks for your clear statement,

May 29, 2016 at 3:44 pm #892306


Mihai, the developer for WooCommerce Multilingual, collected sites for performance analysis. We went over a number of sites and noticed several things that we should fix.

1. There were general calls (not related to WooCommerce Multilingual) to check for plugin versions, which we are removing already (to be done in WPML 3.4).

2. We are removing the translation controls from the standard WooCommerce products listing page, as it's not necessary. Anyway, we recommend to translate via WPML->WooCommerce Multilingual, so displaying these translation controls in the Products admin screen just adds execution.

3. We are going to add preloading for selected admin strings, as these strings appear thousands of times in WooCommerce admin pages.


Overall, we found that most of the performance issues are in the products listing pages and we're handing them. Some of this will be in WPML 3.4 (in less than two weeks from now) and everything else in WPML 3.5.

I'm not sure if you sent your site for debugging to Mihai. Can you tell me, so I can follow up?

May 31, 2016 at 3:55 pm #893980


Languages: English (English ) Hebrew (עברית )

Timezone: Asia/Jerusalem (GMT+02:00)

Hello, again Patrick.

Is Amir's reply above answers your question?
Do you need more help with debugging your site?
Will be glad to assist you with this.

Please let me now if you need more help with this issue.

June 3, 2016 at 4:37 am #896118


Hi Amir and Itamar,

There’s no need for "debugging" and fumbling around on our E-Commerce solution any more. Just do your homework, invest in top developers, build your own Multilingual and Multicurrency WooCommerce solution as a test center to replicate speed issues! Just get it done, otherwise you will be losing out on some serious competitors out there like i.e. Polylang which, in the meantime, has become by far faster and easier to handle than your WPML dinosaur. And no, Polylang never asked us for access and for "debugging" on our E-Commerce solution because they have their business under control and their product just works right out of the box. Period!

The terrible WPML speed problem will only be resolved, once WPML has radically changed its code structure. And this takes the right sort of top developers (Yes! Developers and not supporters and debuggers!). According to other third party developers, your code is one big mess. No wonder that all sites dramatically slow down as soon as WPML is installed and activated. Everything else is just semantics.

Again, use this page as SPEED BENCHMARK: hidden link
(Note: As long as your own loading time is longer than the above site (left alone the absolute horrible loading time once you, as a WPML customer, are logged in your own customer area, you haven’t even come close to maximum speed possible at all. Keep coding until you’ll reach this level).

IMPORTANT: Pass this information on to your LEAD DEVELOPERS (not Supporters!) & TOP MANAGEMENT.

BONUS INFO: The smarter and better any software/plugin component is developed the less support is needed! - That would be all.


June 5, 2016 at 10:24 am #897537


I received also your previous message to our company site with very similar content and I understand that you need help ASAP.

Let me detail the status and you can decide what's best for you.

In the last 3 weeks we ran a series of measurements on a number of sites that clients provided us for debug purposes.

We saw several issues that we were already familiar with and we learned about several other issues that were new to us. We are currently handling all reported issues.

What we found:

1. There are cases where WPML adds significant execution time to most admin screens. This is very noticeable on servers that have a slow file system or a huge amount of folders in their path. It's happening because of dynamic file resolution for files. This is something that we didn't notice before because our test systems have fast discs and minimal folders on the path (normal for many Web hosts). This problem is most significant on development PCs which run Windows and also on shared hosts that need to load a large number of libraries, to satisfy many dependencies. Fortunately, the solution for this problem is very simple and we can give you a development version that resolves this right now. This can knock off about 30% from the slower admin pages, depending on the speed of your host's file system.

2. WPML adds information to the WooCommerce product listing, which is not necessary. When you use WooCommerce Multilingual, we ask you to translate from WPML->WooCommerce Multilingual and not from the Products admin screen. We are removing the translation controls from the standard products list. This is most significant for sites that have many products, especially if they are also variable products. This change is also available in development version and can reduce another 25%-30% from the page load time (very data dependent).

3. We are doing a major optimization for WPML's String Translation, which will allow to pre-load only the strings needed for each page (front-end and admin). This will prevent WPML from loading too many strings, or hitting the DB too many times when strings are needed.

4. WordPress itself adds very significant processing time to load the many .mo files for WordPress core and for plugins, when site admin is not in English. For WooCommerce it's especially noticeable because the .mo file is huge (similar to the core .mo file). We are going to disable loading of .mo files when WPML offers translation for the same strings. This improvement, together with the previous one can further reduce the page load time significantly. This is still under development so we don't yet have numbers to show. It's also not available to download.

As I wrote before, each of these performance issues is related to data or configuration. We are testing right now on a set of different configurations (data and PHP setup). If you are interested, we can test on your setup to make sure that it doesn't include another factor that we're not aware of. Of course, we will be happy to provide you with development versions so that you can try yourself.

We cannot compare the performance of WPML to Polylang on sites that run WooCommerce because Polylang doesn't have any of the code needed to run multilingual WooCommerce sites. You may be surprised but this code is very far from trivial.

Please let me know if you want to receive development versions. What we have right now can reduce a lot of the processing time from your WordPress admin. Of course, we cannot tell how much because we don't know your site and your server setup.

I hope this helps. I also hope that you understand that we are doing our best to resolve this problem, as fast as we possibly can.

June 9, 2016 at 2:54 pm #904156


Hi Patrick,

I just wanted to alert you that WPML 3.4 and WCML 3.8 were just released. Please update your plugins to experience some performance improvements.

Thanks for taking the time to give us such detailed feedback.