How to make WPML run faster! (instead of slow)
Is WPML slowing your site to a crawl? (10-20s load times?)
I hear complaints about WPML slowing down sites almost every other day. And for the most part, there’s truth to that. ANY multi-lingual plugin, not just WPML will slow down your site.
But many people are claiming that WPML is the worst multi-lingual plugin ever and that’s isn’t true. They WERE actually pretty slow when I first tried using it in 2013 but each update got faster and faster and in around 2014 and 2015, their development team really listened to the complaints and the 3.X versions sped up incredibly. Aside from that, I also learned that the plugin CAN indeed run pretty fast. YOU JUST HAVE TO FOLLOW SOME INSTRUCTIONS. My 6-language site with tons of articles and images loads in 1 second.
Before you give up on WPML, give these things a try.
1. Disable auto-register strings for themes/plugins
It’s on the string translation page. DISABLE IT! Otherwise, every extra plugin/theme you add will add a thousand strings. Don’t worry, you can register them manually later!
2. Delete unnecessary strings
If you haven’t already figured out, string translation is the #1 reason for slow WPML sites. If your WPML is slow, there’s a good chance you have thousands of strings. I’ve seen sites with as many as 25,000 strings when they only needed 100!!! Go through them and delete them! You can even filter the strings by plugin/theme, etc.
The only strings you need are the ones showing text on the front-end THAT you intend to translate. Everything else, JUST DELETE! All the admin screen text, delete that (unless you intend to have multi-lingual admins). All the internal php string text names that only show in the code, delete that. Delete delete delete.
Your WPML site may start to run pretty fast once you get down to 500 strings. Don’t BE LAZY. Keep deleting. Scrutinize every string until you get under 100. By then, you may be shocked to find your site runs just as fast as when it was brand new.
Last tip: MAKE SURE YOU followed step #1…or else all the strings you deleted will come right back.
3. Have a clean-coded theme
WPML kinda re-processes your theme. So if your theme is bloated and inefficiently-coded, WPML will work extra hard to convert that to multi-lingual. I didn’t realize how much of a difference it can make but having your theme re-coded from scratch can make a huge difference on WPML impact. I’m not a coder so I can’t explain exactly which things.
But I’m aware that cleaning up your theme will make it run that much faster, can be anywhere from a half-second to 2 second decrease in load time. My theme was already fast but my programmer cleaned it up, I was surprised that it made WPML even faster (or more accurately, decreased its impact even further).
4. Basic speed optimization still applies
PHP 7, object caching, page caching, GZIP, having your site on a VPS instead of shared hosting. All these things make a huge difference together as well as individually.
5. Set up 2 sites
If you want to speed up WPML even further, you can do THIS trick…set up your main language site (non-WPML) on your main domain. And then put your WPML site on a sub-domain. I called mine “world.domain.com”. From there, you clone over your main language and then translate it to the other languages and output them to their own TLD. This way I have a main language site (non-WPML) that runs at full speed and then another site (WPML) for all the other languages.
This tactic is really only worth it if you have more than one translated language. Otherwise, it’s like you’re doing multi-site if you only have 2 languages.
What about WPML’s overhead?
Yes, it’s true…WPML does do a lot of php-intensive and database-intensive operations. But even without a cache plugin, I’ve been able to get a busy 1mb site to load in 1 second. (I’m on a 4-core VPS, btw.) If your theme is coded cleanly enough, you will be fine. In fact, if you’re like me…you’ll be surprised at how fast WPML can run! At this point, it’s only 200-300ms cost AT MOST compared to the exact same site without WPML.
This article is a life saver !!! Thank you so much !
So happy for you, Michal! I’m guessing you removed a bunch of strings!
I had around 25 000 strings !!! Now it is less than 100 🙂 My shop came back to the living. WPML Support was helpless in in this case. Thank you once again ! Best, Michal
LOL! You were the perfect case. I swear, I think over 95% of users complaining about WPML speed out there are unknowingly running their site with 5-20k strings.
Hi Johnny, I am going to switch to Polylang since WPML is really painful with its strings autoregister. Do you have some experience with other wordpress translation plugins? Is Polylang a recommendable plugin ?
I’ve tried Polylang (many years ago as well as recently) and absolutely cannot recommend it over WPML. There was a time a few years back when WPML was having constant issues and many people preferred Polylang because it was simpler and with less hassles. Well, now WPML has finally matured and Polylang has commercialized (charging for every feature). Both are the similar with Polylang being more expensive despite less features and more of a hassle for me. I understand your concern about the autoregistered strings; I suppose you could just delete them all and then register individually if you prefer. Who knows…try it and see if you like it.
Or 54k Strings like in my case! 😀
WPML Support was of no help either. Apparently they are lame and don’t want to face the facts, otherwise they would have told me to go look in the string translation.
I’ll be running separate sites per language instead of WPML as I’m looking for maximum speed.
Thanks you! Cool article.
I think the biggest pain is that there is not option/function to register only front end strings, or to stop auto-register strings completely, wpml is constantly loading new added plugins. Delete whole domain would be cool too.
I agree with you, Tom!!!
If anyone will be interested in your suggestions too. I found out way to to made string deleting easier. By just choosing “Translation needed” + “All domains” = delete all. And wait for hours… .-))
It is based on simply logic, that what is not translated is not needed by front end. If it was needed by front end it will show up.
But what is working for me, may not work for anyone else.
Hahaha, yes…that is one way to do it but can easily miss some items that you want later. I do it manually and can clean out 20k strings relatively quick. If it’s really bad, can do it directly from the database.
45k strings..oh boy i have work to do
Hahaha, best of luck to you my friend!
Yup, we have 23k strings EEEk.
Johnny (or anyone?), can you suggest a safe and methodical way of tackling this (searching the WPML forums, just had me going in circles…).
E.g.
1) Start with WP back-end (we don’t need it translated at all)
2) Then tackle the known “heavy string translators”
3) Then go more granular…
Any help would be appreciated
Did you follow my guides for getting rid of the strings? Believe me, 23k ain’t that bad (if your server is strong enough). Also, WPML is coming out with a new mechanism that won’t rely on strings so if you can just wait a little while longer… 🙂
Hi Johnny – thanks for the quick response. Yes – I’m following the process on our staging environment to see that we don’t break anything, but while doing it I’m wondering:
1) Is it 100% fine to disable all plugins and themes from auto-register settings
2) Is it advisable to keep everything that has a translation (If it has a translation, then it’s likely its being used on the site — and if a handful are no longer being used, then those few instances won’t over-bloat the DB)
3) And fine to remove everything that doesn’t have a translation (i.e. if we never bothered to translate it, then by removing it, we won’t break anything, right?)
If you’re able to give you advice on the above I’d be very grateful.
Also, can you point me to any links that discuss how WPML will be changing the way they do String Translations?
Andre
PS. Happy for you to reach out to me directly, if you’d rather not publish your response publicly. Thanks again!!
1) Yes, 100% fine to disable all plugins/themes from auto-register settings. That’s exactly what I recommend in my guide.
2) The criteria for removal is that you’re not using it, rather than that it doesn’t have a translation yet….here’s why: A) many default WordPress strings aren’t shown on frontend but have translations. This can easily be around 5k unused strings. B) Your theme might not be fully translated in some areas but you didn’t notice yet. C) Your theme appears fully translated to your liking but some strings aren’t used. You should still keep some of the unused ones in case you want to translate them later (maybe if not the text, then perhaps the link that they point to).
3) Fine to remove whatever you don’t use. But if you want to translate them later, it’s a total PITA to have to rescan for all strings again to add the missing ones. That’s why you have to be careful which ones you remove.
I tried my best to explain simply for you but there are many scenarios which I did not account for. I hope you figure it out. I promise, there’s a light at the end of the tunnel. I’ve had WPML one of my sites since 2013 (way back when WPML was a much bigger mess) and I still love WPML.
Links to new WPML 4.3.x with faster string translation (skipping DB calls):
– https://wpml.org/2019/08/wpml-4-3-beta-1-with-much-faster-string-translation/
– https://wpml.org/2019/09/wpml-4-3-0-beta-with-faster-string-translation-and-multisite/
@Johnny – thanks for the detailed response. You have articulated it well. To summarise further, for others’ benefit:
– Remove what’s not being used (NOT ONY what is without a translation)
– Keep what is being used and what may be used in the future (NOT ONLY the things that have translations)
BTW – We’ve made good progress:
Before starting, we exported the list of domains (with StringCount per domain) into a spreadsheet. Then ordered by StringCount, and tackled the list from top to bottom:
– We had 210 domains covering 23k Strings
– The 26 “biggest” domains covered 80% of the strings. They were:
default 2,844
woocommerce 2,152
gravityforms 1,529
gravity_form-2 1,444
js_composer 1,425
citytours 753
all-in-one-wp-security-and-firewall 639
wordpress-seo 628
includes_excludes 614
updraftplus 539
sitepress 499
rocket 490
w3-total-cache 489
ultimatemember 464
wp_all_import_plugin 461
acf 451
continents-cities 435
simple-history 369
wpml-translation-management 337
redux-framework 336
amazon-s3-and-cloudfront 320
custom-post-type-ui 317
advanced-access-manager 313
user-role-editor 307
jetpack 249
wp-super-cache 243
Many of these plugins we weren’t even using (e.g. we added Woocommerce ages ago, realised it wasn’t going to be needed on our site, deleted it from WP ages ago too… Yet the 2,152 Woocommerce Strings were still there in the DB).
We’ve deleted all unneeded Strings from the 26 domains above and we’re now down to 5k Strings from 23k. And we intend to work through the remaining 181 domains slowly-slowly to see if we can get Strings to the 500-1000 range.
80-20 rule FTW.
Thanks again for the help – Andre
Hello there, Johnny,
thank you for great post!
Would you say that the step 2) of deleting unnecessary strings is not needed anymore?
I am indeed having WPML performance issues on my clien´t site. After the last update, things got a BIT better, but still on the border of real world usability. I was even contacted by my hosting (quite beefy one at that, btw) and told to manage my WPML queries, as they are putting lot of strain of the server. 🙂
So should I go through the process of deleting the unnecessary strings? The page is slow both on front-end (anonymous window) and back-end when logged-in.
Thank you very much for your tips – I bet they work wonders, just not sure if it is worth the extra hassle (20k ish strings for me) now. If so, I will indeed do it!
Cheers and may your code be clean. 🙂
Mirek
Hahaha yes! Do it, do it, do it! Clean those strings. If you’re clever…can do it quicker in phpmyadmin. I’ve gotten so good at it, I can clean 20k in about 2-3 hours. Just play some Youtube in the background. Hahahaha.
Johnny,
thank you for keeping this discussion live, you´re golden.
My client phoned me yesterday and was furious that WPML slows down his site so much… so fingers crossed, will clean it up in myAdmin today. 😉 Thanks for the tip, man!
Hey there, Johnny (and everyone reading),
just an update – I have tried to delete most of strings, even all of them, but the site still remains painfully slow. I would say that:
a) It is true that the new version bypasses the database calls (as deleting database entries DID NOT speed up the site).
b) The underlying WPML problem might be somewhere else altogether in new WPML version. I am even debating of rollback to previous version and delete the strings, but that might be more work than simply trying other solution. Ah well. 🙂
Just to be clear – has anyone tried different multi-language plugin (not the ones in the cloud such as Weglot) with success, by which I mean fast and hassle-free operation?
Mirek
ps: I have tried migrating to Polylang via their “WPML to Polylang” plugin – it transfers most things ok, but not everything (since it is formerly intended for non-Woo use as far as I can tell). And when I install “Hyan to Woocommerce Integration” (former WooPoly), the speed is back to stutter even with WPML turned off. So I guess they use similar methods to (slow down :)) translate the site.
Hmmm…I’m very sorry to hear you’re not finding the speeds you want. I have a massive site on WPML and it’s been super fast even 5 years ago on older WPML. Are you able to share your URL and server environment specs? (Doesn’t have to be public, of course.)
Hello Johnny,
I really appreciate you taking care.
I can share the URL and specs no problem – https://laoteashop.cz
The server base specs are PHP 7.3, 512M memory limit, 256M WPML memory + various tweaks such as real cron job instead of WP one, Memcached with preloaded cache (caches DB calls in server RAM), static caching of almost everything that does not break site (combining CSS does, otherwise compressing all), optimized images, …
The hosting platform is, true, Siteground SHARED hosting, but their highest (GoGeek) plan. When I turn off WPML and/or try Polylang (but that does not migrate everything flawlessly), the load time is usually about 1s again. The shop has around 150 simple products, nothing complex going on.
Renting VPS/dedicated is sadly not an option for my client, but I would be hesitant nevertheless, as the WPML support says the (duplicated) site runs very slow even in their own environment.
ATM I am speaking with WPML support and to their credit, they try, but my client does not have the time – this is the only time in year when he used to get biggest sales on his former site, which was very basic and fast. So I cannot wait for WPML and do the back-and-forth support game.
Hope I have not bombed you with wall of text – I just wanted to give context, since you´ve asked. I would not otherwise have bothered you with this. 🙂
What would you say, Johnny? I can share more specs privatelly, should that help. But I realize this is not a paid support forum. 🙂
Thank you, man.
Mirek
Ahhh, I see it! Honestly, I think you should try our managed hosting service. It’s definitely more expensive than SiteGround but not totally out of range. SiteGround GoGeek plan costs $35/month after the first year and I think our $25/month POWER plan is all you need. You’ll get faster dynamic calls with us.
But in you case you can’t or aren’t considering other webhosts, my thoughts are below:
– SiteGround shared servers don’t have enough muscle for dynamic calls that heavier plugins need.
– Object-caching like Redis or the older Memcache can do wonders sometimes, but not on a limited shared server like with SiteGround. Why? I think their ram is slower and that either they won’t give you enough ram space…ORRRR it gets purged so often (due to other clients) that you never really benefit from it.
– If staying on SiteGround, I honestly recommend leaving all of SiteGround’s supercache/memcache OFF and use a static caching plugin like Swift Performance or WP Rocket.
I can also play around with your site if you can give me access. It’d be a great case study for this page.
Hello there, Johnny,
I was busy moving the site live, and did so with Polylang. It runs quite well now, but I am considering your offer strongly – I would love to dig deeper as to what exactly is causing WPML on this site to run slowly.
Funny thing is – I am running it on second site as well, which has much more products and custom code and it is running quite well, certainly usable.
Would you be so kind to show me the hosting details? My client will not use it, but I might as well do, as I am building another e-commerce store now and would love to try another hosting.
Anyway, I am having issue with “Add to cart” button now – it takes about 4-6s to add a product. Funny thing again – on the second site I´ve mentioned, the action takes about 1-2s. 🙂
So I am starting to think that my site itself might be corrupted somehow. I know this is out of scope of this topic (WPML), but should you know some tips for that, that would be great. I can see in dev tools that Ajax add to cart takes long TTFB indeed.
Thank you very much, Johnny, speak soon hopefully. 🙂
Mirek
You can check us out here at JohnnyVPS.com; we offer free clone tests, too. 🙂
Johnny, thanks!
I will reach you via contact form so as not to spam this blog post with personal convo.
Have a great day. 🙂
Mirek
Hi Johnny. In 2021 is this guide already good or did wpml updates that the strings won’t slow down the page?
Good question, just wondering same thing, Still good in 2021? As they are changing price, buy or do not buy.
Same ++
Set up 2 sites?
Are you sure that’s a good option?
How do you sync the rel=”alternate” hreflang elements? That’s probably one of the most important elements to WPML and your suggestion would appear to break that.
I can’t tell if this question is actually about multilingual functioning or about SEO.
WPML creates rel=”alternate” for all translated content. If you have the content over 2 sites then the link is broken, unless there is a solution to this.
Just flagging this as you say seperate sites is a solution, but it’s not a good solution if you are concerned about SEO or want to offer users the ability to switch between translations of the same content.
My site has a main language switcher (as an entire site) but doesn’t have option to switch between languages for every page. And that’s ok as I don’t see anyone trying to read in 2 languages. In regards to SEO…zero SEO problems here either. Each site ranks for its own language.
But either way…this guide is written for WPML speed optimization. And my tactic does that wonderfully.
Hi! This article is a life-saver! Thank you. I’m reading in it in 2023 and can’t find the option to Disable auto-register strings for themes/plugins. Maybe they changed the interface?
If you could point me in the right direction, I’d be great!
How can I know if the string is used on the frontend?
or in an e-mail?
I have 6000+ strings in the WooCommerce domain…