i18next VS Intlayer | React & Next.js 国際化 (i18n) ベンチマーク比較

i18nextは、JavaScriptエコシステムで最も広く利用されているi18nフレームワークです。react-i18nextやnext-i18nextを通じて、数多くのReactおよびNext.jsアプリケーションで採用されています。Intlayerは、コンパイラ駆動型でコンポーネントスコープ設計を採用した新しい選択肢です。

本記事では、機能リストの単なる比較ではなく、客観的な実測値に基づいて両者を比較します。掲載されている数値は、同一アプリケーションを各ライブラリでビルドし、ブラウザが実際にダウンロードするリソースを記録するオープンソーススイートBenchmark Bloomの測定結果に基づいています。

tl;dr: i18nextはベンチマーク内で最も重量級のランタイムであり、標準構成のNext.jsで1ページあたり+77 KB gzip、名前空間と遅延ロードを完全に最適化した場合でも+22 KBの増加をもたらします。対してIntlayerの増加はわずか+0.3 KBです。完全スコープ化された構成を除くすべてのi18next構成では、別ページの翻訳文字列が約90%リークして送信されますが、Intlayerはデフォルトで0%です。遅延読み込みバックエンドを使用したロケール切り替えは、react-i18nextで123〜185 msかかったのに対し、Intlayerは3〜4 msで完了しました。i18nextのAPIを維持できる互換アダプター@intlayer/next-i18nextを使用した場合でも、1ページあたり150.7 KBとなり、本家の218.5 KBから大幅に削減されます。

要約

• i18next / react-i18next / next-i18next - 実績豊富でプラグインが充実し、フレームワークに依存しません。名前空間、言語検出、各種バックエンド、プラグイン経由のICU、リッチコンテンツ用の<Trans>をサポート。翻訳はlocales/{lng}/{ns}.jsonに一括管理されます。強力ですが、最適化（名前空間の分割、ページごとの読み込み制御、型安全性）のすべてを開発者自身で設計・保守する必要があります。
• Intlayer - コンポーネント中心のコンテンツモデル。.content.ts辞書ファイルを対応するコンポーネントと同階層に配置。ビルド時コンパイラがコンポーネントおよびロケール単位でツリーシェイキングと遅延読み込みを実施し、コンテンツから厳格なTypeScript型を自動生成。翻訳漏れはビルド時に検出・遮断されます。ミドルウェア、SEOヘルパー、ビジュアルエディタ / CMS、AI翻訳支援も標準提供。

テーブルのすべての内容を表示

テーブルのすべての内容を表示

テーブルをモーダルで開き、すべてのデータを明確に表示

ライブラリ	GitHubスター	総コミット数	最終コミット	初回リリース	NPMバージョン	NPM月間ダウンロード数
aymericzip/intlayer				2024年4月
i18next/i18next				2012年1月
i18next/react-i18next				2015年12月
i18next/next-i18next				2018年11月

バッジは自動更新されます。測定時期により変動します。

機能比較一覧

ベンチマーク測定

測定対象と環境

Benchmark Bloomスイートは、各ライブラリを用いて同一仕様のアプリケーションを構築します。10ページ（home, about, blog, careers, contact, FAQ, pricing, products, settings, team）、10ロケール（en, fr, es, de, it, pt, zh, ja, ko, ru）、同一コンポーネント・同一コンテンツで検証し、測定はenおよびfrで行われます。

各ライブラリは、基本的な構成から最適な構成まで最大4つの読み込み戦略でテストされています：

Intlayerには「scoped」バリアントが存在しません。コンパイラが自動的にコンポーネント単位でコンテンツをスコープ化するため、staticおよびdynamicの行がすでに最適化された状態となります。

各ビルドで測定される指標：

• Lib size: i18nライブラリのみをインポートした空コンポーネントのgzipサイズ。ランタイムの固定コスト。
• Page JS: 1ページあたりにダウンロードされるJavaScriptのgzipサイズ（全ページ・全言語の平均）。
• Locale leak %: ダウンロードされたJS内の翻訳文字列のうち、ユーザーが閲覧していない言語の割合。
• Page leak %: ダウンロードされたJS内の翻訳文字列のうち、ユーザーが開いていないページの割合。
• Component avg: 独立してコンパイルされた各コンポーネントの平均gzipサイズ。
• E2E reactivity: 言語切り替え操作からDOMのhtml[lang]が更新されるまでの実測時間（Playwright、5回試行の平均）。
• Hydration: Reactのハイドレーションフェーズの所要時間。

以下の測定値は、next-i18next 16.3.0、react-i18next 17.0.13、intlayer 9.5.1を使用した2026-09-12時点のデータです。テストアプリは意図的に軽量（言語あたり数十個の文字列）に作られているため、リーク率は構造的な傾向を表しています。コンテンツ量が増加するにつれてリーク量は拡大しますが、ランタイムコストは固定されます。

Next.jsでの結果 (next-i18next)

結果の解説

• ランタイムコスト: i18nextコア + react-i18nextは、空のコンポーネントでも19.7 KB gzipと測定対象中最大で、next-intlayerの5.5 KBを大きく上回ります。
• 標準構成の肥大化: init()にresourcesをインライン化すると、ベースアプリから+77.5 KB増の218.5 KB/ページに達します。全ページが全名前空間を持ち歩くためです。
• 最適化の難易度: バックエンド（dynamic）に切り替えると49 KB削減できますが、依然として別ページの文字列が90%リークし、測定構成では半分が別言語の文字列となります。ルート単位の名前空間分割（scoped-dynamic）を導入してようやくリーク0%（163.4 KB）に達しますが、設定不要なIntlayerの141.3 KBより22.4 KB重い結果となります。
• コンポーネントサイズ: useTranslation()を使用するコンポーネントは構成に応じて26〜79 KBに膨らみますが、useIntlayer()を使う同一コンポーネントは6.9 KBで済みます。
• ハイドレーション: dynamic構成では27.7 msに悪化します。クライアント側でReactがハイドレーションを開始する前に、i18nextインスタンスが初期化されバックエンドを解決する必要があるためです。

TanStack Startでの結果 (react-i18next)

Next.js特有のオーバーヘッドを排除するため、TanStack Start上で純粋なreact-i18nextを使用した比較です。

結果の解説

• 初期のreact-i18nextアプリはベースアプリより+69 KB/ページ重く、ハイドレーションに85 ms（ベースの4倍）かかります。初回の描画前にすべてのリソースツリーを解析・登録するためです。
• 言語切り替え時の遅延: バックエンドによる遅延読み込みを行う場合、言語を変更するとネットワーク往復が発生してからhtml[lang]が更新されるため、dynamicで123 ms、scoped-staticで185 msを要します。対してIntlayerはどちらのモードでも3〜4 msで即座にDOMが反映されます。
• 最大限に最適化したscoped-dynamicでも127.2 KBと、Intlayerのdynamicより+8.6 KB重く、ルートと名前空間のマッピングやSuspenseの設定などの複雑な作業が必要です。
• Intlayerのstaticは、該当ページのコンポーネントがインポートした辞書のみをバンドルするため、初期状態でページリーク0%です。importMode: 'dynamic'を設定すれば、言語リークも0%になります。
• コンポーネントサイズ: react-i18nextの24〜27 KBに対し、Intlayerは6〜8 KBです。

なぜこれほどの差が出るのか？ グローバルインスタンス vs コンパイル済み辞書

i18nextは2012年にランタイム主導で設計されました。グローバルインスタンスがリソースストアを保持し、プラグインがそれを拡張し、描画時にt()がキーを検索します。この構造が高い汎用性をもたらす一方で、オーバーヘッドの原因となっています：

.
├── 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     # ["common", "about"]が必要であることを把握しておく必要がある

インスタンスはコンポーネントがどのキーを必要とするか事前に知ることができないため、指定された名前空間をすべて保持します。最適化のためには、開発者自身がカタログを名前空間に分割し、ページごとの依存関係を定義し、コンポーネントの移動に合わせてメンテナンスし続ける必要があります。ベンチマークノートにある通り、「型安全性を保ちながら各ページに必要な名前空間を正確に把握・維持することは非常に過酷な作業」です。

Intlayerはグローバルインスタンスを排除します。コンテンツはコンポーネントのすぐ隣で宣言され、コンパイラがビルド時に依存関係グラフを解決します：

.
├── 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がコンポーネントと辞書の依存関係を追跡し、アクティブな言語に必要な辞書のみをバンドルし、未使用のコンテンツを切り捨てます。「scoped-dynamic」な最適化は、手作業のルールではなくビルドの成果物として自動的に実現されます。

dynamic行の数値を再現するには、intlayer.config.tsでdictionary.importMode: 'dynamic'を設定します。詳細はバンドル最適化ドキュメントを参照してください。

開発者体験（DX）

セットアップの比較

next-i18next (App Router)

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

これに加えて、クライアント側のI18nProviderの作成、generateStaticParamsの設定、各ページでの名前空間リストの指定が必要です。

Intlayer

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;

クライアントコンポーネント

react-i18next

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

このコンポーネントを描画するページはabout名前空間をロードする必要があり、CustomTypeOptionsを拡張しない限りt("counter.label")の型安全性は保証されません。

Intlayer

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

labelとincrementは厳格に型付けされており、キーのタイポはTypeScriptエラーになり、フランス語の翻訳欠落はビルド時にエラーとして検出されます。

同期サーバーコンポーネント

next-i18next

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

ページ側でi18n.getFixedT(locale, "about")を呼び出し、Propsを通じてtとlocaleを渡す必要があります。

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

i18nextのAPIのままIntlayerの最適化を享受する

既存のコンポーネントを書き換えることなく、上記のベンチマーク性能を得ることも可能です。@intlayer/i18next、@intlayer/react-i18next、@intlayer/next-i18nextはドロップイン互換アダプターとして機能します。useTranslation、t()、<Trans>、{{interpolation}}、複数形接尾辞、コンテキスト接尾辞、returnObjectsがそのまま動作し、背後ではIntlayerコンパイラが辞書を最適化して供給します。

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()],
});

ベンチマークでは、アプリコードを変更することなく、Next.jsアプリが1ページあたり218.5 KBから150.7 KBへ、コンポーネントが78.5 KBから9.7 KBへ、ページリークが~90%から0%へと改善し、ハイドレーション時間も15.6 msから11.3 msへ短縮されました。既存のlocales/{lng}/{ns}.jsonは、JSON同期プラグインを介してマスターデータのまま運用できます。

詳細は移行ガイドをご覧ください: i18next, react-i18next, next-i18next。

どちらを選ぶべきか？

• i18nextを選ぶべき場合: 豊富なプラグインエコシステム（各種バックエンド、ICU、Locize等）が不可欠な場合、React以外の領域（Node.jsサービス、Vanilla JS、他フレームワーク）でも同一ツールを使いたい場合、チームがすでに習熟している場合、翻訳プラットフォームがlocales/{lng}/{ns}.jsonを前提としている場合。ただし、パフォーマンスを追求する場合は名前空間の設計やページマッピングの維持に十分なリソースを確保してください。
• Intlayerを選ぶべき場合: コンポーネントスコープのコンテンツ管理、厳格なTypeScript型付け、ビルド時の翻訳漏れ検出、自動ツリーシェイキングと遅延ロード、瞬時のロケール切り替え、同期サーバーコンポーネント、統合編集ツール（ビジュアルエディタ、CMS、AI翻訳支援、MCPサーバー）を重視する場合。モジュール化されたコードベースやデザインシステムに最適です。
• @intlayer/*-i18nextアダプターを選ぶべき場合: すでにi18nextを採用しており、大規模なコード書き換えなしにバンドルサイズと応答性の向上を図りたい場合。

関連する比較記事

• next-intl vs Intlayer（同一ベンチマーク）
• Lingui vs Intlayer（同一ベンチマーク）
• vue-i18n vs Intlayer ベンチマーク（同一ベンチマーク）
• next-i18next vs next-intl vs Intlayer
• react-i18next vs react-intl vs Intlayer
• i18nextは時代遅れか？

GitHubスター

GitHubスターは、プロジェクトの認知度、コミュニティの信頼、長期的な継続性の目安となります。技術的な優劣を直接測るものではありませんが、どれだけの開発者が関心を持ち、実務で採用しているかを反映しています。

結論

i18nextは10年以上にわたるメンテナンスと抜群の汎用性により、現在の地位を確立しました。しかし、今回のベンチマークはそのランタイム依存型アーキテクチャのコストを浮き彫りにしています。一般的な構成では1ページあたり+70〜77 KB gzipが加算され、別ページの文字列が約90%漏洩し、遅延ロード時の言語切り替えに100 ms以上かかります。リークを0%に抑えることも可能ですが、それには手動での名前空間マッピングが必要であり、それでもなおIntlayerより9〜22 KB重くなります。

Intlayerはこの負担をコンパイラに移行させました。コンポーネント単位の辞書分割、ロケールごとの遅延ロード、未使用コンテンツのパージは、手作業のルールではなくビルドの成果物として自動化されます。同一アプリでの実測値は、1ページあたり+0.3 KB、リーク0%、コンポーネントサイズ3〜10倍削減、ロケール切り替え3〜4 msです。

テストアプリ、生データ、自動化スクリプトはすべてBenchmark Bloomリポジトリで公開されています。ぜひご自身で追試してみてください。

詳細は'Why Intlayer?' ドキュメントをご覧ください。