Multilingual WordPress Performance: 7 Ways to Keep a Translated Site Fast

Summarize this post with: 9 min read

ChatGPT Perplexity Grok Google AI

A multilingual WordPress site stays fast when every language version is treated as its own set of cacheable pages: give each language a separate URL, make sure your page cache and CDN store each one separately, load fonts only for the scripts a page uses, and choose a translation method that delivers finished, translated HTML instead of swapping text after the page loads. Then measure Core Web Vitals per language, because a fast English home page says nothing about the Japanese one.

Key takeaways

• Measure each language separately. Google’s “good” thresholds are LCP within 2.5 s, INP under 200 ms and CLS under 0.1, at the 75th percentile of page loads.
• Language-specific URLs (/de/, /fr/) can be cached like any other page. Language chosen by cookie usually can’t.
• Clear the page cache for translated pages when translations change, or visitors will see stale text.
• Split web fonts by script with unicode-range, so a German visitor doesn’t download Japanese glyphs.
• Avoid automatic language redirects on every visit; each redirect is an extra round trip before anything renders.

Why multilingual WordPress sites slow down

Adding languages multiplies the number of pages without changing your server. Five languages on a 200-page site means about 1,000 URLs to cache, crawl and keep fresh. Performance problems usually come from one of five places:

1. Cache misses. Translated pages aren’t cached, or are cached under the wrong key.
2. Translation work at request time. Translations are looked up or generated while the visitor waits.
3. Client-side swapping. The page loads in the original language, then JavaScript replaces the text, which delays the final content and can shift the layout.
4. Heavy fonts. Adding Chinese, Japanese, Korean or Arabic adds large font files.
5. Redirect hops. Language detection that redirects every first visit adds a round trip.

Each has a straightforward fix.

Step 1: measure per language

Google recommends achieving good Core Web Vitals, which it says “aligns with what our core ranking systems seek to reward” (Google Search Central). The targets:

Web.dev recommends judging these at the 75th percentile of page loads, split by mobile and desktop (web.dev).

How to measure per language:

• Run PageSpeed Insights on the same page in each language (/pricing/, /de/pricing/, /ja/pricing/). Differences point straight to language-specific problems such as fonts or long text causing layout shifts.
• In Search Console’s Core Web Vitals report, open the example URLs in each issue group and note which language folders appear.
• Test from the regions you serve. A site hosted in the US will have higher latency for visitors in Asia, whatever the language.

Step 2: give each language its own cacheable URL

Page caching is the biggest single win. The WordPress Advanced Administration handbook says caching plugins serve pages as static files and “can improve performance several hundred times over for fairly static pages” (WordPress Developer Resources).

That only works if each language has a distinct URL. When the language is chosen by a cookie or by the browser’s settings and served on the same URL, a page cache either stores one language for everyone or has to be bypassed. Google also prefers separate URLs for SEO: it recommends “different URLs for each language version of a page rather than using cookies or browser settings” (Google Search Central).

Checklist for your caching plugin:

• Cache pages under /de/, /fr/ and so on, and check none are in the exclusion list.
• If the plugin can preload the cache, include the translated URLs; preloading from your sitemap is easiest if the sitemap lists them.
• Don’t vary the cache by a language cookie unless you have no other choice.
• Purge the translated URL when its translation changes, not only when the original post is edited.

Step 3: serve translated HTML, not text swapped after load

How your translation tool produces a translated page matters as much as caching.

• Server-side translation generates the translated HTML on the server. The visitor receives the finished page, and a page cache can store it.
• Client-side translation sends the original page, then JavaScript fetches translations and replaces the text in the browser. It works on any platform, but the translated content arrives later, and longer translated text can move elements after they’re painted, which shows up as layout shift.

On WordPress, prefer a server-side method for your main languages. If a client-side script is your only option on part of the site, reserve space for text that grows (buttons and menus especially) and test CLS in each language.

Step 4: split fonts by script

Latin fonts are small; complete CJK (Chinese, Japanese, Korean) fonts can be many times larger. Loading every script on every page wastes bandwidth.

Use the @font-face unicode-range descriptor. MDN explains that if a page doesn’t use any character in the range, “the font is not downloaded”, and that the descriptor exists so a site “with many localizations” can provide separate font resources for each script (MDN).

@font-face {
  font-family: 'Brand Sans';
  src: url('/fonts/brand-latin.woff2') format('woff2');
  unicode-range: U+0000-00FF, U+0131, U+0152-0153;
  font-display: swap;
}
@font-face {
  font-family: 'Brand Sans';
  src: url('/fonts/brand-arabic.woff2') format('woff2');
  unicode-range: U+0600-06FF;
  font-display: swap;
}

Also:

• Self-host WOFF2 files and preload only the Latin (or main-script) file used above the fold.
• Consider using a good system font for scripts your brand font doesn’t cover, instead of a large web font.
• Use font-display: swap so text shows immediately in a fallback font.

Step 5: keep images and scripts lean in every language

• Localized images. If you replace images per language, compress and size each version like the original; it’s easy to upload an unoptimised 4 MB banner for one market.
• Lazy loading. WordPress adds loading="lazy" to images by default; make sure your hero image is not lazy-loaded, in every language template.
• Third-party scripts. Market-specific chat widgets, payment badges and trackers add up. Load them only on the languages or pages that need them.

Step 6: avoid unnecessary redirects

Automatic redirects based on browser language add a round trip before the first byte of the right page. Google also advises against redirecting users to a language version “based on what you think the user’s language may be”, because it can stop users and search engines reaching all versions (Google Search Central).

Better options:

• Let people pick a language with a visible switcher, and link internally to translated URLs so they stay in their language.
• If you do redirect, do it only on the first visit to the home page and remember the choice.
• Point hreflang and internal links at final URLs, not at URLs that redirect.

Step 7: get the basics right on the server

Translated pages don’t change the fundamentals. The WordPress handbook points to caching, a CDN for static files and server tuning as the main levers:

• Keep PHP current and OPcache enabled.
• Add a persistent object cache (Redis or Memcached) if your host supports it, especially for WooCommerce or membership sites where full-page caching is limited.
• Use a CDN for images, CSS and JS, and for full pages if your setup allows, so visitors far from your server get them from nearby.
• Keep the plugin list short. Every active plugin runs on every uncached request, in every language.

How the ConveyThis WordPress plugin fits

The ConveyThis plugin translates pages on the server and serves each language on its own subfolder or subdomain, so translated pages can be cached like the original. It keeps a local cache of translations for each page and language, so repeat requests don’t wait on the translation service, and when you change a translation it clears the page cache in popular caching plugins such as WP Rocket, W3 Total Cache, WP Super Cache and WP Fastest Cache.

Other settings worth knowing:

• Exclude pages or sections that don’t need translating, such as account areas, to keep translation work where it matters.
• Automatic redirection by browser language is off unless you enable it, and uses the browser’s language rather than IP lookups; see automatic redirection.
• Words are counted only when translated content is shown to visitors; bots don’t count.

The WordPress integration page covers installation and settings, and plans and pricing lists word and language limits per plan. For translating theme strings themselves, see our guide to translating a WordPress theme.

Frequently asked questions

Does adding languages slow down a WordPress site?

It doesn’t have to. Each language adds pages, not per-page weight, as long as translated pages are cached on their own URLs and translations are applied on the server. Slowdowns usually come from uncached translated pages, client-side text swapping, heavy fonts or redirects.

Should translated pages be cached separately?

Yes. Each language should have its own URL, and your page cache and CDN should store each URL separately. Purge a translated page when its translation changes.

How do I measure performance for each language?

Run PageSpeed Insights on the same page in each language and compare, and check which language folders appear in Search Console’s Core Web Vitals report. Aim for LCP within 2.5 seconds, INP under 200 milliseconds and CLS under 0.1.

Are subdirectories or subdomains faster for a multilingual site?

Neither is inherently faster. Subdirectories share one host, cache and CDN setup, which is simpler to manage; subdomains can be hosted separately if you need servers closer to a region.

How do I stop large fonts slowing down translated pages?

Split fonts by script with the unicode-range descriptor so browsers only download fonts for characters the page uses, serve WOFF2, and use font-display swap.

Keep it fast as you grow

Speed and translation quality both depend on how translated pages are produced. You can create a ConveyThis account, install the WordPress plugin, and measure your translated pages against the originals.