i18next VS Intlayer: React & Next.js Internationalisierungs-Benchmark (i18n)

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, einer Open-Source-Suite, die dieselbe Anwendung mit jeder Bibliothek erstellt und misst, was der Browser tatsächlich herunterlädt.

tl;dr: i18next ist die schwerste Runtime im Benchmark: +77 KB gzip pro Seite auf Next.js im Standard-Setup (naiv), +22 KB nach vollständiger Namespace- und Lazy-Loading-Optimierung. Intlayer fügt lediglich +0.3 KB hinzu. Jede i18next-Konfiguration mit Ausnahme der vollständig isolierten (scoped) liefert ~90% Zeichenketten fremder Seiten aus; Intlayer liefert standardmäßig 0% aus. Der Sprachwechsel mit einem dynamisch nachgeladenen Backend dauerte 123-185 ms mit react-i18next gegenüber 3-4 ms mit Intlayer. Der Adapter @intlayer/next-i18next behält die i18next-API bei und erzielte 150.7 KB pro Seite gegenüber 218.5 KB für das Original.

Kurz zusammengefasst

• i18next / react-i18next / next-i18next - Ausgereift, pluginreich, framework-agnostisch. Namespaces, Spracherkenner, Backends, ICU über Plugins, <Trans> für Rich Content. Inhalte sind zentral in locales/{lng}/{ns}.json organisiert. Mächtig, aber jede Optimierung (Namespace-Aufteilung, seitenweises Laden, Typsicherheit) ist Konfigurationsaufwand, den Sie selbst verwalten müssen.
• Intlayer - Komponentenzentriertes Inhaltsmodell. .content.ts-Wörterbücher liegen direkt neben der jeweiligen Komponente, ein Build-Time-Compiler übernimmt Tree-Shaking und Lazy Loading pro Komponente und Sprache, strikte TypeScript-Typen werden aus den Inhalten generiert und fehlende Übersetzungen führen zu Build-Fehlern. Bietet Middleware, SEO-Helfer, einen visuellen Editor / CMS und KI-gestützte Übersetzung.

Alle Tabellendaten anzeigen

Alle Tabellendaten anzeigen

Tabelle in einem Modal öffnen, um alle Daten übersichtlich anzuzeigen

Bibliothek	GitHub-Sterne	Commits insgesamt	Letzter Commit	Erste Version	NPM-Version	NPM-Downloads
aymericzip/intlayer				April 2024
i18next/i18next				Jan 2012
i18next/react-i18next				Dez 2015
i18next/next-i18next				Nov 2018

Badges aktualisieren sich automatisch. Snapshots variieren im Zeitverlauf.

Direkter Funktionsvergleich

Der Benchmark

Was gemessen wurde

Die Benchmark Bloom-Suite erstellt dieselbe Anwendung mit jeder Bibliothek: 10 Seiten (Startseite, Über uns, Blog, Karriere, Kontakt, FAQ, Preise, Produkte, Einstellungen, Team), 10 Sprachen (en, fr, es, de, it, pt, zh, ja, ko, ru), identische Komponenten und identische Inhalte. Die Seiten werden in en und fr gemessen. Jede Bibliothek wird in bis zu vier Ladestrategien implementiert:

Intlayer benötigt keine "scoped"-Variante: Der Compiler grenzt den Inhalt automatisch pro Komponente ein, sodass bereits die Zeilen static und dynamic optimiert sind.

Für jeden Build erfasst die Suite:

• Lib size: gzip-Größe einer leeren Komponente, die nur die i18n-Bibliothek importiert.
• Page JS: gzip-JavaScript pro Seite heruntergeladen, gemittelt über alle Seiten und Sprachen.
• Locale leak %: Anteil der übersetzten Zeichenketten im JS, die zu einer Sprache gehören, die der Nutzer nicht betrachtet.
• Page leak %: Anteil der übersetzten Zeichenketten im JS, die zu einer Seite gehören, auf der sich der Nutzer nicht befindet.
• Component avg: durchschnittliche gzip-Größe jeder isoliert kompilierten Komponente.
• E2E reactivity: gemessene Zeitspanne zwischen Sprachauswahl und Aktualisierung von html[lang] im DOM (Playwright, 5 Iterationen).
• Hydration: Dauer der React-Hydratisierungsphase.

Die nachfolgenden Werte stammen aus dem Durchlauf vom 2026-09-12 mit next-i18next 16.3.0, react-i18next 17.0.13 und intlayer 9.5.1. Die Testanwendung ist bewusst kompakt gehalten (einige Dutzend Strings pro Sprache), daher spiegeln die Leckage-Werte ein Muster wider: Sie wachsen proportional zu Ihrem Inhalt, während die Runtime-Kosten konstant bleiben.

Ergebnisse auf Next.js (next-i18next)

Wählen Sie die Metriken und Bibliotheken aus, die für Sie wichtig sind:

Interpretation der Messwerte

• Runtime-Kosten. Der i18next-Core samt react-i18next ist die größte gemessene Runtime: 19.7 KB gzip für eine leere Komponente gegenüber 5.5 KB bei next-intlayer.
• Das Standard-Setup ist kostspielig. Das direkte Einbetten von resources in init() führt zu 218.5 KB pro Seite, +77.5 KB über der Basisanwendung. Jede Seite trägt sämtliche Namespaces mit.
• Optimierung erfordert viel Aufwand. Der Wechsel zu einem Backend (dynamic) spart 49 KB ein, lässt aber weiterhin 90% an Zeichenketten fremder Seiten durchsickern, und in dieser Konfiguration gehört die Hälfte der Strings zur falschen Sprache. Erst die zusätzliche Aufteilung in routenbasierte Namespaces (scoped-dynamic) eliminiert die Lecks vollständig bei 163.4 KB - immer noch +22.4 KB pro Seite mehr als Intlayer mit 141.3 KB, das ganz ohne manuelle Konfiguration auskam.
• 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.

Vollständige Tabelle, jede Bibliothek und jede Strategie, im Next.js-Benchmark-Bericht.

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.

Interpretation der Messwerte

• Die unoptimierte react-i18next-App liefert +69 KB pro Seite mehr als die Basisanwendung aus, und die Hydratisierung dauert 85 ms (das Vierfache der Basis), da der gesamte Ressourcenbaum vor dem ersten Rendern auf dem Client analysiert und registriert werden muss.
• Sprachwechsel macht Backend-Latenzen spürbar. Werden Ressourcen erst bei Bedarf geladen, erfordert der Sprachwechsel einen zusätzlichen Netzwerk-Roundtrip vor der html[lang]-Aktualisierung: 123 ms bei dynamic, 185 ms bei scoped-static. Intlayer aktualisiert das DOM in beiden Modi in 3-4 ms: Der Wechsel erfolgt sofort und blockiert nicht auf Netzwerkanfragen.
• Die voll optimierte scoped-dynamic-Konfiguration erreicht 0% Leckage bei 127.2 KB, liegt aber immer noch +8.6 KB über Intlayers dynamic-Zeile - und erforderte dafür eine Routen-zu-Namespace-Zuordnung, ein Backend und Suspense-Grenzen pro Route.
• 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.

Vollständige Tabelle im TanStack Start-Benchmark-Bericht.

Woher kommt der Unterschied? Globale Instanz vs. kompilierte Wörterbücher

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:

.
├── i18n.ts                      # createInstance().use(...).use(...).init({...})
└── src
    ├── locales
    │   ├── en
    │   │   ├── common.json
    │   │   ├── home.json
    │   │   └── about.json
    │   └── fr
    │       ├── common.json
    │       ├── home.json
    │       └── about.json
    ├── components
    │   └── Counter.tsx          # useTranslation("about") + t("counter.label")
    └── app
        └── [locale]
            └── about
                └── 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.

Die Rechnung wächst auf zwei Achsen gleichzeitig, Seiten und Sprachen:

Wie die Benchmark-Hinweise 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:

.
├── intlayer.config.ts
└── src
    ├── components
    │   └── Counter
    │       ├── index.tsx        # useIntlayer("counter")
    │       └── index.content.ts
    └── app
        └── [locale]
            └── about
                ├── page.tsx
                └── page.content.ts

@intlayer/swc / @intlayer/babel erkennt, welche Komponente welches Wörterbuch importiert, bündelt nur diese und nur für die aktive Sprache und verwirft Unbenutztes. Das "scoped-dynamic"-Muster ist das automatische Ergebnis des Builds und keine mühsame manuelle Disziplin mehr.

Um die Werte der dynamic-Zeile zu erhalten, setzen Sie dictionary.importMode: 'dynamic' in intlayer.config.ts. Details finden Sie in der Dokumentation zur Bundle-Optimierung.

Entwicklererfahrung

Einrichtung

import { createInstance } from "i18next";
import { initReactI18next } from "react-i18next/initReactI18next";
import resourcesToBackend from "i18next-resources-to-backend";
import { defaultLocale } from "@/i18n.config";

const backend = resourcesToBackend(
  (locale: string, namespace: string) =>
    import(`../../locales/${locale}/${namespace}.json`)
);

export const initI18next = async (
  locale: string,
  namespaces: string[] = ["common"]
) => {
  const i18n = createInstance();
  await i18n
    .use(initReactI18next)
    .use(backend)
    .init({
      lng: locale,
      fallbackLng: defaultLocale,
      ns: namespaces,
      defaultNS: "common",
      interpolation: { escapeValue: false },
      react: { useSuspense: false },
    });
  return i18n;
};

import { type IntlayerConfig, Locales } from "intlayer";

const config: IntlayerConfig = {
  internationalization: {
    locales: [Locales.ENGLISH, Locales.FRENCH],
    defaultLocale: Locales.ENGLISH,
  },
};

export default config;

import { getHTMLTextDir } from "intlayer";
import { IntlayerClientProvider, type NextLayoutIntlayer } from "next-intlayer";

const LocaleLayout: NextLayoutIntlayer = async ({ children, params }) => {
  const { locale } = await params;

  return (
    <html lang={locale} dir={getHTMLTextDir(locale)}>
      <body>
        <IntlayerClientProvider locale={locale}>
          {children}
        </IntlayerClientProvider>
      </body>
    </html>
  );
};

export default LocaleLayout;

Client-Komponente

{
  "counter": {
    "label": "Counter",
    "increment": "Increment"
  }
}

"use client";

import { useState } from "react";
import { useTranslation } from "react-i18next";

export const Counter = () => {
  const { t, i18n } = useTranslation("about");
  const [count, setCount] = useState(0);
  const numberFormat = new Intl.NumberFormat(i18n.language);

  return (
    <div>
      <p>{numberFormat.format(count)}</p>
      <button
        aria-label={t("counter.label")}
        onClick={() => setCount((c) => c + 1)}
      >
        {t("counter.increment")}
      </button>
    </div>
  );
};

import { t, type Dictionary } from "intlayer";

const counterContent = {
  key: "counter",
  content: {
    label: t({ en: "Counter", fr: "Compteur" }),
    increment: t({ en: "Increment", fr: "Incrémenter" }),
  },
} satisfies Dictionary;

export default counterContent;

"use client";

import { useState } from "react";
import { useIntlayer } from "next-intlayer";
import { useNumber } from "next-intlayer/format";

export const Counter = () => {
  const { label, increment } = useIntlayer("counter");
  const number = useNumber();
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>{number(count)}</p>
      <button aria-label={label} onClick={() => setCount((c) => c + 1)}>
        {increment}
      </button>
    </div>
  );
};

Synchrone Server-Komponente

type ServerCounterProps = {
  t: (key: string) => string;
  locale: string;
  count: number;
};

export const ServerCounter = ({ t, locale, count }: ServerCounterProps) => (
  <div>
    <p>{new Intl.NumberFormat(locale).format(count)}</p>
    <button aria-label={t("counter.label")}>{t("counter.increment")}</button>
  </div>
);

import { useIntlayer } from "next-intlayer/server";
import { useNumber } from "next-intlayer/server/format";

export const ServerCounter = ({ count }: { count: number }) => {
  const { label, increment } = useIntlayer("counter");
  const number = useNumber();

  return (
    <div>
      <p>{number(count)}</p>
      <button aria-label={label}>{increment}</button>
    </div>
  );
};

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.

import type { NextConfig } from "next";
import { createNextI18nPlugin } from "@intlayer/next-i18next/plugin";

const withIntlayer = createNextI18nPlugin();

const nextConfig: NextConfig = {};

export default withIntlayer(nextConfig);

import { defineConfig } from "vite";
import { reactI18nextVitePlugin } from "@intlayer/react-i18next/plugin";

export default defineConfig({
  plugins: [reactI18nextVitePlugin()],
});

Im Benchmark sank die angepasste Version derselben Next.js-Anwendung von 218.5 KB auf 150.7 KB pro Seite, von 78.5 KB auf 9.7 KB pro Komponente, von ~90% Inhaltslecks auf 0% und die Hydratisierung von 15.6 ms auf 11.3 ms - bei unverändertem Anwendungscode. Ihre bestehenden locales/{lng}/{ns}.json-Dateien können über das JSON-Sync-Plugin weiterhin die Source of Truth bleiben.

Siehe die Migrationsanleitungen: i18next, react-i18next, next-i18next.

Wann welche Lösung wählen?

FAQ

Verwandte Vergleiche

Gleicher Benchmark, andere Bibliotheken:

Mehr zu i18next:

Referenzdokumentation:

Kompatibilitätsadapter:

Migrationsleitfäden:

Um zu verstehen, woher diese Bibliotheken kommen, lesen Sie die Geschichte von i18n in JavaScript.

GitHub-Sterne

GitHub-Sterne sind ein aussagekräftiger Indikator für Popularität, Vertrauen der Community und Zukunftsfähigkeit eines Projekts. Sie messen zwar nicht direkt die Codequalität, zeigen aber, wie viele Entwickler das Projekt schätzen, verfolgen und einsetzen.

Commit-Aktivität

Sterne zeigen Popularität. Commits zeigen, wie viel Arbeit in einem Projekt steckt. Zum Zeitpunkt des Schreibens zählt Intlayer rund 7.500 Commits, mehr als die meisten hier verglichenen Bibliotheken und etwa 5-mal so viele wie next-intl oder next-i18next.

Intlayer ist ein Monorepo: Die Zahl umfasst jedes Framework-Paket, die CLI und die Dokumentation. Commits sind ein Signal für Aktivität, nicht für Qualität.

npm-Downloads

Downloads belohnen die ältesten Lösungen, nicht die besten. Eine vor Jahren veröffentlichte Bibliothek wird weiterhin von jedem Projekt installiert, das sie damals gewählt hat, von jedem CI-Lauf und von jedem Paket, das davon abhängt. Die Zahl misst Trägheit mehr als eine bewusste Wahl.

KI-Assistenten verstärken diesen Effekt. next-intl, i18next und vue-i18n sind im Code, mit dem sie trainiert wurden, allgegenwärtig, also schlagen sie diese standardmäßig vor, ohne Alternativen zu vergleichen. Jeder Vorschlag erzeugt Downloads, die den nächsten Vorschlag verstärken. Vergleichen Sie anhand des Benchmarks, nicht anhand der Downloadzahlen.

Fazit

i18next hat seinen Platz verdient: Es läuft überall, bietet Plugins für jeden Anwendungsfall und wird seit über zehn Jahren gepflegt. Der Benchmark verdeutlicht jedoch die Kosten dieser runtime-fokussierten Architektur. Das typische Setup kostet +70-77 KB gzip pro Seite, transportiert ~90% Daten fremder Seiten mit sich und benötigt bei Lazy Loading über 100 ms für einen Sprachwechsel. 0% Leckage ist machbar, erfordert aber ein Backend, getrennte Namespaces pro Route und manuelle Pflege - und bleibt dennoch +9-22 KB schwerer als Intlayer.

Intlayer verlagert diese Arbeit in den Compiler. Wörterbücher pro Komponente, Lazy Loading pro Sprache und das Bereinigen ungenutzter Inhalte sind Ergebnisse des Builds statt manueller Konventionen. Auf derselben Anwendung: +0.3 KB pro Seite, 0% Leckage, Komponenten 3 bis 10 Mal kleiner und Sprachwechsel in 3-4 ms.

Alle Rohdaten, Testanwendungen und Skripte stehen im Benchmark Bloom Repository bereit. Probieren Sie es selbst aus.

Weitere Details finden Sie in der Dokumentation 'Warum Intlayer?'.