next-intl VS Intlayer | Next.js Internationalisierung (i18n) Benchmark

next-intl ist die beliebteste i18n-Bibliothek für Next.js. Intlayer ist eine compiler-basierte, component-scoped Alternative. Beide lokalisieren eine App Router-Anwendung. Die Frage ist, was jede Bibliothek kostet, sobald die App erstellt ist.

Dieser Artikel ist kein Tutorial. Es ist ein Vergleich, der durch Zahlen aus Benchmark Bloom gestützt wird, einer Open-Source-Benchmark-Suite, die die gleiche Anwendung mit jeder Bibliothek erstellt und misst, was der Browser tatsächlich herunterlädt und ausführt.

tl;dr: In derselben Next.js-App fügt next-intl auf jeder Seite +12,6 KB gzip JavaScript hinzu, versus +0,3 KB für Intlayer. Ohne zusätzlichen Aufwand liefert next-intl ~90% der Strings von Fremdsprachen-Seiten mit jeder Seite mit. Um 0% Speicherlecks mit next-intl zu erreichen, ist Namespace-Scoping und per-Seite pick(messages, [...]) erforderlich. Intlayer erreicht 0% standardmäßig, da sein Compiler Inhalte pro Komponente scopet. Wenn Sie die next-intl-API mit Intlayers Ausgabe möchten, zeigte der @intlayer/next-intl-Adapter 147,5 KB pro Seite versus 153,6 KB mit dem Original.

Kurz gesagt

• next-intl - Leichtgewichtig, gut dokumentiert, ICU-Nachrichtenformat, First-Class-App-Router-Unterstützung mit Middleware, Formattern und Navigations-Helfern. Inhalte befinden sich in zentralisierten JSON-Katalogen; Leistungsoptimierungen (Namespaces, Message-Picking pro Seite, Lazy Loading) sind deine Verantwortung.
• Intlayer - Komponentenzentriertes Inhaltsmodell. .content.ts-Wörterbücher befinden sich neben der Komponente, der sie dienen. Ein Build-Time-Compiler führt Tree-Shaking durch und lazy-loaded sie pro Komponente und pro Locale. Strikte TypeScript-Typen werden aus deinen Inhalten generiert, und fehlende Übersetzungen schlagen zur Build-Zeit fehl. Wird mit Middleware, SEO-Helfern, einem Visual Editor / CMS und KI-gestützter Übersetzung ausgeliefert.

Alle Tabellendaten anzeigen

Alle Tabellendaten anzeigen

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

Bibliothek	GitHub Stars	Gesamte Commits	Letzter Commit	Erste Version	NPM Version	NPM Downloads
aymericzip/intlayer				April 2024
amannn/next-intl				Nov 2020

Badges werden automatisch aktualisiert. Snapshots werden sich im Laufe der Zeit ändern.

Nebeneinander-Funktionsvergleich

Die Benchmark

Was wurde gemessen

Die Benchmark Bloom Suite erstellt die gleiche Anwendung mit jeder Bibliothek: 10 Seiten (Home, About, Blog, Karrieren, Kontakt, FAQ, Preise, Produkte, Einstellungen, Team), 10 Sprachen (en, fr, es, de, it, pt, zh, ja, ko, ru), identische Komponenten und identischer Inhalt. Seiten werden in en und fr gemessen. Jede Bibliothek wird in bis zu vier Ladestrategien implementiert, von der naiven Einrichtung bis zur optimalen:

Intlayer hat keine "scoped"-Variante: Der Compiler scoped Inhalte pro Komponente automatisch, daher sind seine static- und dynamic-Zeilen bereits scoped.

Für jeden Build zeichnet die Suite Folgendes auf:

• Lib size: gzip-Größe einer leeren Komponente, die nur die i18n-Bibliothek importiert. Die Fixkosten der Runtime.
• Page JS: gzip-JavaScript, das pro Seite heruntergeladen wird, gemittelt über alle Seiten und Sprachen.
• Locale leak %: Anteil der übersetzten Strings im heruntergeladenen JS, die zu einer Sprache gehören, die der Benutzer nicht ansieht (fingerprinted auf en und fr, also bedeutet 50 % "die andere gemessene Sprache ist vollständig vorhanden"; bei 10 gebündelten Sprachen ist der tatsächliche Verschwendung höher).
• Page leak %: Anteil der übersetzten Strings im heruntergeladenen JS, die zu einer Seite gehören, auf der sich der Benutzer nicht befindet.
• Component avg: durchschnittliche gzip-Größe jeder Komponente, die isoliert kompiliert wird. Zeigt, wie viel i18n-Runtime eine einzelne Komponente mit sich bringt.
• E2E Reaktivität: Echtzeit zwischen der Auswahl eines neuen Locale und der Aktualisierung von html[lang] im DOM (Playwright, 5 Iterationen).
• Hydration: Dauer der React-Hydration-Phase.

Die folgenden Zahlen stammen aus dem Lauf vom 12.09.2026 mit next-intl 4.14.2, use-intl 4.14.2 und intlayer 9.5.1. Die Test-Anwendung ist absichtlich klein (einige Dutzend Strings pro Locale), daher beschreiben die Leckage-Prozentsätze ein Muster: Sie wachsen mit Ihrem Inhalt, während die Runtime-Kosten fest bleiben.

Ergebnisse auf Next.js (App Router)

Wie man es liest

• Laufzeit-Kosten. Die Basis-Anwendung wiegt 141.0 KB pro Seite. next-intl bringt es auf 153.6 KB (+12.6 KB gzip auf jeder Seite), Intlayer auf 141.3 KB (+0.3 KB). Dieser Unterschied hängt nicht davon ab, wie viele Strings Sie haben: es ist die Library-Runtime.
• Leakage. In den zwei Setups, die die meisten Teams tatsächlich einsetzen (static und dynamic), liefert next-intl ~90% der Strings fremder Seiten mit jeder Seite: das gesamte en.json wird in den Client Provider eingebunden. Um auf 0% zu kommen, sind die scoped-* Setups erforderlich: Kataloge in Namespaces aufteilen und dann pick() die richtigen auf jeder Seite. Intlayer liegt in beiden Zeilen ohne all das bei 0%.
• Per-Page JS bewegte sich für next-intl zwischen Strategien nicht. Der Testinhalt ist klein, daher ist das ~90% Leakage hier nur wenige KB. Bei einer echten App mit Hunderten von Strings pro Seite wird dieses Verhältnis zur dominanten Kosten. Währenddessen wird die +12,6 KB Runtime in jeder Konfiguration bezahlt.
• Komponentengröße. Eine Komponente, die useTranslations() aufruft, wird im Durchschnitt zu 21,8 KB kompiliert; die gleiche Komponente mit useIntlayer() wird zu 6,9 KB kompiliert. Im scoped-static-Setup springen die next-intl-Komponenten auf 80,1 KB, weil jede ihren Namespace-Katalog inline einfügt.
• Reaktivität und Hydration liegen für beide Bibliotheken auf Next.js im gleichen Bereich (15-18 ms). Keine von beiden ist hier ein Engpass.

Ergebnisse auf TanStack Start (use-intl)

use-intl ist der Framework-agnostische Kern von next-intl. Gleiche API, gleiches Nachrichtenformat. Der Vergleich mit intlayer auf TanStack Start entfernt die Next.js-spezifischen Teile der Gleichung.

So wird es gelesen

• Das naive use-intl-Setup versendet 68.8 KB mehr JS pro Seite als die Basis-App, wobei die Hälfte der Strings zur falschen Locale gehört und 90% zur falschen Seite.
• use-intl im dynamic-Modus landet bei 119,4 KB, nahe an Intlayers 118,6 KB, trägt aber immer noch 89,8% Seiten-Leakage: alle Strings aller Seiten für das aktive Locale werden auf jeder Seite geladen. Das Scoping pro Route (scoped-*) entfernt das Leak, kostet aber zusätzliche ~9 KB Chunk-Overhead.
• Intlayer's static-Zeile hat bereits 0% Seiten-Leakage: der Compiler bundelt nur die Dictionaries, die von den Komponenten auf der Seite verwendet werden. Das Aktivieren von importMode: 'dynamic' (eine Zeile in intlayer.config.ts) entfernt auch das Locale-Leakage.
• Komponenten-Größe ist der Punkt, wo die Architektur sich zeigt: 76-87 KB pro Komponente mit use-intl gegenüber 6-8 KB mit Intlayer. useTranslations() bindet jede Komponente an den globalen Message-Tree; useIntlayer() bindet sie an ihr eigenes Dictionary.
• Locale-Wechsel ist mit Intlayer 2x-4x schneller (3 ms vs 7-21 ms).

Warum der Unterschied? Zentralisierte Kataloge vs. kompilierte Wörterbücher

next-intl folgt dem klassischen Modell: eine JSON pro Locale, geladen in getRequestConfig, gepusht in einen NextIntlClientProvider, gelesen durch t("namespace.key").

.
├── messages
│   ├── en.json
│   └── fr.json
└── src
    ├── i18n
    │   ├── request.ts
    │   └── routing.ts
    ├── middleware.ts
    └── app
        └── [locale]
            ├── layout.tsx
            └── about
                └── page.tsx

Die Runtime kann nicht wissen, welche Keys eine Seite verwenden wird, also ist der sichere Standard, den gesamten Katalog zu senden. Optimierung bedeutet, dass Sie den Katalog in Namespaces aufteilen, Sie entscheiden, welche Namespaces jede Seite benötigt, und Sie diese Zuordnung synchron halten, während sich Komponenten bewegen. Die scoped-dynamic-Zeile des Benchmarks ist die Belohnung für diese Arbeit, und die meisten Teams erreichen das nie.

Intlayer dreht die Verantwortung um. Inhalte werden neben der Komponente deklariert:

.
├── intlayer.config.ts
└── src
    ├── middleware.ts
    ├── app
    │   └── [locale]
    │       ├── layout.tsx
    │       └── about
    │           ├── page.tsx
    │           └── page.content.ts
    └── components
        └── Counter
            ├── index.tsx
            └── index.content.ts

Zur Build-Zeit sieht der Compiler (@intlayer/swc / @intlayer/babel), welche Komponente welches Dictionary importiert. Er bündelt nur diese Dictionaries, nur für die aktive Locale, und verwirft die, die nichts importiert. Das "scoped-dynamic" Pattern wird zur Ausgabe des Builds, anstatt eine Disziplin zu sein, die das Team beibehalten muss.

Um die Nummern der dynamic Reihe zu erhalten, setzen Sie dictionary.importMode: 'dynamic' in intlayer.config.ts. Siehe die Bundle-Optimierungs-Dokumentation.

Developer Experience

Client-Komponente

next-intl

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

"use client";

import { useState } from "react";
import { useTranslations, useFormatter } from "next-intl";

export const Counter = () => {
  const t = useTranslations("counter");
  const format = useFormatter();
  const [count, setCount] = useState(0);

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

Denken Sie daran, den counter-Namespace in die Nachrichten einzubeziehen, die an NextIntlClientProvider auf jeder Seite übergeben werden, die diese Komponente rendert.

Intlayer

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

const counterContent = {
  key: "counter",
  content: {
    label: t({ de: "Zähler", en: "Counter", fr: "Compteur" }),
    increment: t({ de: "Inkrementieren", 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>
  );
};

Nichts auf der Seite zu registrieren: die Komponente bringt ihren eigenen Inhalt mit.

Synchrone Server-Komponente

Design-System-Komponenten (Navbar, Footer, Cards) sind oft Server-Komponenten, die als untergeordnete Elemente von Client-Komponenten gerendert werden, daher können sie nicht async sein.

next-intl

type ServerCounterProps = {
  t: (key: string) => string;
  formattedCount: string;
};

export const ServerCounter = ({ t, formattedCount }: ServerCounterProps) => (
  <div>
    <p>{formattedCount}</p>
    <button aria-label={t("label")}>{t("increment")}</button>
  </div>
);

Die Seite muss await getTranslations("counter") und await getFormatter() aufrufen und die Ergebnisse dann als Props nach unten weiterleiten. Die Komponente ist nicht mehr in sich geschlossen.

Intlayer

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>
  );
};

Metadaten

next-intl

import type { Metadata } from "next";
import { getTranslations } from "next-intl/server";
import { routing } from "@/i18n/routing";

const localizedPath = (locale: string, path: string) =>
  locale === routing.defaultLocale ? path : `/${locale}${path}`;

export const generateMetadata = async ({
  params,
}: {
  params: Promise<{ locale: string }>;
}): Promise<Metadata> => {
  const { locale } = await params;
  const t = await getTranslations({ locale, namespace: "about" });

  const languages = Object.fromEntries(
    routing.locales.map((l) => [l, localizedPath(l, "/about")])
  );

  return {
    title: t("title"),
    description: t("description"),
    alternates: {
      canonical: localizedPath(locale, "/about"),
      languages: { ...languages, "x-default": "/about" },
    },
  };
};

Intlayer

import { getIntlayer, getMultilingualUrls } from "intlayer";
import type { Metadata } from "next";
import type { LocalPromiseParams } from "next-intlayer";

export const generateMetadata = async ({
  params,
}: LocalPromiseParams): Promise<Metadata> => {
  const { locale } = await params;
  const metadata = getIntlayer("about-metadata", locale);
  const multilingualUrls = getMultilingualUrls("/about");

  return {
    ...metadata,
    alternates: {
      canonical: multilingualUrls[locale as keyof typeof multilingualUrls],
      languages: { ...multilingualUrls, "x-default": "/about" },
    },
  };
};

Behalte die next-intl API, erhalte die Ausgabe von Intlayer

Du musst Komponenten nicht neu schreiben, um die oben genannten Benchmark-Zahlen zu erreichen. @intlayer/next-intl ist ein Drop-in-Adapter: Er behält useTranslations, getTranslations, useFormatter, t.rich(), ICU-Plurale und die next-intl/navigation Helper bei und stellt sie aus den vom Intlayer-Compiler kompilierten Intlayer-Wörterbüchern bereit.

import type { NextConfig } from "next";
import { createNextIntlPlugin } from "@intlayer/next-intl/plugin";

const withIntlayer = createNextIntlPlugin();

const nextConfig: NextConfig = {};

export default withIntlayer(nextConfig);

Im Benchmark ist die Kompatibilitätsbuild derselben App von 153,6 KB auf 147,5 KB pro Seite, von 21,8 KB auf 8,1 KB pro Komponente und von ~90% Seiten-Leakage auf 0% gesunken, wobei der Anwendungscode unverändert blieb. Ihre vorhandenen messages/{locale}.json-Dateien können durch das JSON-Sync-Plugin als Quelle der Wahrheit bleiben.

Siehe den next-intl-Migrationsleitfaden für eine Schritt-für-Schritt-Anleitung.

Wann sollte man was wählen?

• Wählen Sie next-intl, wenn Sie den Ökosystem-Standard für Next.js mögen, Sie sich auf ICU MessageFormat verlassen, Ihre App klein bis mittelgroß ist, oder Sie mit einer Übersetzungsplattform (Crowdin, Phrase, Lokalise...) integrieren, die zentralisierte JSON erwartet. Planen Sie Zeit für das Namespace von Katalogen und wählen Sie Nachrichten pro Seite, wenn Performance wichtig ist.
• Wählen Sie Intlayer, wenn Sie komponentengebundene Inhalte, striktes TypeScript, Build-Zeit-Fehler bei fehlenden Schlüsseln, müheloses Tree-Shaking und Lazy Loading, synchrone Server Components und integrierte redaktionelle Tools (Visual Editor, CMS, AI-Übersetzung, MCP-Server) mögen. Besonders relevant für große, modulare Codebases und Design Systems.
• Wählen Sie @intlayer/next-intl, wenn Sie bereits next-intl verwenden und die Bundle-Gewinne ohne Umschreiben mögen.

Verwandte Vergleiche

• i18next vs Intlayer (gleicher Benchmark)
• Lingui vs Intlayer (gleicher Benchmark)
• vue-i18n vs Intlayer benchmark (gleicher Benchmark)
• next-i18next vs next-intl vs Intlayer
• Is next-intl outdated?

GitHub STARS

GitHub-Sterne sind ein starker Indikator für die Beliebtheit eines Projekts, das Vertrauen der Community und die langfristige Relevanz. Obwohl sie kein direktes Maß für technische Qualität sind, spiegeln sie wider, wie viele Entwickler das Projekt für nützlich befinden, dessen Fortschritt verfolgen und es wahrscheinlich einführen werden.

Fazit

next-intl ist eine solide, gut gepflegte Bibliothek, und der Benchmark bestätigt, dass sie bei Next.js weit entfernt davon ist, die schlechteste Option zu sein. Aber sein zentralisiertes Katalog-Modell legt jede Optimierung in die Hände des Entwicklers: Das naive Setup leckt ~90% des Inhalts fremdsprachiger Seiten, und die Runtime allein kostet +12,6 KB gzip auf jeder Seite.

Intlayer verlagert diese Arbeit in den Compiler. Pro-Komponenten-Wörterbücher, Pro-Locale-Lazy-Loading und Dead-Content-Purging sind Build-Ausgaben, keine Konventionen. Das Ergebnis in derselben App: +0,3 KB pro Seite, 0% Leckageverlust, Komponenten 3x kleiner, und ein Locale-Wechsel 2x-4x schneller auf TanStack Start.

Alle Rohdaten, die Test-Apps und die Scripts befinden sich im Benchmark-Bloom-Repository. Führen Sie es selbst aus.

Weitere Informationen finden Sie in der Dokumentation 'Why Intlayer?'.