このページとあなたの好きなAIアシスタントを使ってドキュメントを要約します
バージョン履歴
- "GitHub スター比較を追加"v8.9.82026/5/18
- "ベンチマークの初期化"v8.7.122026/1/6
このページのコンテンツはAIを使用して翻訳されました。
英語の元のコンテンツの最新バージョンを見るこのドキュメントを改善するアイデアがある場合は、GitHubでプルリクエストを送信することで自由に貢献してください。
ドキュメントへのGitHubリンクドキュメントのMarkdownをクリップボードにコピー
Svelte i18nライブラリ - 2026年ベンチマークレポート
このページは、Svelteにおけるi18nソリューションのベンチマークレポートです。
目次
インタラクティブベンチマーク
結果のリファレンス:
完全なベンチマークデータを見る
完全なベンチマークリポジトリはこちらでご覧いただけます。
はじめに
国際化ソリューションは、Svelteアプリにおいて最も重い依存関係の一つです。主なリスクは、不必要なコンテンツ（単一のルートのバンドルに含まれる他のページや他のロケールの翻訳）を送信してしまうことです。
アプリが成長するにつれて、この問題はクライアントに送信されるJavaScriptを急速に増大させ、ナビゲーションを遅くする可能性があります。
実際、最適化が不十分な実装では、国際化されたページがi18nなしのバージョンよりも数倍重くなることがあります。
もう一つの影響は、開発者エクスペリエンス（DX）です。コンテンツの宣言方法、型、名前空間の構成、動的ロード、ロケール変更時の反応性などが含まれます。
TL;DR
- Intlayer: 最もパフォーマンス効率が高く、フットプリントが最も小さい選択肢（v8.7.12）。
- Paraglide: ツリーシェイキング（tree-shaking）の強力な候補ですが、開発者エクスペリエンスがより複雑で、反応性のオーバーヘッドがあります。
- svelte-i18n: Svelte向けの標準的で機能が充実したソリューションですが、バンドル重量が非常に大きくなります（Intlayerの約7倍）。
アプリをテストする
i18nリークの問題を素早く特定するために、無料のスキャナーを用意しました。こちらでお試しいただけます。
問題点
多言語アプリのコストを抑えるためには、2つのレバーが不可欠です。
- ページ/名前空間ごとにコンテンツを分割し、不要な時に辞書全体をロードしないようにする。
- 必要な時にだけ、適切なロケールを動的にロードする。
これらのアプローチの技術的限界を理解する：
動的ロード
動的ロードがない場合、ほとんどのソリューションは最初のレンダリングからメッセージをメモリに保持するため、ルートやロケールが多いアプリでは大きなオーバーヘッドとなります。
動的ロードを使用する場合、トレードオフを受け入れることになります。初期JSは減りますが、言語切り替え時などに追加のリクエストが発生することがあります。
コンテンツの分割
t('a.b.c') を中心に構築された構文は非常に便利ですが、実行時に大きなJSONオブジェクトを保持することを助長しがちです。このモデルでは、ライブラリがページごとの分割戦略を提供していない限り、ツリーシェイキングが難しくなります。
研究方法
このベンチマークでは、以下のライブラリを比較しました。
Base App(i18nライブラリなし)svelte-intlayer(v8.7.12)svelte-i18n(v4.0.1)@inlang/paraglide-js(v2.17.0)
フレームワークは Svelte で、10ページと10言語を持つ多言語アプリを使用しました。
4つのロード戦略を比較しました。
テーブルをモーダルで開き、すべてのデータを明確に表示
| 戦略 | 名前空間なし（グローバル） | 名前空間あり（スコープ） |
|---|---|---|
| 静的ロード | Static: 起動時にすべてをメモリに保持。 | Scoped static: 名前空間で分割。起動時にすべてロード。 |
| 動的ロード | Dynamic: ロケールごとのオンデマンドロード。 | Scoped dynamic: 名前空間とロケールごとの詳細なロード。 |
戦略のまとめ
- 静的（Static）: シンプル。初期ロード後のネットワーク遅延なし。欠点：バンドルサイズが大きい。
- 動的（Dynamic）: 初期重量を削減（遅延ロード）。ロケールが多い場合に理想的。
- 名前空間付き静的（Scoped static）: 複雑な追加リクエストなしで、コードを整理（論理的分離）した状態に保つ。
- 名前空間付き動的（Scoped dynamic）: コード分割とパフォーマンスのための最善のアプローチ。現在のビューとアクティブなロケールに必要なものだけをロードし、メモリ使用量を最小限に抑える。
GitHubのスター
GitHubのスターは、プロジェクトの普及度、コミュニティの信頼、および長期的な関連性を示す強力な指標です。技術的な品質を直接測定するものではありませんが、どれだけの開発者がプロジェクトを有用だと感じ、その進捗をフォローし、採用する可能性があるかを反映しています。プロジェクトの価値を見積もる際、スターは代替案との勢いの比較を助け、エコシステムの成長に関する洞察を提供します。
結果の詳細
1 - 避けるべきソリューション
Svelteエコシステムにおいて、明確に避けるべきソリューションはありません。
2 - 許容できるソリューション
(Paraglide) (@inlang/[email protected]):
Paraglide は革新的でよく考えられたアプローチを提供しています。Vite + Svelte アプリの文脈では、彼らが宣伝しているツリーシェイキングは期待通りに機能しており、素晴らしいことです。
しかし、React + TanStack Start の場合、ツリーシェイキングは期待通りに機能せず、Next.jsでも同様でした。とはいえ、Svelte および TanStack Start プロジェクトにおける Paraglide の使用は再確認する価値があるでしょう。
ワークフローとDXも他のオプションより複雑です。
個人的には、プッシュする前に毎回JSファイルを再生成しなければならないのが好きではありません。これはPRを通じた開発者間の絶え間ないマージコンフリクトのリスクを生みます。また、このツールはNext.jsよりもViteに重点を置いているようです。
最後に、他のソリューションと比較して、Paraglide はコンテンツをレンダリングするための現在のロケールを取得するためにストア（例：Svelte store）を使用しません。パースされる各ノードに対して、localStorage / cookie などからロケールを要求します。これにより、コンポーネントの反応性に影響を与える不要なロジックの実行が発生します。
paraglideに関する注意：このソリューションはインポートのためにコードベースにコードを注入するため、ベンチマークレポートの「ライブラリサイズ（lib size）」メトリックはほぼ0になります。コード生成は、使用される関数に必要なロジック（接頭辞あり vs 接頭辞なし、クッキー vs ストレージなど）のみが含まれるため、良いことです。比較すると、Intlayer はビルド時に環境変数を注入することでこのフィルタリングを行い、ロジックに応じてコンテンツをツリーシェイクするようにバンドラーに強制します。このおかげで、paraglide と intlayer は i18next や next-intl よりも 6〜10倍軽量なソリューションとなります。
(svelte-i18n) ([email protected]):
このソリューションは、Svelteプロジェクトにおけるi18nのすべてのニーズに応えます。しかし、i18nextや他の主要なi18nソリューションと同様に、少し重いです（~15.9kb。これは svelte-intlayer の約7倍です）。
3 - 推奨事項
(Intlayer) ([email protected]):
客観性を保つため、svelte-intlayer については私自身のソリューションであるため、個人的な評価は控えます。
個人メモ
このメモは個人的なものであり、ベンチマーク結果には影響しません。それでも、i18nの世界では翻訳されたコンテンツに対して const t = useTranslation('xx') + <>{t('xx.xx')}</> のようなパターンが一般的です。
Svelteアプリにおいて、関数を Slot として注入することは、私の考えではアンチパターンです。また、回避可能な複雑さとJavaScriptの実行オーバーヘッド（たとえほとんど目立たなくても）を追加することになります。