Please make sure to update to WPML 4.3.5 and check our list of Known Issues before reporting

Hi, Amit here, I am the WPML Support Manager, our current ticket queue is high, update your WPML plugins and make sure you meet the minimal requirements for running WPML before reporting an issue please - many tickets are resolved doing that

Please look at our updated list of Known Issues and you can also use our support search to find helpful information and of course review our documentation before opening a ticket.

If you do need to open a ticket please make sure to provide us with all the needed information as described in this page

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 thread is resolved. Here is a description of the problem and solution.

Some sites run into performance issues because of other plugins. It can be due to compatibility issues with WPML or other problems in the code of those plugins.

If you are running into performance problems, first follow our FAQ entry about preventing performance issues with WPML. This FAQ includes a number of simple steps to follow.

In case you want to profile your site's performance and get to the bottom of performance problems, follow the guide for debugging performance problems.

Tagged: 

This topic contains 120 replies, has 4 voices.

Last updated by George Botsev 2 years ago.

Assigned support staff: George Botsev.

Author Posts
April 27, 2017 at 3:42 pm #1263556

Joanna

Hello Adri,

I reviewed the results and it turned out that you have much better results without WPML that I had on the copy of your site. I consulted it with our 2nd tier and they will test it further but before it, I'd like to ask you to check two more things:

1. Please install a cache plugin, e.g. W3 Total cache, and check if that changes anything.

2. We have some performance issues between WPML String Translation and Gravity Forms. Please test if deactivating Gravity Forms changes the site's performance. I tested it on the copy of your site and it didn't change much but since the performance is different on your installation, it's worth testing this.

April 28, 2017 at 11:08 am #1264208

adriO

Hi Joanna,

I installed W3 Total Cache and run the tests again for the different admin pages. I can tell you, no big difference. Sometimes the load time was about 1s faster and at another attempt up to 3s slower!!!.

Next i tried to test the pages on the frontend! Bang!!!!! My site totally messed up to that extend that I had to revert it back to a pre-W3 Total Cache state. I was lucky that I had a backup of last night so other then some restoring time no harm done.

However you will onderstand that I did not installed the plugin again.

I tried to deactivate all Gravity Forms plugins (plugin, add-ons and Multilingual) and went testing again. No noticeable speed improvement.

Sorry that I don't have any files prepared but I really don't want te Cache plugin re-installed.

I hope you can work with those findings.

April 28, 2017 at 4:27 pm #1264495

Joanna

Hello Adri,

Thank you for testing. I'm sorry to hear that it made such issues. For now, I can only ask you for a little more patience. Our Developers are testing your website carefully to find the main reason for your issues and the solution. I'll get back to you as soon as I have any feedback from them.

April 29, 2017 at 8:12 am #1264734

adriO

Hi Joanna,
I will be patient (for a while). I do hope 2nd tier will come up with a solution shortly.
Have a nice weekend.

Cheers!

May 5, 2017 at 9:39 am #1269014

George Botsev
Supporter

Languages: English (English )

Timezone: Europe/Sofia (GMT+02:00)

Hello, I am George from second tier support.
I am taking a look at the performance issue that you have reported.
From what I can see, in my testing environment, your site loads some parts for about 10secs. At first the frontend was and there were some quieries, but after the initial caching of the strings on subsequent visits, the frontend pages seem to load a bit faster.
So at a first glance, the database queries are not the one to blame here.
I am continuing to investigate your case and I will get back to you as soon as I have been able to determine a cause for this.

May 5, 2017 at 12:13 pm #1269200

adriO

Hi George, thank you for your reply and your efforts to solve this issue.
I do hope that there is a solution shortly because "watching the grass grow" while developing is not my hobby.......

Best wishes,

Adri

May 5, 2017 at 12:25 pm #1269216

George Botsev
Supporter

Languages: English (English )

Timezone: Europe/Sofia (GMT+02:00)

I understand completely. We are all developers and not gardeners 🙂
Please also understand that debugging performance issues requires some time.
Currently, as far as I see, the duplicator clone that you have provided to my colleague generates a whole lot of requests when I passed it trough a profiler.
I still need to find the function that causes all that - this is currently the tricky part because it appears that a filter is being run 1000 times and generates the load as far as I see.

May 5, 2017 at 3:34 pm #1269458

adriO

Hi George..... a filter runs a 1000 times that's impressive.
As I'm not a trained and experienced developer it could make sense to look at my functions.php at first. Of course it is possible that I add some "stupid" code that's causing it.

Thank you for helping me out here.

Best wishes.

Adri

May 9, 2017 at 10:41 am #1271590

adriO

Hi George (and maybe Joanna),

I have some additional information I want to share.

In an attempt to solve it myself and get clear what is happening I cleaned out my site and database of all WPML related data. I deleted the data from the database (using the WPML support option)and I removed the plugins. Next I removed the translated products, media files, categories, tags and menus. As far as I could see there was nothing left related to WPML.

Next I made an export of my database and compared the sizes with the database of my last backup. The cleaned one is 5.4Mb while the one from my last backup is 18.6Mb. Quite a difference don't you agree? I'm wondering why it is so a big difference with only a few pages and products. Where will that go when my products are growing to a 100.000 photos. And believe me that is a low quantity.....

From this "clean" situation I installed the WPML plugins again and guess what...... It is as slow as it was before. This means the database and its size is in this matter no problem.
Next I thought.... could it be my functions.php? I removed it but no avail.

I had planned to keep you posted on my progress (+ or -). I went to wpml.org and what is striking me that your site (and I'm sure you are using WPML as well :-)) is very slow also. Th indicator in the Chrome tab at the top of the page is spinning backwards a considerable time before it is loading the page..........

So, and please correct me if I'm wrong, I'm starting to believe the problems are in the core of WPML. Without WPML it is fast (not extreme because I'm on my local machine) with WPML I'm a gardener again :-).

I even tried the plugin qTranslate X on my "clean" site and it is as fast as a rocket. I will try however to stay with WPML because it suites me much better for now. However when it takes this much time to load pages.... We all know that visitors don't stay long on a slow site, not to speak about purchases........

Minor fornt end example: it takes over 30 seconds for WPML to determine in what language the browser is. It is starting in English, wait, wait, wait, wait, wait and then finally it switch to Dutch, because that is my browser language. With qTranslate X you even don't see an English page coming up. It is so fast that the Dutch page is coming up right away.

Best wishes,

Adri

May 9, 2017 at 11:16 am #1271624

adriO

BTW I can supply a website package (files and database) with the cleaned out database.

May 9, 2017 at 2:37 pm #1271873

George Botsev
Supporter

Languages: English (English )

Timezone: Europe/Sofia (GMT+02:00)

Thank you for the detailed analysis.
I think that the problem might be coming from some plugins that you use and also WPML String Translation as well.
There is no need for you to provide anything else at this time.
I am going to consult with our developers about this now and escalate the issue to them.
Perhaps you might want to test it with the previous version of WPML String Translation - available from this site - in Account > Downloads > WPML String Translation > Changelog (link) and then scroll to WPML String Translation 2.5.2 if this happens to speed things a bit for you.
The other plugin that made some impression for me is Revolution Slider, but this does not mean that it is problematic - the problem could be in WPML String Translation as well.

I will let you know of any progress that happens to this case.

May 16, 2017 at 6:46 am #1276789

adriO

Hi George,

It is more than a month ago I started this topic. I think it is about time that a solution is provided. I don't understand why it has to take so long. Another recent issue was also taking over a month to solve it. In my opinion that is no good support. It more looks like everything is treated as "minor bug reports" and I have to wait with in what new release WPML is good enough to solve it. I think I have been patient enough. So come on WPML, wake up and give me a good solution.

Best wishes,

Adri

May 16, 2017 at 8:20 am #1276866

George Botsev
Supporter

Languages: English (English )

Timezone: Europe/Sofia (GMT+02:00)

Debugging and fixing performance issues take a lot of time.
I am sorry that this is taking so much time - now the case is in our developers and they are actively working on providing a fix in the next release (if everything goes according to the current plan).
For now, you can try and set the option in WPML > Theme and plugin localization to "Translate the theme and plugins using WPML's String Translation only (don't load .mo files)" which should help to some extent, at least it the second language.

May 16, 2017 at 10:55 am #1277035

adriO

Hi George, thank you for your quick reply.
I think you will understand that, although all your good intentions, this don't tell me anything.
When is the next release launched? And your remark "if everything goes according to the current plan" gives (IMHO an escape) to leave it as it is for a long time. Maybe it sounds more annoyed as I mean. I certainly do appreciate your efforts to solve this issue and your hands are also "tied up".
Short, and you will understand as you re-read your reply, there is nothing concrete in it. I have to wait and see what's happens in the future. Is the future this week or after Christmas?

About your suggestion to not work with .mo files did not bring any gain in speed what so ever. Thank you for the suggestion though.

BTW did you check the performance of wpml.org frontend? When I compare it with other sites it is slow as well. I made this remark earlier but never heard anything about it. Is it related?

Regards,

Adri

May 16, 2017 at 11:38 am #1277095

George Botsev
Supporter

Languages: English (English )

Timezone: Europe/Sofia (GMT+02:00)

Yes, I need to mention that, because I don't want to be a liar.
There are some times when releases are being postponed for various kind of reasons. I cannot take a chance to promise you a release on date X because the current performance issue is something that requires a lot of coding and testing. Furthermore, I am a supporter and not developer so I don't have the view over the whole picture as our developers have.
I report only facts that I see. The issue is being worked on with priority and should be better in next release.
I will ask our developers if there is some workaround, but as far as I see it now - the problem comes from the number of .mo files that are in use in your setup and WPML String Translation.
Our QA team always runs performance tests with several big sites, and also before every release we first run tests on our site - wpml.org.
They have not determined any performance problem with that site, but as I told you - the problem here is unique to the fact of how many .mo files are being loaded.

I will let you know as soon as I have more information.