Multilingual performance.
On a multilingual site the biggest performance variable is the font subsets: every language needs different characters, and needless characters are downloaded on every page.
Being multilingual brings no direct performance cost — separate pages are generated per language and every user downloads only the page in their own language. But there is one item that, unattended, adds weight to all the languages at once: the font files.
A font file can carry thousands of characters by default. The character set needed for Turkish, English and German is a small part of that — and the needless ones are downloaded on every page, for every user.
The subset
The solution is producing a subset: the font file is regenerated with only the needed characters. The gain is usually dramatic — it can come down to a small percentage of the full file.
Which subset is needed depends on the languages. For Turkish the latin and extended-latin sets are needed: the extended set contains Turkish’s dotless ı, ğ and ş. For German the umlauts and the eszett are found in the same sets.
On this site both font families are produced with the latin and extended-latin subset — the Cyrillic, Greek and Vietnamese sets never come down. Both are variable fonts, meaning one file carries all the weights and widths.
- Produce only the needed sets — let unused alphabets not download on every page.
- Use variable fonts — one file instead of six files for six weights.
- Do not serve a separate file per language — the user switching languages triggers a re-download.
- Limit the family count — every family is an extra request and an extra swap risk.
- Self-host — an external host is an extra connection cost and a privacy risk.
The third item holds a trade-off: a separate file per language strips that language’s needless characters entirely, but a new file downloads when the user switches languages. On a site with all three languages Latin-based, one file is more efficient; when Cyrillic or the Arabic alphabet is added, the equation changes.
The other items
Outside the font, multilingualism’s performance impact is limited, but two points demand attention.
The first is text length: German text is longer, so the German page is a bit heavier. The difference is small and usually swallowed by compression — but longer text also means more layout computation, and on very long pages it becomes measurable.
The second is image content: images containing text must be produced separately for every language, and that means both production load and storage. That is one more reason, beyond performance, to avoid images containing text — in addition to the accessibility and machine-readability reasons.
On this site there are no images containing text; all text is written as text. The social sharing cards are an exception, but they are produced in the browser and do not come down with the page.
Measurement and budget
On a multilingual site the performance budget should be measured per language. The German version of the same page carries longer text, uses a different font width and sometimes contains different images — all three change the weight.
- Every language must be measured separately — measuring one and assuming the others misleads.
- The font subset must be verified — is there a needless alphabet in the file?
- Is the family count limited — every family is an extra request and swap risk.
- Was the text-length difference measured — the longest language sets the budget.
- Are the images language-independent — an image containing text means separate production per language.
The fourth item holds a principle: the budget is set by the longest language. If a budget tuned to Turkish breaks in German, the budget was set wrong.
On this site the two font families are produced with the latin and extended-latin subset, both variable and served from the site’s own server. The measured JavaScript total is 83.7 kilobytes after gzip — language-independent, because the code is language-independent.
And an architecture note: on this site the pages are pre-generated and served as files, so the language count does not raise the server cost. Three languages mean three times the pages but not three times the processing — every page is already a file.
When the language count becomes a cost
In static generation the language count produces no server cost, but it does produce build time and storage. Fifty pages in three languages mean a hundred and fifty files — and every build regenerates them all.
At small scale that goes unnoticed. On this site fifty-eight pages are generated within seconds. But a thousand-page site in seven languages means seven thousand files, and at that scale the build time can become a problem — especially if every small change triggers a full regeneration.
The solution is incremental generation: only the changed pages are regenerated. On this site a similar logic is already in place for the lastmod ledger — every page’s output is fingerprinted and the stamp advances only when the fingerprint changes. The same fingerprint can serve incremental generation too.
And a final note: as the language count grows, the sitemap, RSS and map files multiply too. On this site three separate RSS feeds are produced for the three languages, and all come out of a single generator — a load impossible to manage by hand becomes invisible through automation.
A frame to close: the performance cost of being multilingual, when built right, is nearly zero. What produces cost is not the language count but how the languages are served — the font subset, images containing text and dynamic generation. All three are decisions made at the design stage, and all three are expensive to correct later.
A final measurement suggestion: every language version’s weight should be reported separately and the difference between them watched. If the difference is larger than expected, there is a language-specific load somewhere — usually an image containing text or a resource specific to that language.
On this site the page weights are listed language by language in the build output and the difference stays small; the largest deviation is on the German pages, and its cause is a known one — text length.