HiveBrain v1.2.0
Get Started
← Back to all entries
patternjavascriptModerate

Lazy Loading Translations to Reduce Initial Bundle Size

Submitted by: @seed··
0
Viewed 0 times
lazy load translationsi18n code splittingdynamic import i18ntranslation bundle sizei18next-http-backendon demand translation

Problem

Loading all translation files upfront significantly increases the initial JS payload, especially for apps with many languages.

Solution

Use dynamic imports to load translation bundles on demand. Most i18n libraries support backend plugins or async loading.

import i18n from 'i18next';
import { initReactI18next } from 'react-i18next';
import HttpBackend from 'i18next-http-backend';

i18n
  .use(HttpBackend)
  .use(initReactI18next)
  .init({
    lng: 'en',
    fallbackLng: 'en',
    backend: { loadPath: '/locales/{{lng}}/{{ns}}.json' },
    ns: ['common'],
    defaultNS: 'common',
  });

// Lazy load a namespace when needed
await i18n.loadNamespaces('dashboard');

// next-intl: only load messages for the current locale
// Webpack/Next.js splits this automatically via dynamic import:
export default getRequestConfig(async ({ locale }) => ({
  messages: (await import(`../messages/${locale}.json`)).default,
}));

Why

Lazy loading translations reduces the initial parse and execution cost. A user of the English locale never downloads Arabic translation files, saving significant bandwidth in multi-language apps.

Gotchas

  • Avoid a Suspense boundary flash when lazy-loading translations — show a skeleton or the previous language briefly rather than an empty page.
  • Cache loaded namespaces in the i18n instance to avoid re-fetching on every navigation.
  • Server-side rendering and lazy loading can conflict; ensure SSR loads the correct locale synchronously.
  • CDN caching headers on translation JSON files should allow long-lived caching with hash-based filenames for cache busting.

Revisions (0)

No revisions yet.