@intlayer/docs 9.5.6 → 9.5.8

package/blog/de/i18next_vs_intlayer.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "i18next vs Intlayer: Benchmark & Vergleich 2026"
 description: "react-i18next und next-i18next im Benchmark gegen Intlayer auf Next.js und TanStack Start. Bundle-Größe, Inhaltslecks, Reaktivität beim Sprachwechsel und Entwicklererfahrung."
 keywords:
@@ -25,6 +25,8 @@ author: aymericzip
 
 # i18next VS Intlayer | React & Next.js Internationalisierungs-Benchmark (i18n)
 
+![i18next VS Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18next-next-intl-intlayer.webp?raw=true)
+
 `i18next` ist das am weitesten verbreitete i18n-Framework im JavaScript-Ökosystem. Über `react-i18next` und `next-i18next` betreibt es einen großen Teil der React- und Next.js-Anwendungen. Intlayer ist eine compilerbasierte, komponentenzentrierte Alternative.
 
 Dieser Artikel vergleicht beide anhand echter Messwerte anstelle von Feature-Listen. Die Zahlen stammen aus dem [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom), einer Open-Source-Suite, die dieselbe Anwendung mit jeder Bibliothek erstellt und misst, was der Browser tatsächlich herunterlädt.
@@ -99,6 +101,10 @@ Für jeden Build erfasst die Suite:
 
 ### Ergebnisse auf Next.js (`next-i18next`)
 
+Wählen Sie die Metriken und Bibliotheken aus, die für Sie wichtig sind:
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | Bibliothek                        | Strategie      | Lib size (gz) | Page JS avg (gz) | Locale leak | Page leak | Component avg (gz) | E2E-Reaktivität | Hydration |
 | --------------------------------- | -------------- | ------------: | ---------------: | ----------: | --------: | -----------------: | --------------: | --------: |
 | **base** (ohne i18n)              | -              |        0.0 KB |         141.0 KB |        0.0% |      0.0% |             0.9 KB |         13.4 ms |   11.8 ms |
@@ -119,6 +125,15 @@ Für jeden Build erfasst die Suite:
 - **Komponentengröße.** Eine Komponente mit `useTranslation()` kompiliert je nach Konfiguration auf 26 bis 79 KB; dieselbe Komponente mit `useIntlayer()` benötigt lediglich 6.9 KB.
 - **Die Hydratisierung** steigt im `dynamic`-Setup auf 27.7 ms an: Die i18next-Instanz initialisiert sich und löst ihr Backend auf dem Client auf, bevor React die Hydratisierung abschließen kann.
 
+<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;"
+/>
+
+> Vollständige Tabelle, jede Bibliothek und jede Strategie, im [Next.js-Benchmark-Bericht](https://intlayer.org/de/doc/benchmark/nextjs).
+
 ### Ergebnisse auf TanStack Start (`react-i18next`)
 
 Dieselbe Testanwendung auf TanStack Start mit reinem `react-i18next`, wodurch Next.js-spezifische Eigenheiten aus dem Vergleich herausgefiltert werden.
@@ -141,8 +156,19 @@ Dieselbe Testanwendung auf TanStack Start mit reinem `react-i18next`, wodurch Ne
 - Intlayers `static`-Zeile weist bereits **0% Seitenleckage** auf, weil ausschließlich die von den Komponenten der jeweiligen Seite importierten Wörterbücher gebündelt werden. Das Aktivieren von `importMode: 'dynamic'` eliminiert auch die Sprachleckage vollständig.
 - **Komponentengröße**: 24-27 KB pro Komponente mit `react-i18next` gegenüber 6-8 KB mit Intlayer. `useTranslation()` bindet jede Komponente an die globale i18next-Instanz.
 
+<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;"
+/>
+
+> Vollständige Tabelle im [TanStack Start-Benchmark-Bericht](https://intlayer.org/de/doc/benchmark/tanstack).
+
 ## Woher kommt der Unterschied? Globale Instanz vs. kompilierte Wörterbücher
 
+![Centralized catalogs versus per-component dictionaries](https://github.com/aymericzip/intlayer/blob/main/docs/assets/project_stucture_18n_vs_intlayer.png?raw=true)
+
 `i18next` wurde 2012 als Runtime konzipiert: Eine globale Instanz verwaltet einen Ressourcenspeicher, Plugins erweitern ihn und `t()` schlägt Schlüssel zur Renderzeit nach. Das macht es sehr flexibel (für jedes Framework, Backend und Format), führt aber auch zu Mehrgewicht:
 
 ```bash
@@ -166,7 +192,13 @@ Dieselbe Testanwendung auf TanStack Start mit reinem `react-i18next`, wodurch Ne
                 └── page.tsx     # muss wissen, dass es ["common", "about"] benötigt
 ```
 
-Die Instanz kann nicht wissen, welche Schlüssel eine Komponente anfordern wird. Optimierung bedeutet daher: **Sie** unterteilen Kataloge in Namespaces, **Sie** listen die Namespaces für jede Seite auf und **Sie** halten diese Liste synchron, wenn Komponenten verschoben werden. Wie die [Benchmark-Hinweise](https://github.com/intlayer-org/benchmark-bloom/blob/main/report/NOTE.md) festhalten: "Typsicherheit zu wahren und exakt zu wissen, welcher Namespace auf welcher Seite eingebunden werden muss, ist ein Albtraum".
+Die Instanz kann nicht wissen, welche Schlüssel eine Komponente anfordern wird. Optimierung bedeutet daher: **Sie** unterteilen Kataloge in Namespaces, **Sie** listen die Namespaces für jede Seite auf und **Sie** halten diese Liste synchron, wenn Komponenten verschoben werden.
+
+Die Rechnung wächst auf zwei Achsen gleichzeitig, Seiten und Sprachen:
+
+![Theoretical content leakage by architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
+
+Wie die [Benchmark-Hinweise](https://github.com/intlayer-org/benchmark-bloom/blob/main/report/NOTE.md) festhalten: "Typsicherheit zu wahren und exakt zu wissen, welcher Namespace auf welcher Seite eingebunden werden muss, ist ein Albtraum".
 
 Intlayer verzichtet auf die globale Instanz. Inhalte werden direkt bei der Komponente deklariert und der Compiler löst den Abhängigkeitsgraphen zur Build-Zeit auf:
 
@@ -193,7 +225,8 @@ Intlayer verzichtet auf die globale Instanz. Inhalte werden direkt bei der Kompo
 
 ### Einrichtung
 
-**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 (
 
 Dazu kommt ein clientseitiger `I18nProvider`, der die Instanz mit identischen Optionen instanziiert, `generateStaticParams` und eine `namespaces`-Liste auf jeder Seite.
 
-**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-Komponente
 
-**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 = () => {
 
 > Die Seite, die diese Komponente einbindet, muss den Namespace `about` laden, und `t("counter.label")` bleibt ein einfacher String, sofern `CustomTypeOptions` nicht erweitert wird.
 
-**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` und `increment` sind strikt typisiert; Tippfehler werden als TypeScript-Fehler gemeldet und fehlende Übersetzungen verhindern den Build.
 
+</Tab>
+</Tabs>
+
 ### Synchrone Server-Komponente
 
-**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) => (
 
 Die Seite ruft `i18n.getFixedT(locale, "about")` auf und reicht `t` und `locale` als Props nach unten weiter.
 
-**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>
+
 ## i18next-API behalten, Intlayer-Performance nutzen
 
 Sie müssen keine Komponenten neu schreiben, um von den Benchmark-Ergebnissen zu profitieren. `@intlayer/i18next`, `@intlayer/react-i18next` und `@intlayer/next-i18next` sind Drop-in-Adapter: `useTranslation`, `t()`, `<Trans>`, `{{interpolation}}`, `_one` / `_other`-Plurale, Kontext-Suffixe und `returnObjects` funktionieren weiterhin, bereitgestellt aus vorkompilierten Intlayer-Wörterbüchern.
@@ -415,18 +462,85 @@ Siehe die Migrationsanleitungen: [i18next](https://intlayer.org/de/doc/migration
 
 ## Wann welche Lösung wählen?
 
-- **Wählen Sie i18next**, wenn Sie dessen Plugin-Ökosystem (Detektoren, Backends, ICU, Locize) benötigen, Lokalisierung auch außerhalb von React stattfindet (Node-Dienste, Vanilla JS, andere Frameworks), Ihr Team bereits damit vertraut ist oder Übersetzungsplattformen `locales/{lng}/{ns}.json` erwarten. Planen Sie die Zeit ein, um Kataloge in Namespaces aufzuteilen, ein Backend einzubinden und das Seiten-Mapping manuell zu pflegen.
-- **Wählen Sie Intlayer**, wenn Sie **komponentenzentrierte Inhalte**, **strikte TypeScript-Typen**, **Build-Time-Fehler bei fehlenden Übersetzungen**, **automatisiertes Tree-Shaking und Lazy Loading**, sofortige Sprachwechsel, synchrone Server-Komponenten und integrierte redaktionelle Werkzeuge (visueller Editor, CMS, KI-Übersetzung, MCP-Server) wünschen. Besonders wertvoll für modulare Codebases und Design-Systeme.
-- **Wählen Sie die `@intlayer/*-i18next`-Adapter**, wenn Sie bereits auf i18next setzen und die Bundle- sowie Reaktivitätsgewinne ohne Refactoring realisieren möchten.
+<AccordionGroup>
+<Accordion header="i18next wählen">
+
+Wenn Sie dessen Plugin-Ökosystem (Detektoren, Backends, ICU, Locize) benötigen, Lokalisierung auch außerhalb von React stattfindet (Node-Dienste, Vanilla JS, andere Frameworks), Ihr Team bereits damit vertraut ist oder Übersetzungsplattformen `locales/{lng}/{ns}.json` erwarten. Planen Sie die Zeit ein, um Kataloge in Namespaces aufzuteilen, ein Backend einzubinden und das Seiten-Mapping manuell zu pflegen.
+
+</Accordion>
+<Accordion header="Intlayer wählen">
+
+Sie möchten **komponentenbezogene Inhalte**, **striktes TypeScript**, **Fehler bei fehlenden Schlüsseln zur Build-Zeit**, **müheloses Tree-Shaking und Lazy Loading**, sofortiges Umschalten der Sprache, synchrone Serverkomponenten und integrierte Redaktionswerkzeuge ([Visueller Editor](https://intlayer.org/de/doc/concept/editor), [CMS](https://intlayer.org/de/doc/concept/cms), [KI-Übersetzung](https://intlayer.org/de/doc/concept/auto-fill), [MCP-Server](https://intlayer.org/de/doc/mcp-server)). Besonders relevant für große, modulare Codebasen und Design-Systeme.
+
+</Accordion>
+<Accordion header="@intlayer/*-i18next-Adapter wählen">
+
+Sie nutzen bereits i18next und möchten die Bundle- und Reaktivitätsgewinne ohne Umschreiben nutzen. Ihre `locales/{lng}/{ns}.json`-Dateien bleiben die Quelle der Wahrheit. Direkt verglichen in [i18next vs @intlayer/i18next](https://intlayer.org/de/blog/i18next-vs-intlayer-i18next).
+
+</Accordion>
+</AccordionGroup>
+
+## FAQ
+
+<FAQ>
+
+<Question title="Warum ist i18next so viel schwerer als die anderen Bibliotheken?">
+
+Es wurde als Framework-agnostische Laufzeitumgebung konzipiert: eine globale Instanz, eine Plugin-Pipeline, ein Ressourcenspeicher, ein Schlüssel-Resolver. Diese Flexibilität wird in jedes Bundle kompiliert. Eine leere Komponente, die nur die Bibliothek importiert, kostet **19.7 KB gzip** mit `next-i18next` gegenüber **5.5 KB** mit `next-intlayer`, und diese Kosten fallen auf jeder Seite an, unabhängig vom Inhalt.
+
+</Question>
+
+<Question title="Löst Lazy Loading mit einem Backend das Problem?">
+
+Es spart Bytes, verringert aber nicht die Latenz. Der Wechsel zu `i18next-resources-to-backend` spart ~49 KB pro Seite, fügt aber beim Sprachwechsel einen Netzwerk-Roundtrip hinzu: **123 ms** im `dynamic`-Setup und **185 ms** in `scoped-static`, gegenüber **3-4 ms** bei Intlayer. Die Hydratisierung steigt ebenfalls auf 27.7 ms, da die Instanz ihr Backend auflöst, bevor React hydratisieren kann.
+
+</Question>
+
+<Question title="Kann ich mit i18next 0% Leakage erreichen?">
+
+Ja, mit `scoped-dynamic`: ein Namespace pro Route, ein Ressourcen-Backend und eine manuell gepflegte Zuordnung von Seiten zu Namespaces. Das landet bei 163.4 KB pro Seite auf Next.js, immer noch **+22 KB** über den 141.3 KB von Intlayer, das keine Konfiguration benötigte. Siehe [Bundle-Optimierung](https://intlayer.org/de/doc/concept/bundle-optimization).
+
+</Question>
+
+<Question title="Muss ich meine Komponenten für die Migration umschreiben?">
+
+Nein. `@intlayer/i18next`, `@intlayer/react-i18next` und `@intlayer/next-i18next` behalten `useTranslation`, `t()`, `<Trans>`, `{{interpolation}}`, `_one` / `_other`-Plurale, Kontext-Suffixe und `returnObjects` bei. Eine einzige Plugin-Zeile in `next.config.ts` oder `vite.config.ts`. Schritt für Schritt im [next-i18next-Migrationsleitfaden](https://intlayer.org/de/doc/migration/next-i18next).
+
+</Question>
+
+<Question title="Was passiert mit meinen i18next-Plugins?">
+
+Backends und Spracherkenner werden akzeptiert, bleiben aber wirkungslos: Es gibt zur Laufzeit nichts mehr zu laden oder zu erkennen. Die Spracherkennung wird zur Routing-Konfiguration von Intlayer (URL-Präfix, Cookie, Header). Wenn Ihre App Übersetzungen zur Laufzeit von einem CMS abruft, nutzen Sie stattdessen das [Intlayer CMS](https://intlayer.org/de/doc/concept/cms) oder `intlayer pull` / `push`.
+
+</Question>
+
+</FAQ>
 
 ## Verwandte Vergleiche
 
-- [next-intl vs Intlayer](https://intlayer.org/de/blog/next-intl-vs-intlayer) (gleicher Benchmark)
-- [Lingui vs Intlayer](https://intlayer.org/de/blog/lingui-vs-intlayer) (gleicher Benchmark)
-- [vue-i18n vs Intlayer Benchmark](https://intlayer.org/de/blog/vue-i18n-vs-intlayer-benchmark) (gleicher Benchmark)
+Gleicher Benchmark, andere Bibliotheken:
+
+- [next-intl vs Intlayer](https://intlayer.org/de/blog/next-intl-vs-intlayer)
+- [Lingui vs Intlayer](https://intlayer.org/de/blog/lingui-vs-intlayer)
+- [vue-i18n vs Intlayer benchmark](https://intlayer.org/de/blog/vue-i18n-vs-intlayer-benchmark)
 - [next-i18next vs next-intl vs Intlayer](https://intlayer.org/de/blog/next-i18next-vs-next-intl-vs-intlayer)
 - [react-i18next vs react-intl vs Intlayer](https://intlayer.org/de/blog/react-i18next-vs-react-intl-vs-intlayer)
+
+Mehr zu i18next:
+
+- [i18next vs @intlayer/i18next](https://intlayer.org/de/blog/i18next-vs-intlayer-i18next), die Adapter auf derselben App gemessen
 - [Ist i18next veraltet?](https://intlayer.org/de/blog/is-i18next-outdated)
+- [Intlayer mit i18next nutzen](https://intlayer.org/de/blog/intlayer-with-i18next) und [mit react-i18next](https://intlayer.org/de/blog/intlayer-with-react-i18next)
+- [Wie man eine Next.js-App mit next-i18next internationalisiert](https://intlayer.org/de/blog/nextjs-internationalization-using-next-i18next)
+
+Referenzdokumentation:
+
+- [Next.js-Benchmark-Bericht](https://intlayer.org/de/doc/benchmark/nextjs) und [TanStack Start-Benchmark-Bericht](https://intlayer.org/de/doc/benchmark/tanstack)
+- Kompatibilitätsadapter: [i18next](https://intlayer.org/de/doc/compatibility/i18next), [react-i18next](https://intlayer.org/de/doc/compatibility/react-i18next), [next-i18next](https://intlayer.org/de/doc/compatibility/next-i18next)
+- Migrationsleitfäden: [i18next](https://intlayer.org/de/doc/migration/i18next), [react-i18next](https://intlayer.org/de/doc/migration/react-i18next), [next-i18next](https://intlayer.org/de/doc/migration/next-i18next)
+- [Bundle-Optimierung](https://intlayer.org/de/doc/concept/bundle-optimization) und [der Intlayer-Compiler](https://intlayer.org/de/doc/compiler)
+- [Komponentenbezogene vs. zentrale i18n](https://intlayer.org/de/blog/per-component-vs-centralized-i18n)
+- [Compiler-gesteuerte vs. deklarative i18n](https://intlayer.org/de/blog/compiler-vs-declarative-i18n)
 
 ## GitHub-Sterne
 

package/blog/de/is_intlayer_lighter_than_paraglide.md

@@ -0,0 +1,284 @@
+---
+createdAt: 2026-09-23
+updatedAt: 2026-09-23
+title: Ist Intlayer leichter als Paraglide?
+description: Paraglide wirkt in i18n-Benchmarks nahezu kostenlos, da der Code direkt in Ihr Repository generiert wird. Hier erfahren Sie, wo dieses Gewicht wirklich landet, warum Locale-Abfragen pro Knoten Leistung kosten und wie Intlayers dynamisches Laden nur eine einzige Locale statt aller ausliefert.
+keywords:
+  - Paraglide
+  - Intlayer
+  - Internationalisierung
+  - i18n
+  - Bundle size
+  - Tree shaking
+  - Benchmark
+  - Blog
+slugs:
+  - blog
+  - is-intlayer-lighter-than-paraglide
+author: aymericzip
+---
+
+# Ist Intlayer leichter als Paraglide?
+
+Ja.
+
+`Paraglide` genießt den Ruf, die leichteste i18n-Lösung auf dem Markt zu sein, und auf den ersten Blick bestätigt der [Benchmark](https://intlayer.org/de/doc/benchmark/tanstack) diesen Eindruck: Die Bibliotheksgröße liegt nahe bei null. Doch eine Bibliotheksgröße von null bedeutet keineswegs null ausgelieferte Bytes. Es bedeutet lediglich, dass die Bytes an einer Stelle liegen, die diese Metrik nicht erfasst.
+
+<TOC/>
+
+## Wichtigste Erkenntnisse
+
+**Die Bibliotheksgröße ist versteckt, nicht verschwunden:**
+
+Paraglide generiert seine Runtime und Nachrichtenfunktionen direkt in Ihre Codebase. Dieser Code wird an den Browser ausgeliefert, wird aber als _Ihr_ Code gewertet und nicht als der Code der Bibliothek.
+
+**Kein Provider bedeutet keinen kostenlosen Gewinn:**
+
+Jeder Aufruf von `m.my_key()` ermittelt die Locale eigenständig und liest bei jedem gerenderten Knoten das Cookie oder den Storage aus, anstatt den Wert einmalig aus einem Kontext zu beziehen.
+
+**Kein dynamisches Laden:**
+
+Paraglide importiert jede Locale einer Nachricht in Ihr Client-Bundle. Intlayer mit `importMode: 'dynamic'` oder `'fetch'` lädt ausschließlich die Locale, die gerade gerendert wird.
+
+**Tree Shaking ist nicht garantiert:**
+
+In einigen unserer Benchmarks griff das von Paraglide beworbene Tree Shaking nicht. Prüfen Sie Ihr eigenes Bundle.
+
+## Wo landet das Gewicht von Paraglide?
+
+In den Benchmark-Berichten misst die Metrik „Bibliotheksgröße“ den Provider und die Hooks jeder i18n-Bibliothek in einer leeren Komponente, bevor Inhalte hinzugefügt werden.
+
+| Bibliothek (TanStack Start)   | Lib-Größe (gz) | Lib-Größe (min) |
+| ----------------------------- | -------------- | --------------- |
+| `@inlang/paraglide-js@2.15.1` | 1.8 KB         | 4.5 KB          |
+| `react-intlayer@9.5.1`        | 5.0 KB         | 15.2 KB         |
+
+Isoliert betrachtet gewinnt Paraglide. Aber Paraglide ist ein Compiler: Es liest Ihre `messages/*.json`-Dateien und schreibt einen `paraglide/`-Ordner in Ihr Repository, der eine `runtime.js` (Locale-Erkennung, Cookie- und Storage-Strategien, URL-Lokalisierung) sowie eine JavaScript-Funktion pro Nachricht enthält.
+
+```bash
+src/paraglide/
+├── runtime.js      # Locale-Erkennung, Strategien, URL-Hilfsfunktionen
+├── server.js
+├── messages.js     # Reexportiert alle Nachrichten
+└── messages/
+    ├── _index.js
+    ├── en.js
+    └── fr.js
+```
+
+Da dieser Code in Ihrem `src/`-Ordner liegt und mit einem relativen Pfad importiert wird, rechnet der Bundler ihn Ihrer Anwendung zu und nicht einem Paket in `node_modules`. Die Spalte für die Bibliotheksgröße zeigt fast nichts an, während dieselbe Logik weiterhin im Bundle Ihrer Seite ausgeliefert wird.
+
+Code zu generieren ist an sich keine schlechte Idee: Die generierte Runtime enthält nur die Logik, die Ihre Konfiguration tatsächlich benötigt (Präfix-Strategie, Cookie vs. Local Storage usw.). Intlayer erreicht dasselbe Ergebnis auf andere Weise, indem zur Build-Zeit Umgebungsvariablen injiziert werden, sodass der Bundler Zweige entfernt, die Ihre Konfiguration nicht nutzt. Beide Ansätze sind letztlich 3- bis 10-mal leichter als `i18next` oder `next-intl`.
+
+Der faire Vergleich ist daher nicht die Bibliotheksgröße. Es ist **das tatsächlich pro Seite übertragene JavaScript**.
+
+## Gemessenes Seitengewicht
+
+TanStack Start App, 10 Seiten, gemessen auf den Routen `en` und `fr`, gzippt:
+
+| Setup                              | Seiten-JS Ø (gz) | Über Basis  | Locale-Leak | Leak anderer Seiten |
+| ---------------------------------- | ---------------- | ----------- | ----------- | ------------------- |
+| Basis (ohne i18n)                  | 111.0 KB         | -           | 0.0%        | 0.0%                |
+| `paraglide` (jede Strategie)       | 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, dieselbe Anwendung:
+
+| Setup             | Seiten-JS Ø (gz) | Über Basis  |
+| ----------------- | ---------------- | ----------- |
+| Basis (ohne i18n) | 141.0 KB         | -           |
+| `paraglide-next`  | 155.3 KB         | +14.3 KB    |
+| `next-intlayer`   | **141.3 KB**     | **+0.3 KB** |
+
+<I18nBenchmark framework="tanstack" vertical/>
+
+> Vollständige Daten im [TanStack Start Benchmark-Bericht](https://intlayer.org/de/doc/benchmark/tanstack) und im [Next.js Benchmark-Bericht](https://intlayer.org/de/doc/benchmark/nextjs). Jedes Bundle kann im [Benchmark-Repository](https://github.com/intlayer-org/benchmark-i18n) eingesehen werden.
+
+Zwei Aspekte stechen hervor:
+
+- Im `static`-Modus liefert Intlayer praktisch denselben Inhalt wie Paraglide aus (125.8 KB vs. 125.1 KB). Das ist zu erwarten: Beide enthalten jede Locale der Nachrichten, die eine Seite verwendet.
+- Paraglide verharrt unabhängig von der Strategie bei 125.1 KB, da es keinen dynamischen Modus bietet. Jede Zeile in der obigen Tabelle entspricht der statischen Variante.
+
+## Kein Provider: Eine vermeintlich gute Idee
+
+Paraglide kommt ohne Provider aus. Sie importieren eine Nachricht und rufen sie direkt auf:
+
+```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>
+);
+```
+
+Kein Kontext, kein Wrapper, kein Hook. Das wirkt unkompliziert. Doch die Locale muss dennoch ermittelt werden. Jede generierte Nachrichtenfunktion sieht vereinfacht etwa so aus:
+
+```js fileName="paraglide/messages/_index.js"
+export const hero_title = (inputs = {}, options = {}) => {
+  const locale = options.locale ?? getLocale(); // wird bei jedem Aufruf ermittelt
+
+  if (locale === "en") return en.hero_title(inputs);
+  if (locale === "fr") return fr.hero_title(inputs);
+  // ...ein Zweig pro Locale
+};
+```
+
+Und `getLocale()` durchläuft die konfigurierten Strategien (Cookie, Local Storage, URL, Basis-Locale), um die aktuelle Locale zu bestimmen. Jeder gerenderte Textknoten (`<>{m.my_key()}</>`) führt also seine eigene Locale-Auflösung aus, einschließlich des Auslesens von `document.cookie` im Browser. Eine Seite mit 200 übersetzten Zeichenfolgen ermittelt die Locale 200 Mal pro Rendervorgang und erneut bei jedem Re-Render.
+
+Eine providerbasierte Bibliothek liest die Locale **ein einziges Mal** aus, speichert sie in einem Kontext (oder Signal bzw. Store), und jeder Knoten liest einen bereits im Speicher vorhandenen Wert. Der Provider kostet wenige hundert Bytes. Ihn wegzulassen kostet CPU-Leistung bei jedem Render. Das spiegelt sich im Benchmark wider: Paraglides Seitenlade- und Sprachwechselzeiten liegen auf TanStack Start durchweg hinter Intlayer (22.1 ms vs. 14.6 ms beim Seitenaufbau, 4.3 ms vs. 3.2 ms bei der E2E-Reaktivität).
+
+## Entwicklererlebnis (DX)
+
+Die Source of Truth von Paraglide ist JSON, aber Sie importieren die JSON-Dateien nie direkt. Stattdessen importieren Sie die generierte `.js`-Datei:
+
+<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/de.json"
+{
+  "hero_title": "Veröffentlichen Sie Ihre App in jeder Sprache"
+}
+```
+
+```tsx fileName="Hero.tsx"
+// Existiert erst, nachdem der Compiler die Datei aus dem JSON neu generiert hat
+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({
+      de: "Veröffentlichen Sie Ihre App in jeder Sprache",
+      en: "Ship your app in every language",
+    }),
+  },
+} satisfies Dictionary;
+```
+
+```tsx fileName="Hero.tsx"
+import { useIntlayer } from "react-intlayer";
+
+export const Hero = () => {
+  const { title } = useIntlayer("hero");
+
+  return <h1>{title}</h1>;
+};
+```
+
+  </Tab>
+</Tabs>
+
+Dieser Workflow bringt Nachteile mit sich:
+
+- Jede Änderung an einer JSON-Datei erfordert eine Neugenerierung, bevor der Import aufgelöst werden kann oder Typen aktualisiert werden.
+- Der generierte `paraglide/`-Ordner wird entweder committed (was Merge-Konflikte in generierten Dateien bei jedem Text-PR bedeutet) oder ignoriert (was einen Generierungsschritt vor jedem Type-Check, Test und CI-Job erfordert).
+- Jede Zeichenkette wird zu einem Funktionsaufruf. Konstanten werden überall zu `m.key()`, selbst an Stellen, an denen ein einfacher Wert genügen würde.
+
+## Tree Shaking: Überprüfen Sie Ihr Bundle
+
+Paraglides zentrales Versprechen lautet, dass ungenutzte Nachrichten per Tree Shaking entfernt werden, da jede Nachricht ein eigener Export ist. Im Benchmark mit Svelte + Vite funktioniert das wie beworben.
+
+In anderen Konfigurationen funktionierte es nicht. In unserem [Next.js](https://intlayer.org/de/doc/benchmark/nextjs)-Lauf wiegen Paraglides Seiten 14 KB mehr als die Basisanwendung, während `next-intlayer` lediglich 0.3 KB hinzufügt. Frühere Durchläufe auf TanStack Start zeigten zudem, dass Nachrichten anderer Seiten im Bundle der Route landeten.
+
+Tree Shaking hängt von Ihrem Bundler (Turbopack, Rolldown, Rollup), der Import-Syntax (`import { m }` vs. `import * as m`) und der Side-Effect-Analyse ab. Wenn Sie Paraglide wegen seiner Größe wählen, öffnen Sie Ihren Bundle-Visualizer und überprüfen Sie, ob das Versprechen in Ihrer Anwendung greift.
+
+## Kein dynamisches Laden
+
+Hier liegt die strukturelle Grenze. Paraglide bietet keine Möglichkeit, nur eine Locale auf einmal zu laden: Jede Nachrichtenfunktion importiert statisch die Implementierung jeder Sprache, sodass alle Sprachen im Client-Bundle landen.
+
+Bei 2 Sprachen wird die Hälfte der Übersetzungsdaten verschwendet, was den oben gemessenen ~50% Locale-Leak entspricht. Bei 10 Sprachen sind es 90%. Bei 30 Sprachen 97%.
+
+Der Wechsel zu dynamischem Laden würde das Problem nicht beheben: Bei einer Funktion pro Nachricht würde das verzögerte Laden jeder einzelnen Funktion tausende Anfragen bedeuten.
+
+Intlayer lässt Ihnen die Wahl, global oder pro Wörterbuch:
+
+```ts fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH, Locales.SPANISH],
+    defaultLocale: Locales.ENGLISH,
+  },
+  dictionary: {
+    importMode: "dynamic", // 'static' | 'dynamic' | 'fetch'
+  },
+};
+
+export default config;
+```
+
+| `importMode` | Was an den Client ausgeliefert wird                     | vs. Paraglide                   |
+| ------------ | ------------------------------------------------------- | ------------------------------- |
+| `static`     | Alle Locales der Wörterbücher, die die Seite verwendet  | Theoretisch derselbe Inhalt     |
+| `dynamic`    | Nur die aktuelle Locale, Lazy-Loading pro Wörterbuch    | **N-mal kleiner** bei N Locales |
+| `fetch`      | Nur die aktuelle Locale, bezogen über die Live Sync API | **N-mal kleiner** bei N Locales |
+
+Mit der [Build-Transformation](https://intlayer.org/de/doc/concept/bundle-optimization) und `importMode: 'static'` lädt Intlayer in der Theorie exakt denselben Inhalt wie Paraglide. Mit `'dynamic'` oder `'fetch'` lädt es nur das, was die aktuelle Locale benötigt: Bei einer App in N Sprachen ist die Übersetzungs-Nutzlast um den Faktor N kleiner als bei Paraglide.
+
+## Wann Paraglide weiterhin passt
+
+<AccordionGroup>
+<Accordion header="Svelte + Vite mit wenigen Locales">
+
+Wenn Ihr Stack auf Svelte mit Vite basiert und Sie zwei oder drei Sprachen unterstützen, funktioniert Tree Shaking wie beworben und der Overhead durch zusätzliche Sprachen bleibt gering.
+
+</Accordion>
+<Accordion header="Bestehender inlang-Workflow">
+
+Wenn Ihr Team bereits das inlang-Ökosystem nutzt (Fink, Sherlock, Message-Format-Plugins), lässt sich Paraglide nahtlos integrieren.
+
+</Accordion>
+</AccordionGroup>
+
+## Testen Sie es in Ihrer Anwendung
+
+Prüfen Sie Bundle-Größe und Locale-Leaks Ihrer Live-Anwendung mit dem kostenlosen [i18n SEO Scanner](https://intlayer.org/i18n-seo-scanner):
+
+<ClickToOpenIframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+So richten Sie Intlayer ein:
+
+```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
+```
+
+## Weiterführende Literatur
+
+- [TanStack Start i18n Benchmark](https://intlayer.org/de/doc/benchmark/tanstack)
+- [Next.js i18n Benchmark](https://intlayer.org/de/doc/benchmark/nextjs)
+- [Bundle-Optimierung und `importMode`](https://intlayer.org/de/doc/concept/bundle-optimization)
+- [So wählen Sie eine React i18n-Bibliothek aus](https://intlayer.org/de/blog/how-to-pick-react-i18n-library)
+- [Plädoyer für compilergestützte Internationalisierung](https://intlayer.org/de/blog/compiler-vs-declarative-i18n)