You added a Hindi version, or French and German, and since then pages take longer, the dashboard feels heavier, and the translated pages are noticeably slower than the originals. Or everything seems fine until a visitor switches language and waits. Why is a multilingual WordPress site slow in ways the single-language version never was? The reasons are specific enough to check one by one.
Most of them come down to two things: how your translation plugin stores and serves content, and whether your caching knows about languages. Hreflang, URL structure and what Google needs from a multilingual site are a different subject, handled in our post on multilingual WordPress plugins and what Google needs.
Three ways translation plugins work
Translation plugin speed starts with the plugin’s basic design. Roughly, there are three approaches, and each puts the extra work in a different place.
Separate posts for each language
WPML and Polylang store each translation as its own post or page, linked to the original. Your database ends up with a copy of every translated item per language. To show the right one, the plugin adds a language condition to WordPress’s queries: WPML keeps its own table of which post belongs to which language, and Polylang records the language using WordPress’s taxonomy system.
The extra work happens while the server builds the page. Each query does a little more, there are more rows to look through, and menus, widgets and settings may exist per language. On a small site this is barely noticeable. On a large site, a store with many products, or a site with several languages, it adds up, mostly on uncached pages and in the dashboard.
Translating the finished page
TranslatePress and similar plugins work differently. WordPress builds the page in the original language, and before it is sent, the plugin goes through the output and replaces each piece of text with its translation from the plugin’s own tables. That makes editing pleasant, because you translate on the page itself, but it means every uncached page view in a secondary language has an extra processing step on the server.
Once a translated page is cached, that cost disappears for visitors. Without caching, or for logged-in users and shoppers who bypass the cache, it is paid each time.
Hosted translation services
Weglot and similar services keep translations on their own platform. The plugin on your site fetches them and keeps a local copy. Your server does less translation work itself, but translated pages depend partly on the service, and the first view of a new or changed page can involve fetching or creating its translation. Automatic machine translation of new content, where it is switched on, happens at this stage.
String translation: the hidden load
Your content is only part of what gets translated. Theme text, plugin labels, buttons, form messages, menu items and widget titles are all strings, and multilingual plugins have systems for translating them too.
WordPress itself loads translation files for the theme and each plugin in the visitor’s language. Recent versions of WordPress load these files more efficiently than older ones did, which helps every non-English site. Multilingual plugins then add their own string tables for text that is not covered by those files.
Two settings deserve a look:
- Automatic string registration. Some plugins can scan for and register new strings as pages load, so you can find text to translate. It is useful during setup, and it adds work to every request while it stays on. Switch it off once your translations are in place.
- Strings you never translate. Large string tables full of entries from deleted plugins, or from plugins whose text never appears on the front end, still have to be managed. Check the plugin’s tools for cleaning up unused strings.
Caching per language
This is where most of the speed difference between a quick multilingual site and a slow one comes from.
Separate addresses make caching easy
Page caches store pages by address. If each language has its own URL, such as /fr/ and /de/ subfolders or separate subdomains, every language version is cached as its own page, and caching works normally. This is also what search engines want, so it is the common setup.
Cookies and detection make it hard
Trouble starts when the language depends on something other than the address:
- Language stored in a cookie. The same URL shows different languages to different visitors. A page cache that ignores the cookie serves the wrong language; one that respects it may bypass caching for those visitors entirely.
- Automatic detection by browser language or location. Redirecting visitors on their first visit means that visit cannot simply be served from the cache, and redirects add a round trip before anything appears.
- Currency switching on multilingual stores. Currency stored in a cookie has the same effect as a language cookie, and stores often combine both.
If you see translated pages that are always uncached, look at the response headers for the cache status, then check whether a language or currency cookie is involved. Your caching plugin’s documentation usually explains how it handles the multilingual plugin you use.
Purging and preloading every language
When you update a post, its translations may need purging too, along with the home page and archives in every language. Some caching plugins handle this automatically for well-known multilingual plugins; others need settings. And if you preload your cache, make sure the preload covers every language’s URLs, usually through each language’s sitemap. Otherwise the first visitor to each translated page pays the full cost. Our post on warming the cache before visitors arrive explains how preloading works and when to hold back.
Multilingual WordPress site slow? Measure where the time goes
Compare like with like:
- Pick one page and its translation in each language.
- Test each with the cache cleared, three times, and note the server response time.
- Test each again once cached.
- Logged in as an administrator, use Query Monitor’s queries-by-component view on the original and a translation. It shows how much of the database time belongs to the multilingual plugin.
If cached pages are fast in every language and only uncached ones are slow, the plugin’s work on the server is the cost. A persistent object cache often helps there, because the extra queries tend to repeat; our explainer on Redis object caching for WordPress covers what it needs from your host. If translated pages are slow even when they should be cached, the cache is being bypassed, and the cookie and detection points above are where to look.
Mistakes that slow multilingual sites
- Two translation plugins at once. Usually left over from a change of mind. They conflict and double the work. Choose one and remove the other carefully, after exporting anything you need.
- Languages nobody reads. Each language adds content, strings, cache entries and maintenance. If analytics shows almost no visits to a language, consider whether it earns its place.
- Machine translating everything on the fly. Translating large amounts of content automatically as it is first viewed adds waits for visitors and, as our SEO post notes, raises quality questions.
- Duplicated media. Some setups create a separate media record per language for each image. Check whether yours does and whether you need it.
- Testing only the original language. Speed checks after updates often cover the English home page and nothing else. Include at least one translated page.
If your second language is an Indian one, there are content and font choices too; our guide to building a Hindi or Bengali version of your website covers them. For how the translation plugin fits into the wider plugin picture, the section guide on plugin weight and what makes plugins heavy applies here as well, and our overview on improving website speed shows where caching and server time sit for any site.
Frequently asked questions
Which multilingual plugin is fastest?
There is no single answer, because each puts its work in a different place. Plugins that store separate posts add database work; plugins that translate the finished page add processing on uncached views; hosted services shift work to their platform. With proper per-language caching, all of them can be quick for visitors. Test on staging with your own content and languages.
Will adding a second language double my server load?
Not necessarily. Cached pages in any language cost very little to serve, so the extra load comes mainly from uncached requests, the dashboard and background tasks. If visits are split between languages, total traffic stays the same. The larger difference comes from how well each language is cached, not from the number of languages alone.
Why is only the translated version of my site slow?
The most common reason is that translated pages are not being cached, often because the language is detected by cookie or browser setting rather than a separate URL, or because the preload only covers the main language. It can also be a plugin that translates the finished page on every uncached view. Check the cache status header on a translated page first.
Should multilingual WooCommerce stores use a different setup?
Stores have more to translate, including products, attributes, emails and checkout text, and often add multiple currencies. Use a multilingual plugin with proper WooCommerce support, keep each language on its own URL, and check how currency switching interacts with your page cache. Test the cart and checkout in every language and currency after setup.
Translated pages belong in any speed review, not just the original language. If you bring the site to our speed optimisation service, tell us which languages you run, so the translated pages are measured alongside the original from the start.
