I would like to dedicate this blog post to WPML, hoping they improve and become more reliable.

We bought WPML on April 18, 2018, getting a Multilingual CMS lifetime license for $195. The cost isn’t the issue—it’s the chaos it caused. My main concerns are page speed issues, random bugs, delayed PHP 8.2 support, and the plugin slowing our website so much it became nearly unusable.

Why We Chose WPML

In 2018, Liran asked if we could create Hebrew and Spanish versions of our site. After reviewing WPML and Polylang, we chose WPML due to easier integration. Initially, WPML was simple to set up, but we soon faced limitations. It couldn’t handle the complex translations we needed, so we built an internal API to fill the gaps. WPML handled static pages while our API managed dynamic event translations.

When duplicating posts to Hebrew and Spanish, our website slowed dramatically. We used Advanced Custom Fields for extra fields and Yoast for SEO, and WPML compounded the issue by making us duplicate over 5000 events, ballooning the site to 20,000 pages.

Who Should Use WPML?

WPML is designed for large-scale multilingual sites like e-commerce. However, even with our 3 domains and 20,000 pages, the admin dashboard became unbearably slow. By 2024, we expanded to 11 domains and the issues only worsened. WPML often blames clients for performance issues, but a simple search reveals countless threads about WPML’s poor optimization and excessive database queries causing high TTFB.

TTFB and Endless Queries

Query Monitor exposed how WPML floods each page load with unnecessary queries. WordPress has its flaws, but a paid plugin like WPML should perform better. I managed to build a faster replacement in just two months. WPML has had years to improve yet remains sluggish.

Deactivating WPML reduced our loading time by over 90%.

Random Bugs

• Random SEO language mix-ups requiring manual string refreshes.
• Routing failures causing incorrect term redirects.
• String overwrites causing data loss.
• White screens after updates, forcing full reinstallation.

PHP 8.2

WPML delayed fixing minor PHP 8.2 deprecation warnings for over a year, despite it being a trivial fix that included pre-initializing a property as the forum post suggested (https://wpml.org/forums/topic/deprecation-warning/).

Conclusion: Skip WPML for Business Use

WPML isn’t worth the performance hit and bugs for serious businesses. It might work for smaller sites but can cripple larger ones.

Our Alternative Solution:

We built a translation API accepting requests like:

{
   "language": "es",
   "key": "string-x-3"
}

We batch queries into a single request per page, with a fallback to English if no translation exists or defaulting to the EN domain if that’s what we chose to do. This streamlined solution improved our page speed by over 90%.

In a future post, I may write about our Translation API, how it works, and give the full picture. It’s mostly a concise lang/key pair system that retrieves the chosen language dynamically. If the language is English, it pulls directly from WordPress. Otherwise, it queries our Translation API for the translation.

We likely lost more revenue from slow loading times than it cost to replace WPML. If you’re still using WPML, test your page load times compared to ticket-compare.com. The difference speaks for itself.

A quick business tip for WPML’s parent company: Sometimes it’s best to start fresh. WordPress has evolved, and so should you. If a self-taught developer can build a functional alternative in two months, it’s worth questioning what a team of 50 developers has been doing for seven years that results in such poor performance.