@intlayer/docs 9.5.6 → 9.5.8

package/blog/en-GB/i18next_vs_intlayer.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "i18next vs Intlayer: 2026 Benchmark & Comparison"
 description: "react-i18next and next-i18next measured against Intlayer on Next.js and TanStack Start. Bundle size, content leakage, locale-switch reactivity and developer experience."
 keywords:
@@ -25,6 +25,8 @@ author: aymericzip
 
 # i18next VS Intlayer | React & Next.js Internationalisation (i18n) Benchmark
 
+![i18next VS Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18next-next-intl-intlayer.webp?raw=true)
+
 `i18next` is the most widely used i18n framework in the JavaScript ecosystem. Through `react-i18next` and `next-i18next`, it powers a large share of React and Next.js applications. Intlayer is a compiler-based, component-scoped alternative.
 
 This article compares them on measurements rather than feature lists. The numbers come from [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom), an open-source suite that builds the same application with each library and records what the browser actually downloads.
@@ -99,6 +101,10 @@ For each build, the suite records:
 
 ### Results on Next.js (`next-i18next`)
 
+Pick the metrics and the libraries you care about:
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | Library                           | Strategy       | Lib size (gz) | Page JS avg (gz) | Locale leak | Page leak | Component avg (gz) | E2E reactivity | Hydration |
 | --------------------------------- | -------------- | ------------: | ---------------: | ----------: | --------: | -----------------: | -------------: | --------: |
 | **base** (no i18n)                | -              |        0.0 KB |         141.0 KB |        0.0% |      0.0% |             0.9 KB |        13.4 ms |   11.8 ms |
@@ -119,6 +125,15 @@ For each build, the suite records:
 - **Component size.** A component calling `useTranslation()` compiles to 26-79 KB depending on the setup; the same component with `useIntlayer()` compiles to 6.9 KB.
 - **Hydration** spikes to 27.7 ms in the `dynamic` setup: the i18next instance initialises and resolves its backend on the client before React can hydrate.
 
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-nextjs.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> Full table, every library and every strategy, in the [Next.js benchmark report](https://intlayer.org/en-GB/doc/benchmark/nextjs).
+
 ### Results on TanStack Start (`react-i18next`)
 
 Same test app on TanStack Start with plain `react-i18next`, which removes the Next.js-specific wiring from the comparison.
@@ -141,8 +156,19 @@ Same test app on TanStack Start with plain `react-i18next`, which removes the Ne
 - Intlayer's `static` row already has **0% page leakage** because only the dictionaries imported by the page's components are bundled. Enabling `importMode: 'dynamic'` removes the locale leakage too.
 - **Component size**: 24-27 KB per component with `react-i18next` versus 6-8 KB with Intlayer. `useTranslation()` binds every component to the global i18next instance.
 
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-tanstack.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> Full table in the [TanStack Start benchmark report](https://intlayer.org/en-GB/doc/benchmark/tanstack).
+
 ## Why the gap? Global instance vs. compiled dictionaries
 
+![Centralized catalogs versus per-component dictionaries](https://github.com/aymericzip/intlayer/blob/main/docs/assets/project_stucture_18n_vs_intlayer.png?raw=true)
+
 `i18next` was designed in 2012 as a runtime: a global instance holds a resource store, plugins extend it, and `t()` looks keys up at render time. This is what makes it so flexible (any framework, any backend, any format) and also what makes it costly:
 
 ```bash
@@ -166,7 +192,13 @@ Same test app on TanStack Start with plain `react-i18next`, which removes the Ne
                 └── page.tsx     # must know it needs ["common", "about"]
 ```
 
-The instance cannot know which keys a component will request, so it keeps whatever namespaces you tell it to load. Optimising means **you** split catalogues into namespaces, **you** list the namespaces each page needs, and **you** keep that list correct as components move between pages. As the [benchmark notes](https://github.com/intlayer-org/benchmark-bloom/blob/main/report/NOTE.md) put it: "maintaining type safety and knowing exactly which namespace should be included on which page is a nightmare".
+The instance cannot know which keys a component will request, so it keeps whatever namespaces you tell it to load. Optimising means **you** split catalogues into namespaces, **you** list the namespaces each page needs, and **you** keep that list correct as components move between pages.
+
+The bill grows on two axes at once, pages and locales:
+
+![Theoretical content leakage by architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
+
+As the [benchmark notes](https://github.com/intlayer-org/benchmark-bloom/blob/main/report/NOTE.md) put it: "maintaining type safety and knowing exactly which namespace should be included on which page is a nightmare".
 
 Intlayer removes the instance. Content is declared next to the component, and the compiler resolves the dependency graph at build time:
 
@@ -193,7 +225,8 @@ Intlayer removes the instance. Content is declared next to the component, and th
 
 ### Setup
 
-**next-i18next (App Router)**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-i18next" value="i18next">
 
 ```ts fileName="src/app/i18n/server.ts"
 import { createInstance } from "i18next";
@@ -228,7 +261,8 @@ export const initI18next = async (
 
 Plus a client-side `I18nProvider` that re-creates the instance with the same options, a `generateStaticParams`, and a `namespaces` list on every page.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="intlayer.config.ts"
 import { type IntlayerConfig, Locales } from "intlayer";
@@ -264,9 +298,13 @@ const LocaleLayout: NextLayoutIntlayer = async ({ children, params }) => {
 export default LocaleLayout;
 ```
 
+</Tab>
+</Tabs>
+
 ### Client component
 
-**react-i18next**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="react-i18next" value="i18next">
 
 ```json fileName="src/locales/en/about.json"
 {
@@ -304,7 +342,8 @@ export const Counter = () => {
 
 > The page rendering this component must load the `about` namespace, and `t("counter.label")` is a plain string until you augment `CustomTypeOptions`.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="src/components/Counter/index.content.ts"
 import { t, type Dictionary } from "intlayer";
@@ -345,9 +384,13 @@ export const Counter = () => {
 
 `label` and `increment` are typed; a typo is a TypeScript error, a missing French value is a build error.
 
+</Tab>
+</Tabs>
+
 ### Synchronous server component
 
-**next-i18next**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-i18next" value="i18next">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 type ServerCounterProps = {
@@ -366,7 +409,8 @@ export const ServerCounter = ({ t, locale, count }: ServerCounterProps) => (
 
 The page calls `i18n.getFixedT(locale, "about")` and threads `t` and `locale` down as props.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 import { useIntlayer } from "next-intlayer/server";
@@ -385,6 +429,9 @@ export const ServerCounter = ({ count }: { count: number }) => {
 };
 ```
 
+</Tab>
+</Tabs>
+
 ## Keep the i18next API, get Intlayer's output
 
 You don't have to rewrite components to get the benchmark numbers above. `@intlayer/i18next`, `@intlayer/react-i18next` and `@intlayer/next-i18next` are drop-in adapters: `useTranslation`, `t()`, `<Trans>`, `{{interpolation}}`, `_one` / `_other` plurals, context suffixes and `returnObjects` keep working, served from Intlayer dictionaries compiled by the Intlayer compiler.
@@ -415,18 +462,85 @@ See the migration guides: [i18next](https://intlayer.org/en-GB/doc/migration/i18
 
 ## When to choose which?
 
-- **Choose i18next** if you need its plugin ecosystem (detectors, backends, ICU, Locize), you localise outside React too (Node services, vanilla JS, other frameworks), your team already knows it, or a translation platform expects `locales/{lng}/{ns}.json`. Budget the time to namespace catalogues, wire a backend and maintain the page-to-namespace map if performance matters.
-- **Choose Intlayer** if you want **component-scoped content**, **strict TypeScript**, **build-time missing-key errors**, **zero-effort tree-shaking and lazy loading**, instant locale switching, synchronous server components, and built-in editorial tooling (Visual Editor, CMS, AI translation, MCP server). Especially relevant for large, modular codebases and design systems.
-- **Choose the `@intlayer/*-i18next` adapters** if you are already on i18next and want the bundle and reactivity gains without a rewrite.
+<AccordionGroup>
+<Accordion header="Choose i18next">
+
+If you need its plugin ecosystem (detectors, backends, ICU, Locize), you localise outside React too (Node services, vanilla JS, other frameworks), your team already knows it, or a translation platform expects `locales/{lng}/{ns}.json`. Budget the time to namespace catalogues, wire a backend and maintain the page-to-namespace map if performance matters.
+
+</Accordion>
+<Accordion header="Choose Intlayer">
+
+You want **component-scoped content**, **strict TypeScript**, **build-time missing-key errors**, **zero-effort tree-shaking and lazy loading**, instant locale switching, synchronous server components, and built-in editorial tooling ([Visual Editor](https://intlayer.org/en-GB/doc/concept/editor), [CMS](https://intlayer.org/en-GB/doc/concept/cms), [AI translation](https://intlayer.org/en-GB/doc/concept/auto-fill), [MCP server](https://intlayer.org/en-GB/doc/mcp-server)). Especially relevant for large, modular codebases and design systems.
+
+</Accordion>
+<Accordion header="Choose the @intlayer/*-i18next adapters">
+
+You are already on i18next and want the bundle and reactivity gains without a rewrite. Your `locales/{lng}/{ns}.json` files stay the source of truth. Measured side by side in [i18next vs @intlayer/i18next](https://intlayer.org/en-GB/blog/i18next-vs-intlayer-i18next).
+
+</Accordion>
+</AccordionGroup>
+
+## FAQ
+
+<FAQ>
+
+<Question title="Why is i18next so much heavier than the other libraries?">
+
+It was designed as a framework-agnostic runtime: a global instance, a plugin pipeline, a resource store, a key resolver. That flexibility is compiled into every bundle. An empty component that only imports the library costs **19.7 KB gzip** with `next-i18next` against **5.5 KB** with `next-intlayer`, and the cost is paid on every page whatever your content weighs.
+
+</Question>
+
+<Question title="Does lazy loading with a backend fix it?">
+
+It fixes the bytes, not the latency. Moving to `i18next-resources-to-backend` saves ~49 KB per page but puts a network round-trip on the locale switch: **123 ms** in the `dynamic` setup and **185 ms** in `scoped-static`, against **3-4 ms** with Intlayer. Hydration also jumps to 27.7 ms because the instance resolves its backend before React can hydrate.
+
+</Question>
+
+<Question title="Can I reach 0% leakage with i18next?">
+
+Yes, with `scoped-dynamic`: one namespace per route, a resources backend and a page-to-namespace map you maintain by hand. It lands at 163.4 KB per page on Next.js, still **+22 KB** over Intlayer's 141.3 KB, which needed no configuration. See [bundle optimization](https://intlayer.org/en-GB/doc/concept/bundle-optimization).
+
+</Question>
+
+<Question title="Do I have to rewrite my components to migrate?">
+
+No. `@intlayer/i18next`, `@intlayer/react-i18next` and `@intlayer/next-i18next` keep `useTranslation`, `t()`, `<Trans>`, `{{interpolation}}`, `_one` / `_other` plurals, context suffixes and `returnObjects`. One plugin line in `next.config.ts` or `vite.config.ts`. Step by step in the [next-i18next migration guide](https://intlayer.org/en-GB/doc/migration/next-i18next).
+
+</Question>
+
+<Question title="What happens to my i18next plugins?">
+
+Backends and language detectors are accepted but inert: there is nothing left to load or detect at runtime. Locale detection becomes Intlayer's routing config (URL prefix, cookie, header). If your app fetches translations from a CMS at request time, use the [Intlayer CMS](https://intlayer.org/en-GB/doc/concept/cms) or `intlayer pull` / `push` instead.
+
+</Question>
+
+</FAQ>
 
 ## Related comparisons
 
-- [next-intl vs Intlayer](https://intlayer.org/en-GB/blog/next-intl-vs-intlayer) (same benchmark)
-- [Lingui vs Intlayer](https://intlayer.org/en-GB/blog/lingui-vs-intlayer) (same benchmark)
-- [vue-i18n vs Intlayer benchmark](https://intlayer.org/en-GB/blog/vue-i18n-vs-intlayer-benchmark) (same benchmark)
+Same benchmark, other libraries:
+
+- [next-intl vs Intlayer](https://intlayer.org/en-GB/blog/next-intl-vs-intlayer)
+- [Lingui vs Intlayer](https://intlayer.org/en-GB/blog/lingui-vs-intlayer)
+- [vue-i18n vs Intlayer benchmark](https://intlayer.org/en-GB/blog/vue-i18n-vs-intlayer-benchmark)
 - [next-i18next vs next-intl vs Intlayer](https://intlayer.org/en-GB/blog/next-i18next-vs-next-intl-vs-intlayer)
 - [react-i18next vs react-intl vs Intlayer](https://intlayer.org/en-GB/blog/react-i18next-vs-react-intl-vs-intlayer)
+
+Going further on i18next:
+
+- [i18next vs @intlayer/i18next](https://intlayer.org/en-GB/blog/i18next-vs-intlayer-i18next), the adapters measured on the same app
 - [Is i18next outdated?](https://intlayer.org/en-GB/blog/is-i18next-outdated)
+- [Using Intlayer with i18next](https://intlayer.org/en-GB/blog/intlayer-with-i18next) and [with react-i18next](https://intlayer.org/en-GB/blog/intlayer-with-react-i18next)
+- [How to internationalize a Next.js app with next-i18next](https://intlayer.org/en-GB/blog/nextjs-internationalization-using-next-i18next)
+
+Reference docs:
+
+- [Next.js benchmark report](https://intlayer.org/en-GB/doc/benchmark/nextjs) and [TanStack Start benchmark report](https://intlayer.org/en-GB/doc/benchmark/tanstack)
+- Compat adapters: [i18next](https://intlayer.org/en-GB/doc/compatibility/i18next), [react-i18next](https://intlayer.org/en-GB/doc/compatibility/react-i18next), [next-i18next](https://intlayer.org/en-GB/doc/compatibility/next-i18next)
+- Migration guides: [i18next](https://intlayer.org/en-GB/doc/migration/i18next), [react-i18next](https://intlayer.org/en-GB/doc/migration/react-i18next), [next-i18next](https://intlayer.org/en-GB/doc/migration/next-i18next)
+- [Bundle optimization](https://intlayer.org/en-GB/doc/concept/bundle-optimization) and [the Intlayer compiler](https://intlayer.org/en-GB/doc/compiler)
+- [Per-component vs centralized i18n](https://intlayer.org/en-GB/blog/per-component-vs-centralized-i18n)
+- [Compiler-driven vs declarative i18n](https://intlayer.org/en-GB/blog/compiler-vs-declarative-i18n)
 
 ## GitHub STARs
 

package/blog/en-GB/is_intlayer_lighter_than_paraglide.md

@@ -0,0 +1,285 @@
+---
+createdAt: 2026-09-23
+updatedAt: 2026-09-23
+title: Is Intlayer Lighter than Paraglide?
+description: Paraglide looks almost free in i18n benchmarks because its code is generated into your repo. Here is where that weight actually goes, why per-node locale reads cost you, and how Intlayer's dynamic loading ships one locale instead of all of them.
+keywords:
+  - Paraglide
+  - Intlayer
+  - Internationalisation
+  - i18n
+  - Bundle size
+  - Tree shaking
+  - Benchmark
+  - Blog
+slugs:
+  - blog
+  - is-intlayer-lighter-than-paraglide
+author: aymericzip
+---
+
+# Is Intlayer Lighter than Paraglide?
+
+Yes.
+
+`Paraglide` has a good reputation for being the lightest i18n solution around, and at first sight the [benchmark](https://intlayer.org/en-GB/doc/benchmark/tanstack) agrees: its library size is close to zero. But a library size of zero does not mean zero bytes shipped. It means the bytes live somewhere the metric does not look.
+
+<TOC/>
+
+## Key Takeaways
+
+**The library size is hidden, not gone:**
+
+Paraglide generates its runtime and message functions into your codebase. That code ships to the browser, but it is counted as _your_ code, not as the library's.
+
+**No provider is not a free win:**
+
+Every `m.my_key()` call resolves the locale on its own, reading the cookie or storage for each rendered node, instead of reading it once from a context.
+
+**No dynamic loading:**
+
+Paraglide imports every locale of a message into your client bundle. Intlayer with `importMode: 'dynamic'` or `'fetch'` loads only the locale being rendered.
+
+**Tree shaking is not guaranteed:**
+
+In some of our benchmarks, Paraglide's advertised tree shaking did not take effect. Check your own bundle.
+
+## Where Does Paraglide's Weight Go?
+
+In the benchmark reports, the "library size" metric measures the provider and hooks of each i18n library in an empty component, before any content is added.
+
+| Library (TanStack Start)      | Lib size (gz) | Lib size (min) |
+| ----------------------------- | ------------- | -------------- |
+| `@inlang/paraglide-js@2.15.1` | 1.8 KB        | 4.5 KB         |
+| `react-intlayer@9.5.1`        | 5.0 KB        | 15.2 KB        |
+
+Read in isolation, Paraglide wins. But Paraglide is a compiler: it reads your `messages/*.json` files and writes a `paraglide/` folder into your repository, containing a `runtime.js` (locale detection, cookie and storage strategies, URL localisation) and one JavaScript function per message.
+
+```bash
+src/paraglide/
+├── runtime.js      # locale detection, strategies, URL helpers
+├── server.js
+├── messages.js     # re-exports every message
+└── messages/
+    ├── _index.js
+    ├── en.js
+    └── fr.js
+```
+
+Because this code sits in your `src/` folder and you import it with a relative path, the bundler attributes it to your application, not to a `node_modules` package. The library size column shows almost nothing, while the same logic still ships in your page bundle.
+
+Generating code is not a bad idea in itself: the generated runtime only includes the logic your configuration needs (prefix strategy, cookie vs. local storage, etc.). Intlayer reaches the same result differently, by injecting environment variables at build time so the bundler drops the branches your configuration does not use. Both approaches end up 3 to 10 times lighter than `i18next` or `next-intl`.
+
+So the fair comparison is not the library size. It is **the JavaScript actually sent per page**.
+
+## Page Weight, Measured
+
+TanStack Start app, 10 pages, measured on the `en` and `fr` routes, gzipped:
+
+| Setup                              | Page JS avg (gz) | Above base  | Locale leak | Other-page leak |
+| ---------------------------------- | ---------------- | ----------- | ----------- | --------------- |
+| Base (no i18n)                     | 111.0 KB         | -           | 0.0%        | 0.0%            |
+| `paraglide` (any strategy)         | 125.1 KB         | +14.1 KB    | 49.7%       | 0.0%            |
+| `intlayer` (`importMode: static`)  | 125.8 KB         | +14.8 KB    | 50.0%       | 0.0%            |
+| `intlayer` (`importMode: dynamic`) | **118.6 KB**     | **+7.6 KB** | **0.0%**    | **0.0%**        |
+
+Next.js 16 App Router, same app:
+
+| Setup            | Page JS avg (gz) | Above base  |
+| ---------------- | ---------------- | ----------- |
+| Base (no i18n)   | 141.0 KB         | -           |
+| `paraglide-next` | 155.3 KB         | +14.3 KB    |
+| `next-intlayer`  | **141.3 KB**     | **+0.3 KB** |
+
+<I18nBenchmark framework="tanstack" vertical/>
+
+> Full data in the [TanStack Start benchmark report](https://intlayer.org/en-GB/doc/benchmark/tanstack) and the [Next.js benchmark report](https://intlayer.org/en-GB/doc/benchmark/nextjs). Every bundle can be inspected in the [benchmark repository](https://github.com/intlayer-org/benchmark-i18n).
+
+Two things stand out:
+
+- In `static` mode, Intlayer ships practically the same content as Paraglide (125.8 KB vs. 125.1 KB). That is expected: both include every locale of the messages a page uses.
+- Paraglide stays at 125.1 KB whatever the strategy, because it has no dynamic mode. Every line in the table above is the static one.
+
+## No Provider: A Good Idea That Isn't
+
+Paraglide has no provider. You import a message and call it:
+
+```tsx fileName="Hero.tsx"
+import { m } from "../paraglide/messages.js";
+
+export const Hero = () => (
+  <section>
+    <h1>{m.hero_title()}</h1>
+    <p>{m.hero_description()}</p>
+    <button>{m.hero_cta()}</button>
+  </section>
+);
+```
+
+No context, no wrapper, no hook. It looks simpler. But the locale still has to come from somewhere. Each generated message function looks roughly like this (simplified):
+
+```js fileName="paraglide/messages/_index.js"
+export const hero_title = (inputs = {}, options = {}) => {
+  const locale = options.locale ?? getLocale(); // resolved on every call
+
+  if (locale === "en") return en.hero_title(inputs);
+  if (locale === "fr") return fr.hero_title(inputs);
+  // ...one branch per locale
+};
+```
+
+And `getLocale()` walks the configured strategies (cookie, local storage, URL, base locale) to find the current locale. So every text node you render (`<>{m.my_key()}</>`) runs its own locale resolution, including reading `document.cookie` in the browser. A page with 200 translated strings resolves the locale 200 times per render, and again on every re-render.
+
+A provider-based library reads the locale **once**, stores it in a context (or a signal, or a store), and every node reads a value already in memory. The provider costs a few hundred bytes. Skipping it costs CPU on every render, and it shows in the benchmark: Paraglide's page load and language-switch timings are consistently behind Intlayer's on TanStack Start (22.1 ms vs. 14.6 ms page load, 4.3 ms vs. 3.2 ms E2E reactivity).
+
+## Developer Experience
+
+Paraglide's source of truth is JSON, but you never import the JSON. You import the generated `.js`:
+
+<Tabs defaultTab="intlayer" group="techno">
+  <Tab label="Paraglide" value="paraglide">
+
+```json fileName="messages/en.json"
+{
+  "hero_title": "Ship your app in every language"
+}
+```
+
+```json fileName="messages/fr.json"
+{
+  "hero_title": "Publiez votre app dans toutes les langues"
+}
+```
+
+```tsx fileName="Hero.tsx"
+// Only exists after the compiler has regenerated it from the JSON
+import { m } from "../paraglide/messages.js";
+
+export const Hero = () => <h1>{m.hero_title()}</h1>;
+```
+
+  </Tab>
+  <Tab label="Intlayer" value="intlayer">
+
+```ts fileName="Hero.content.ts"
+import { t, type Dictionary } from "intlayer";
+
+export default {
+  key: "hero",
+  content: {
+    title: t({
+      "en-GB": "Ship your app in every language",
+      en: "Ship your app in every language",
+      fr: "Publiez votre app dans toutes les langues",
+    }),
+  },
+} satisfies Dictionary;
+```
+
+```tsx fileName="Hero.tsx"
+import { useIntlayer } from "react-intlayer";
+
+export const Hero = () => {
+  const { title } = useIntlayer("hero");
+
+  return <h1>{title}</h1>;
+};
+```
+
+  </Tab>
+</Tabs>
+
+That loop has a cost:
+
+- Every change to a JSON file requires a regeneration before the import resolves or the types update.
+- The generated `paraglide/` folder is either committed, which means merge conflicts on generated files in every PR touching copy, or ignored, which means a generation step before every type check, test and CI job.
+- Every string becomes a function call. Constants turn into `m.key()` everywhere, including places where a plain value would do.
+
+## Tree Shaking: Check Your Bundle
+
+Paraglide's main promise is that unused messages are tree-shaken, since each message is its own export. In the Svelte + Vite benchmark, it works as advertised.
+
+In other setups, it did not. In our [Next.js](https://intlayer.org/en-GB/doc/benchmark/nextjs) run, Paraglide's pages weigh 14 KB more than the base app, where `next-intlayer` adds 0.3 KB. Earlier runs on TanStack Start showed messages from other pages ending up in the route bundle as well.
+
+Tree shaking depends on your bundler (Turbopack, Rolldown, Rollup), on how messages are imported (`import { m }` vs. `import * as m`), and on side-effect analysis. If you pick Paraglide for its size, open your bundle visualiser and check that it holds in your app.
+
+## No Dynamic Loading
+
+This is the structural limit. Paraglide has no way to load one locale at a time: every message function statically imports the implementation of each locale, so every locale ends up in your client bundle.
+
+With 2 locales, that is half your translation payload wasted, which matches the ~50% locale leak measured above. With 10 locales, 90% of it. With 30 locales, 97%.
+
+Moving to dynamic loading would not fix it either: with one function per message, loading each one lazily would mean thousands of requests.
+
+Intlayer lets you choose, globally or per dictionary:
+
+```ts fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+
+const config: IntlayerConfig = {
+  internationalisation: {
+    locales: [Locales.ENGLISH, Locales.FRENCH, Locales.SPANISH],
+    defaultLocale: Locales.ENGLISH,
+  },
+  dictionary: {
+    importMode: "dynamic", // 'static' | 'dynamic' | 'fetch'
+  },
+};
+
+export default config;
+```
+
+| `importMode` | What ships to the client                                | vs. Paraglide                      |
+| ------------ | ------------------------------------------------------- | ---------------------------------- |
+| `static`     | All locales of the dictionaries the page uses           | Theoretically the same content     |
+| `dynamic`    | Only the current locale, lazy-loaded per dictionary     | **N times smaller** with N locales |
+| `fetch`      | Only the current locale, fetched from the Live Sync API | **N times smaller** with N locales |
+
+With the [build transformation](https://intlayer.org/en-GB/doc/concept/bundle-optimization) and `importMode: 'static'`, Intlayer loads, in theory, the exact same content as Paraglide. With `'dynamic'` or `'fetch'`, it loads only what the current locale needs: for an app in N locales, the translation payload is N times smaller than Paraglide's.
+
+## Where Paraglide Still Fits
+
+<AccordionGroup>
+<Accordion header="Svelte + Vite with few locales">
+
+If your stack is Svelte with Vite and you support two or three languages, tree shaking works as advertised and the locale overhead stays small.
+
+</Accordion>
+<Accordion header="Existing inlang workflow">
+
+If your team already uses the inlang ecosystem (Fink, Sherlock, message format plugins), Paraglide integrates with it natively.
+
+</Accordion>
+</AccordionGroup>
+
+## Try It on Your App
+
+Check your live application's payload and locale leakage with the free [i18n SEO Scanner](https://intlayer.org/i18n-seo-scanner):
+
+<ClickToOpenIframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+To set up Intlayer:
+
+```bash packageManager="npm"
+npx intlayer init --interactive
+```
+
+```bash packageManager="pnpm"
+pnpm dlx intlayer init --interactive
+```
+
+```bash packageManager="yarn"
+yarn dlx intlayer init --interactive
+```
+
+```bash packageManager="bun"
+bunx intlayer init --interactive
+```
+
+## Further Reading
+
+- [TanStack Start i18n Benchmark](https://intlayer.org/en-GB/doc/benchmark/tanstack)
+- [Next.js i18n Benchmark](https://intlayer.org/en-GB/doc/benchmark/nextjs)
+- [Bundle Optimisation and `importMode`](https://intlayer.org/en-GB/doc/concept/bundle-optimization)
+- [How to Pick a React i18n Library](https://intlayer.org/en-GB/blog/how-to-pick-react-i18n-library)
+- [The Case for Compiler-Driven Internationalisation](https://intlayer.org/en-GB/blog/compiler-vs-declarative-i18n)