Vue i18nライブラリ - 2026年ベンチマークレポート

このページは、Vueにおけるi18nソリューションのベンチマークレポートです。

目次

インタラクティブベンチマーク

結果のリファレンス:

完全なベンチマークデータを見る

完全なベンチマークリポジトリはこちらでご覧いただけます。

はじめに

国際化ソリューションは、Vueアプリにおいて最も重い依存関係の一つです。主なリスクは、不必要なコンテンツ（単一のルートのバンドルに含まれる他のページや他のロケールの翻訳）を送信してしまうことです。

アプリが成長するにつれて、この問題はクライアントに送信されるJavaScriptを急速に増大させ、ナビゲーションを遅くする可能性があります。

実際、最適化が不十分な実装では、国際化されたページがi18nなしのバージョンよりも数倍重くなることがあります。

もう一つの影響は、開発者エクスペリエンス（DX）です。コンテンツの宣言方法、型、名前空間の構成、動的ロード、ロケール変更時の反応性などが含まれます。

TL;DR

• Intlayer: スコーピング（scoping）と動的ロードを内蔵した、最も軽量なソリューション（v8.7.12）。
• vue-i18n: 豊かなエコシステムを持つ業界標準ですが、非常に重くなる可能性があり、大規模アプリケーションでのコード分割の最適化が難しい場合があります。
• fluent-vue: 革新的なメッセージ構成ですが、型安全性が欠けており、非常に重いソリューションです。

アプリをテストする

i18nリークの問題を素早く特定するために、無料のスキャナーを用意しました。こちらでお試しいただけます。

問題点

多言語アプリのコストを抑えるためには、2つのレバーが不可欠です。

• ページ/名前空間ごとにコンテンツを分割し、不要な時に辞書全体をロードしないようにする。
• 必要な時にだけ、適切なロケールを動的にロードする。

これらのアプローチの技術的限界を理解する：

動的ロード

動的ロードがない場合、ほとんどのソリューションは最初のレンダリングからメッセージをメモリに保持するため、ルートやロケールが多いアプリでは大きなオーバーヘッドとなります。

動的ロードを使用する場合、トレードオフを受け入れることになります。初期JSは減りますが、言語切り替え時などに追加のリクエストが発生することがあります。

コンテンツの分割

const { t } = useI18n() + t('a.b.c') を中心に構築された構文は非常に便利ですが、実行時に大きなJSONオブジェクトを保持することを助長しがちです。このモデルでは、ライブラリがページごとの分割戦略を提供していない限り、ツリーシェイキング（tree-shaking）が難しくなります。

研究方法

このベンチマークでは、以下のライブラリを比較しました。

• Base App (i18nライブラリなし)
• vue-intlayer (v8.7.12)
• vue-i18n (v11.4.0)
• fluent-vue (v3.8.2)

フレームワークは Vue で、10ページと10言語を持つ多言語アプリを使用しました。

4つのロード戦略を比較しました。

戦略のまとめ

• 静的（Static）: シンプル。初期ロード後のネットワーク遅延なし。欠点：バンドルサイズが大きい。
• 動的（Dynamic）: 初期重量を削減（遅延ロード）。ロケールが多い場合に理想的。
• 名前空間付き静的（Scoped static）: 複雑な追加リクエストなしで、コードを整理（論理的分離）した状態に保つ。
• 名前空間付き動的（Scoped dynamic）: コード分割とパフォーマンスのための最善のアプローチ。現在のビューとアクティブなロケールに必要なものだけをロードし、メモリ使用量を最小限に抑える。

測定項目：

各スタックについて実際のブラウザで同じ多言語アプリを実行し、実際にネットワーク上を流れたデータ量と時間を記録しました。サイズは通常のWeb圧縮後の数値です。これは、生のソースコード量よりもユーザーが実際にダウンロードする量に近いからです。

• i18nライブラリのサイズ: バンドル、ツリーシェイキング、ミニファイ後のi18nライブラリのサイズです。空のコンポーネントにおけるプロバイダーやコンポーザブル（composables）のコードサイズを指し、翻訳ファイルのロードは含みません。コンテンツが入る前に、ライブラリ自体がどれほど「高価」であるかを示します。

• 1ページあたりのJavaScript: 各ベンチマークルートにおいて、ブラウザが読み込むスクリプトの量です。テストスイート内のページの平均値（およびロケールごとの平均値）です。重いページは遅いページです。

• 他のロケールからのリーク（Leakage）: 同じページの内容ですが、別の言語のコンテンツが誤って監査対象のページにロードされてしまうことです。このコンテンツは不要であり、避けるべきです（例：/en/about ページのバンドルに含まれる /fr/about ページの内容）。

• 他のルートからのリーク: アプリ内の他の画面についても同様です。1つのページしか開いていないのに、他の画面のテキストが一緒に運ばれていないかを示します（例：/en/contact ページのバンドルに含まれる /en/about ページの内容）。数値が高い場合は、分割が不十分であるか、バンドルが広範すぎることを示唆しています。

• コンポーネントの平均バンドルサイズ: 一般的なUI要素を一つずつ測定します。これにより、国際化が日常的なコンポーネントをひっそりと肥大化させていないかを確認できます。例えば、コンポーネントが再レンダリングされる際、それらすべてのデータをメモリからロードすることになります。巨大なJSONをコンポーネントに紐付けることは、未使用のデータの大きなストアを接続するようなもので、コンポーネントのパフォーマンスを低下させます。

• 言語切り替えの反応性: アプリ自身のコントロールを使用して言語を切り替え、ページが明確に切り替わるまでの時間を測定します。これはユーザーが気づく時間です。

• 言語変更後のレンダリング作業: 言語が切り替わり始めた後に、インターフェースが新しい言語で再描画するために費やした労力です。「体感」時間とフレームワークのコストが異なる場合に役立ちます。

• 初期ページロード時間: ナビゲーションから、ブラウザがページを完全にロードしたと判断するまでの時間です。コールドスタートの比較に役立ちます。

• ハイドレーション時間（Hydration）: クライアントがサーバーからのHTMLをインタラクティブなものに変えるのに費やす時間です。表内のダッシュ（-）は、その実装がこのベンチマークで信頼できるハイドレーションの数値を提供しなかったことを意味します。

GitHubのスター

GitHubのスターは、プロジェクトの普及度、コミュニティの信頼、および長期的な関連性を示す強力な指標です。技術的な品質を直接測定するものではありませんが、どれだけの開発者がプロジェクトを有用だと感じ、その進捗をフォローし、採用する可能性があるかを反映しています。プロジェクトの価値を見積もる際、スターは代替案との勢いの比較を助け、エコシステムの成長に関する洞察を提供します。

結果の詳細

1 - 避けるべきソリューション

Vueエコシステムにおいて、明確に避けるべきソリューションはありません。

2 - 許容できるソリューション

(vue-i18n) ([email protected]):

• vue-i18n は間違いなくVueで最も使用されているi18nライブラリであり、多くの機能と巨大なエコシステムを持っています。しかし、内部的にはかなり重いソリューションです。メッセージの遅延ロードを統合していても、スコーピング（scoping）機能が欠けています。標準的なVue SPAアプリの場合は問題ありませんが、@nuxt/i18nを使用するNuxtアプリの場合、すべてのページのメッセージが単一のページに含まれてしまうことになります。10ページを超える大規模なNuxtアプリでは、これが深刻な問題になる可能性があります。

パッケージは非常に重いです（~24.3kb。これは vue-intlayer の約9倍です）。

(fluent-vue) ([email protected]):

• fluent-vue は .ftl 形式を通じて革新を試みています。メッセージの構成は素晴らしく、始めやすいです。しかし実際には、型安全性の欠如によりエラーのリスクが高まり、デバッグに時間がかかる可能性があります。さらに、このソリューションはViteプラグインを使用してメッセージをロードしますが、これによりすべての言語の全コンテンツが各ページに強制的にロードされます。加えて、これは極めて重いソリューションです（~92.7kb。これは vue-intlayer の約34倍です）。

3 - 推奨事項

(Intlayer) ([email protected]):

客観性を保つため、vue-intlayer については私自身のソリューションであるため、個人的な評価は控えます。