[Resolved] My site is much slower after adding WPML
This thread is resolved. Here is a description of the problem and solution.
Problem: The client reported significant slowdowns on their staging site after installing WPML, with page load times increasing to 6-10 seconds. This issue was not present on a similarly configured site without WPML. The client tried various optimizations, including disabling WPML SEO and WPML String Translation modules, which improved load times.
Solution: We recommended migrating the site to our Cloudways testing environment to isolate the problem. The client used the Cloudways WordPress Migrator plugin for this purpose. After migration, we discovered that the combination of Admin Columns Pro, ACF, and ACFML plugins significantly impacted performance. We provided a temporary workaround by modifying the
translateField
method in the ACFML plugin to prevent certain processes from executing in the admin area, which improved backend performance. We also advised on general performance enhancements such as using PHP 8, enabling caching, and optimizing database indexes.
Please note that this solution might not be relevant if it's outdated or not applicable to your specific 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 the issue persists, please open a new support ticket at WPML support forum.
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.
Background of the issue:
I have the live website, without WPML, this feels fast and snappy on both the frontend and backend. I have the staging site, with WPML, and lots of things are taking 5 or 6+ seconds. It feels very slow to use. I've searched numerous threads on WPML before opening this ticket. Tried some fixes which suggested plugins to add indexes to some big tables. Tried some fixes related to ACFML v2+ e.g. https://wpml.org/errata/advanced-custom-fields-multilingual-the-group-fields-title-and-labels-are-translatable-by-default/
Symptoms:
My site is much slower after adding WPML.
Questions:
Why is my site much slower after adding WPML?
Are there any specific optimizations for WPML to improve site speed?
Can I provide you with logins so you can advise?
Fast site:
1 - Import the exact same database file
2 - wp search-replace "old-url" "new-url"
(no --all-tables flag).
On the slow site, if the WPML SEO module was enabled or the WPML String Translation module was enabled it would take 6-10 seconds to load a page. On the fast site the same page took 1-2 seconds.
I don't know what is going on in the background, Query Monitor didn't flag any long/slow queries.
Really, I do want the old url replaced in all of the database tables, I don't want a local development URL in the staging site database, but if I run with that flag WPML grinds to a halt.
With the current site I was lucky it was at a point where I was able to re-import and start fresh. I have a different project's production site which I think has the same issue and has been suffering from it for some time. Maybe it would be helpful to have a copy of that as well as a second example?
I've also tried things like Query Monitor on this second problem site but nothing is flagged as a slow query (similar to my original report on this site), some processing must be happening somewhere but it's so deep in WPML that I can't find it.
I thought this was in a good place before the weekend, but now the site which was "fast" is now behaving the same. 8-10 seconds to loads the backend... Painful.
Just to note - I had to SFTP in and upload some WordPress files before the migrator would accept the destination. Before I did that it was erroring with: "Unable to access wpconfig file. Please check if WordPress is installed on the destination address. Also, check if you have permission to access the folder."
My understanding is that you did set up your site on the testing environment that I created for you and when I tried to access it, it did not work.
So I created a new one this time.
In delicate situations like this one where we talk about performance, we prefer to have our customers migrate the site onto our own testing environment because this way, the developers can easily filter out multiple reasons for which this issue might be happening (performance issues can happen for many reasonse like: due to the way the initial server of the customer was set up, due to specific configurations etc.) and that way, only the valid ones that can help them find the cause of the issue remain.
Sorry I must have been looking at our spare Cloudways instance. I'm not sure what's happened to the original migration site. Do they expire after a certain time?
I've re-run the migration and it's ready to use.
I don't know how or why but the duplicated site is taking a fraction of the time to load, the exact same site (assuming duplicator has done what it's name says!), on the same hosting platform.
The load times are vastly different.
The MB required to load the page are also vastly different.
What Cloudways plan is the duplicated site using?
What do you advise?
I can give you full access to the slow site on my Cloudways plan if that's helpful.
Been testing the migrated website a bit more. If there's more than one tab open it seems to have a massive impact. Two tabs is not really much of a "stress test" but with the live website it's going to have a *lot* more requests than two tabs, and there's multiple editors using the backend on the client side of things too.
The migrated site doesn’t use Cloudways’ malcare plugin, so no that file won’t exist.
It looks like something has changed since I sent all my screenshots as the migrated site was working fine (albeit slowly). I haven’t touched the site so I’m not sure what is going on with the test site deciding to break?
I’m not at a computer right now but can look tomorrow. My guess is the malcare autoappend needs removing from any htaccess or .ini file where it is present.
As suspected, there was a .user.ini file with this in it:
; MalCare WAF
auto_prepend_file = '/mnt/BLOCKSTORAGE/home/214261.cloudwaysapps.com/kekcjmagaj/public_html/malcare-waf.php'
; END MalCare WAF
This isn't part of the site I migrated. The Malcare plugin has also been added in the plugins directory. This isn't part of the site I migrated.
I've had Cloudways add this to my projects in the past before, it would be helpful if it didn't do that in your support environments.
I also noticed some other files like "https://cdn.wpml.org/public_html/cleanedup.txt" which are not from me.
I have deleted the plugin and the user.ini and the site is now back online.
The test website is now working again for me: hidden link
---
On a different note, I know it says your timezone is Europe, but your replies tend to be around 9pm / 10pm. Is there anyone else available who's working hours are closer to GMT working hours?
