More Languages Means a Bigger Bundle — But How Much?
A multilingual web app needs a translation file per language, and how you load those files makes a huge difference in what users actually download. Bundle every language's translation data into one JavaScript file (eager loading) and the bundle size grows linearly with your language count — users end up downloading data for languages they'll never use.
Split the files per language and lazy-load only the one the user selected, and the initial load stays fixed at roughly one language's worth, regardless of how many you support overall. This calculator estimates the rough JSON size per language from your key count and average string length, adds typical key/value overhead, and compares eager vs. lazy strategies side by side. Translation text tends to compress very well with gzip thanks to repeated words and patterns, so the actual transfer size ends up much smaller than the raw JSON.
In practice, teams get the best results combining i18next-style namespace splitting, route-based code splitting, and lazy loading together. If you only support two or three languages, eager loading is usually fine — but once you're past four or five, the size gap becomes noticeable enough that a lazy-loading structure is worth the effort.
Frequently Asked Questions
Lazy-loading only the language the user actually selected is the most effective approach — it keeps the initial load far smaller than bundling every language.
Yes. Translation text tends to have a lot of repeated patterns, so it compresses very well and the transferred size drops significantly with gzip.
Bundling every language into one file grows the size in proportion to the language count, but splitting per language and lazy-loading keeps what users actually download flat.