How to prevent putting the translations in all pageProps when doing clientside navigation

[bjarkebm]

I'm learning how next-i18next works. Currently we have a large-ish website, and all pages use the serverSideTranslations like

  const translations = await serverSideTranslations('en', ['somenamespace']);
  // ...
  return {
    props: {
      // other props ...
      ...translations,
    },
  };

That works fine, and will ensure that translations work on server side rendering with getServersideProps and getStaticProps.
On a full page load, this is obviously fine.

When the user does client-side navigation to a page that uses the same namespace, it seems wasteful to me to put the translations into the page props again-
Currently we have a single namespace at around 130KB, and splitting it into smaller chunks while ensuring that all the necessary translation strings are available correctly on all the pages is quite a task, especially since we have a lot of shared components between the pages.

{
  "_nextI18Next": {
    "initialI18nStore": {
      "en": {
        "somenamespace": {
          // LOTS OF KEY/VALUES HERE, repeated in all payloads from the server whenever the user client-side navigates (~130KB for us)
        }
      },
      "initialLocale": "en",
      // config ...
    }
  }
}

What I'm wondering is, is there a way to prevent putting the translations into the props, but still support the server side rendering?

[youssef509]

You’re right — what you’re seeing is the expected behavior of next-i18next, because serverSideTranslations() injects the translation resources into the page props to make them available for SSR and hydration. When you navigate client-side, Next.js reuses the JSON payload of the next page (including those translations), so you see that repeated 130KB block.

There’s no built-in way to “skip” sending translations in the props and still have them available for SSR, because the server needs to serialize them for hydration consistency.

That said, there are a few practical approaches to reduce this overhead:

Namespace splitting:
Break your large namespace into smaller logical chunks (e.g. per-feature, per-layout). You can still load shared ones globally via _app or a custom AppWithTranslation setup. This is the officially recommended way to manage performance.

Use i18next-http-backend (or a custom backend):
Move your translation loading to the client (via HTTP requests) instead of embedding them in SSR props. You’ll lose fully preloaded SSR translations, but it drastically cuts payload size and still hydrates correctly on client navigation.

Cache translations client-side:
If you keep SSR for the first render, you can configure i18next to persist resources in memory (or localStorage) after initial load. That way, when navigating to a new page using the same namespace, it won’t need to re-fetch or re-embed that data.

In short:
You can’t safely remove translations from the props without breaking SSR hydration, but you can reduce payload size and duplication by splitting namespaces or switching to a backend loading strategy.