next-intl VS Intlayer | Benchmark d'Internationalization (i18n) Next.js

next-intl est la bibliothèque i18n la plus populaire pour Next.js. Intlayer est une alternative basée sur un compilateur et scoped au niveau des composants. Les deux localisent une application App Router. La question est ce que chacune coûte une fois que l'application est construite.

Cet article n'est pas un tutoriel. C'est une comparaison étayée par des chiffres provenant de Benchmark Bloom, une suite de benchmark open-source qui construit la même application avec chaque bibliothèque et mesure ce que le navigateur télécharge et exécute réellement.

tl;dr: Sur la même application Next.js, next-intl ajoute +12.6 KB gzip de JavaScript sur chaque page, versus +0.3 KB pour Intlayer. Sans travail supplémentaire, next-intl expédie ~90% des chaînes de pages étrangères avec chaque page. Atteindre 0% de fuite avec next-intl nécessite la portée des namespaces et pick(messages, [...]) par page. Intlayer atteint 0% par défaut, car son compilateur limite le contenu par composant. Si vous voulez l'API next-intl avec la sortie d'Intlayer, l'adaptateur @intlayer/next-intl a mesuré 147.5 KB par page versus 153.6 KB avec l'original.

En résumé

• next-intl - Léger, bien documenté, format de message ICU, support de première classe pour App Router avec middleware, formatters et helpers de navigation. Le contenu réside dans des catalogues JSON centralisés ; les optimisations de performance (namespaces, picking de messages par page, lazy loading) sont de votre responsabilité.
• Intlayer - Modèle de contenu centré sur les composants. Les dictionnaires .content.ts se situent à côté du composant qu'ils servent, un compilateur au moment du build tree-shake et lazy-load les contenus par composant et par locale, des types TypeScript stricts sont générés à partir de votre contenu, et les traductions manquantes échouent au moment du build. Inclut middleware, helpers SEO, un Visual Editor / CMS et traduction assistée par IA.

Afficher tout le contenu du tableau

Afficher tout le contenu du tableau

Ouvrir le tableau dans une fenêtre modale pour voir tout le contenu clairement

Bibliothèque	Étoiles GitHub	Commits totaux	Dernier Commit	Première Version	Version NPM	Téléchargements NPM
aymericzip/intlayer				Avril 2024
amannn/next-intl				Nov 2020

Les badges se mettent à jour automatiquement. Les snapshots varieront au fil du temps.

Comparaison des fonctionnalités côte à côte

Le benchmark

Ce qui a été mesuré

La suite Benchmark Bloom construit la même application avec chaque bibliothèque : 10 pages (accueil, à propos, blog, carrières, contact, FAQ, tarification, produits, paramètres, équipe), 10 locales (en, fr, es, de, it, pt, zh, ja, ko, ru), composants identiques et contenu identique. Les pages sont mesurées en en et fr. Chaque bibliothèque est implémentée dans jusqu'à quatre stratégies de chargement, de la configuration naïve à la configuration optimale :

Intlayer n'a pas de variante "scoped" : le compilateur scopes le contenu par composant automatiquement, donc ses lignes static et dynamic sont déjà scoped.

Pour chaque build, la suite enregistre :

• Lib size : taille gzip de un composant vide qui importe uniquement la bibliothèque i18n. Le coût fixe du runtime.
• Page JS : JavaScript gzip téléchargé par page, moyenné sur toutes les pages et locales.
• Locale leak % : part des chaînes traduites trouvées dans le JS téléchargé qui appartiennent à une locale que l'utilisateur n'est pas en train de consulter (fingerprint sur en et fr, donc 50% signifie « l'autre locale mesurée est entièrement présente » ; avec 10 locales bundlées, le vrai gaspillage est plus élevé).
• Page leak % : part des chaînes traduites trouvées dans le JS téléchargé qui appartiennent à une page sur laquelle l'utilisateur n'est pas.
• Component avg : taille gzip moyenne de chaque composant compilé isolément. Montre combien de runtime i18n un seul composant entraîne.
• E2E reactivity: temps écoulé entre la sélection d'une nouvelle locale et la mise à jour de html[lang] dans le DOM (Playwright, 5 itérations).
• Hydration: durée de la phase d'hydratation de React.

Les chiffres ci-dessous proviennent de l'exécution datée du 2026-09-12 avec next-intl 4.14.2, use-intl 4.14.2 et intlayer 9.5.1. L'application de test est volontairement petite (quelques dizaines de chaînes par locale), donc les pourcentages de fuite décrivent un pattern : ils augmentent avec votre contenu tandis que le coût d'exécution reste fixe.

Résultats sur Next.js (App Router)

Comment le lire

• Coût du runtime. L'application de base pèse 141.0 KB par page. next-intl la porte à 153.6 KB (+12.6 KB gzip sur chaque page), Intlayer à 141.3 KB (+0.3 KB). Cet écart ne dépend pas du nombre de chaînes que vous avez : c'est le runtime de la librairie.
• Leakage. Dans les deux configurations que la plupart des équipes déploient réellement (static et dynamic), next-intl livre ~90% des chaînes de pages étrangères avec chaque page : l'ensemble du en.json est inséré dans le provider client. Pour atteindre 0%, il faut utiliser les configurations scoped-* : diviser les catalogues en namespaces, puis utiliser pick() pour sélectionner les bons dans chaque page. Intlayer est à 0% dans les deux lignes sans rien de tout cela.
• Le JS par page n'a pas changé pour next-intl entre les stratégies. Le contenu du test est petit, donc la fuite ~90% ne représente que quelques KB ici. Sur une vraie application avec des centaines de chaînes par page, ce ratio devient le coût dominant. Pendant ce temps, le runtime +12.6 KB est payé dans chaque configuration.
• Taille des composants. Un composant qui appelle useTranslations() compile à 21.8 KB en moyenne ; le même composant avec useIntlayer() compile à 6.9 KB. Dans la configuration scoped-static, les composants next-intl sautent à 80.1 KB car chacun intègre son catalogue de namespaces.
• Réactivité et hydratation sont dans le même ordre de grandeur pour les deux bibliothèques sur Next.js (15-18 ms). Aucune n'est un goulot d'étranglement ici.

Résultats sur TanStack Start (use-intl)

use-intl est le cœur indépendant du framework de next-intl. Même API, même format de message. Le comparer à intlayer sur TanStack Start supprime les parties spécifiques à Next.js de l'équation.

Comment le lire

• La configuration naive use-intl embarque 68.8 KB de JS supplémentaires par page par rapport à l'application de base, avec la moitié des chaînes appartenant à la mauvaise locale et 90% à la mauvaise page.
• use-intl en mode dynamic atteint 119.4 KB, proche des 118.6 KB d'Intlayer, mais porte toujours 89.8% de fuite de page : toutes les chaînes de la locale active pour toutes les pages sont chargées sur chaque page. Les délimiter par route (scoped-*) supprime la fuite mais coûte un autre ~9 KB de surcharge de chunk.
• La ligne static d'Intlayer a déjà 0% de fuite de page : le compilateur n'agrège que les dictionnaires utilisés par les composants de la page. L'activation de importMode: 'dynamic' (une ligne dans intlayer.config.ts) supprime aussi la fuite de locale.
• La taille du composant montre où se trouve l'architecture : 76-87 KB par composant avec use-intl versus 6-8 KB avec Intlayer. useTranslations() lie chaque composant à l'arborescence de messages globale ; useIntlayer() le lie à son propre dictionnaire.
• Le changement de locale est 2 à 4 fois plus rapide avec Intlayer (3 ms contre 7-21 ms).

Pourquoi cet écart ? Catalogues centralisés vs dictionnaires compilés

next-intl suit le modèle classique : un JSON par locale, chargé dans getRequestConfig, poussé dans un NextIntlClientProvider, lu via t("namespace.key").

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

Le runtime ne peut pas connaître les clés qu'une page utilisera, donc la valeur par défaut sûre est d'envoyer l'ensemble du catalogue. Optimiser signifie que vous divisez le catalogue en namespaces, que vous décidez quels namespaces chaque page a besoin, et que vous mainteniez cette correspondance synchronisée lorsque les composants se déplacent. La ligne scoped-dynamic du benchmark est la récompense pour ce travail, et la plupart des équipes n'y arrivent jamais.

Intlayer inverse la responsabilité. Le contenu est déclaré à côté du composant :

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

Au moment de la compilation, le compilateur (@intlayer/swc / @intlayer/babel) voit quel composant importe quel dictionnaire. Il regroupe uniquement ces dictionnaires, uniquement pour la locale active, et supprime ceux qu'aucun composant n'importe. Le pattern "scoped-dynamic" devient le résultat de la compilation au lieu d'une discipline que l'équipe doit maintenir.

Pour obtenir les chiffres de la ligne dynamic, définissez dictionary.importMode: 'dynamic' dans intlayer.config.ts. Consultez la documentation sur l'optimisation du bundle.

Expérience développeur

Composant client

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

N'oubliez pas d'inclure l'espace de noms counter dans les messages passés à NextIntlClientProvider sur chaque page qui rend ce composant.

Intlayer

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

const counterContent = {
  key: "counter",
  content: {
    label: t({ fr: "Compteur", en: "Counter" }),
    increment: t({ fr: "Incrémenter", en: "Increment" }),
  },
} 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 = () => {
  // Récupération des traductions du namespace "counter"
  const { label, increment } = useIntlayer("counter");
  // Fonction de formatage des nombres
  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>
  );
};

Rien à enregistrer sur la page : le composant apporte son propre contenu.

Composant serveur synchrone

Les éléments du design system (navbar, footer, cards) sont souvent des composants serveur rendus comme enfants de composants clients, ils ne peuvent donc pas être async.

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

La page doit await getTranslations("counter") et await getFormatter(), puis transmettre les résultats en tant que props. Le composant n'est plus autonome.

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

Métadonnées

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" },
    },
  };
};

Conservez l'API next-intl, obtenez la sortie d'Intlayer

Vous n'avez pas besoin de réécrire les composants pour obtenir les chiffres de benchmark ci-dessus. @intlayer/next-intl est un adaptateur clé en main : il conserve useTranslations, getTranslations, useFormatter, t.rich(), les pluriels ICU et les helpers next-intl/navigation, et les sert à partir des dictionnaires Intlayer compilés par le compilateur Intlayer.

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

const withIntlayer = createNextIntlPlugin();

const nextConfig: NextConfig = {};

export default withIntlayer(nextConfig);

Dans le benchmark, la build de compatibilité de la même application est passée de 153,6 KB à 147,5 KB par page, de 21,8 KB à 8,1 KB par composant, et de ~90% de fuite de page à 0%, sans modifier le code de l'application. Vos fichiers messages/{locale}.json existants peuvent rester la source de vérité grâce au plugin JSON sync.

Consultez le guide de migration next-intl pour les étapes détaillées.

Quand choisir lequel ?

• Choisissez next-intl si vous voulez le standard de l'écosystème pour Next.js, vous dépendez d'ICU MessageFormat, votre application est de petite à moyenne taille, ou vous intégrez avec une plateforme de traduction (Crowdin, Phrase, Lokalise...) qui attend du JSON centralisé. Prévoyez du temps pour structurer les catalogues par namespace et sélectionner les messages par page si la performance compte.
• Choisissez Intlayer si vous voulez du contenu scoped au composant, du TypeScript strict, des erreurs de clés manquantes à la compilation, du tree-shaking et lazy loading sans effort, des composants serveur synchrones, et des outils éditoriaux intégrés (Visual Editor, CMS, traduction IA, serveur MCP). Particulièrement pertinent pour les codebases volumineuses et modulaires et les design systems.
• Choisissez @intlayer/next-intl si vous êtes déjà sur next-intl et voulez les gains de bundle sans réécriture complète.

Comparaisons connexes

• i18next vs Intlayer (même benchmark)
• Lingui vs Intlayer (même benchmark)
• vue-i18n vs Intlayer benchmark (même benchmark)
• next-i18next vs next-intl vs Intlayer
• Is next-intl outdated?

GitHub STARs

Les stars GitHub sont un indicateur fort de la popularité d'un projet, de la confiance de la communauté et de sa pertinence à long terme. Bien que ce ne soit pas une mesure directe de la qualité technique, ils reflètent le nombre de développeurs qui trouvent le projet utile, suivent sa progression et sont susceptibles de l'adopter.

Conclusion

next-intl est une bibliothèque solide et bien maintenue, et le benchmark confirme qu'elle est loin d'être la pire option sur Next.js. Cependant, son modèle de catalogue centralisé place chaque optimisation sur les épaules du développeur : la configuration naïve fuit environ 90% du contenu de pages étrangères, et le runtime seul coûte +12,6 KB gzip sur chaque page.

Intlayer déplace ce travail vers le compilateur. Les dictionnaires par composant, le lazy loading par locale et la purge du contenu mort sont des sorties de build, pas des conventions. Le résultat sur la même application : +0.3 KB par page, 0% de fuite, des composants 3x plus petits, et un changement de locale 2x-4x plus rapide sur TanStack Start.

Toutes les données brutes, les applications de test et les scripts se trouvent dans le repository Benchmark Bloom. Exécutez-le vous-même.

Consultez la documentation 'Why Intlayer?' pour plus de détails.