基準測試與效能
本基準測試參考了 paraglide-js benchmark 的測試架構，模擬現代多語言 Web 應用在首頁預先渲染並完成客戶端注水（Hydration）時，使用者端實際承載的全部國際化資源（HTML + 執行階段程式碼 + 語言包）的真實網路傳輸體積。
情境說明：在純靜態頁面（Zero-JS MPA）中，伺服端直接輸出翻譯好的 HTML，客戶端無需載入任何 i18n 程式碼；本測試針對的是具備客戶端注水、動態互動（如表單驗證、即時文案提示）與客戶端路由能力之現代全端應用，測量首頁達到可互動狀態所下載的靜態資源總開銷。
評估的程式庫與設定模式包含：
ts-intl（輕量執行階段）：測試default（全語言全量打包）與locale-splitting（語言分塊隨需載入）兩種配置。paraglide（編譯型方案）：測試default（編譯函式全語言打包）與experimental-middleware-locale-splitting（路由中介軟體隨需拆包）兩種配置。i18next（傳統執行階段）：測試default（全語言 JSON 打包）與http-backend（客戶端非同步 fetch）兩種配置。
傳輸體積比較圖表
以下數據透過 Playwright 無頭 Chromium 造訪頁面，統計網路閒置（networkidle）前所有成功的 HTTP 靜態回應傳輸體積總和（Transfer Size）：
首頁網路傳輸大小 (KB)
Playwright Headless Chromium · Real HTTP Transfer Size
paraglide中介軟體分割
-91%36.3 KB
ts-intl隨需分割
-86%57.8 KB
paraglide預設全量
-82%76.6 KB
i18nextHTTP 動態載入
-55%188.7 KB
ts-intl預設全量
-14%360.0 KB
i18next預設全量
Baseline420.4 KB
基準測試數據矩陣
測試基準負載：首頁渲染 100 條文案（20% 包含動態變數插值）。
情境一：規模化應用（10 種語言 · 命名空間共 500 詞條）
在此情境中，詞典總共包含 500 條詞條，頁面實際引用並渲染其中 100 條：
| 程式庫與打包模式 | 首頁傳輸體積 | 對比 i18next 預設 | 機制特點 |
|---|---|---|---|
| paraglide (中介軟體拆包) | 36.3 KB | -91.4% | 編譯為獨立 JS 函式，Tree-shaking 剔除未引用詞條，隨需分發 |
| ts-intl (隨需拆包) | 57.8 KB | -86.2% | 核心執行階段約 2 KB，僅載入目前語言 500 條詞條 JSON |
| paraglide (預設全量) | 76.6 KB | -81.8% | Tree-shaking 剔除未引用詞條，但合併打包 10 種語言編譯產物 |
| i18next (HTTP 動態載入) | 188.7 KB | -55.1% | 客戶端非同步請求目前語言 JSON，附帶完整基礎執行時期 |
| ts-intl (預設全量) | 360.0 KB | -14.4% | 合併打包 10 種語言全部 500 條詞條 JSON |
| i18next (預設全量) | 420.4 KB | 基準線 (Baseline) | 合併打包 10 種語言全部 500 條詞條 JSON 與完整執行時期程式庫 |
情境二：輕量入門（5 種語言 · 命名空間共 100 詞條）
在此情境中，詞典共包含 100 條詞條，頁面渲染全部 100 條：
| 程式庫與打包模式 | 首頁傳輸體積 | 對比 i18next 預設 | 機制特點 |
|---|---|---|---|
| ts-intl (隨需拆包) | 29.7 KB | -83.8% | 核心執行階段約 2 KB，僅載入目前語言 100 條詞條 JSON |
| paraglide (中介軟體拆包) | 36.1 KB | -80.3% | 僅分發目前語言 100 條詞條編譯函式 |
| paraglide (預設全量) | 47.1 KB | -74.3% | 合併打包 5 種語言 100 條詞條編譯函式 |
| ts-intl (預設全量) | 56.9 KB | -69.0% | 合併打包 5 種語言 100 條詞條 JSON |
| i18next (HTTP 動態載入) | 167.5 KB | -8.6% | 客戶端非同步請求目前語言 JSON，附帶完整基礎執行時期 |
| i18next (預設全量) | 183.3 KB | 基準線 (Baseline) | 合併打包 5 種語言 100 條詞條 JSON 與完整執行時期程式庫 |
技術架構與體積構成分析
1. 編譯型方案的 Tree-shaking 優勢與權衡
- 優勢：
paraglide將每條翻譯訊息編譯為單獨匯出的 JavaScript 函式。在打包時，打包工具（如 Rollup / esbuild）能夠識別程式碼中未引用的函式並予以清除（Tree-shaking）。在情境一中，500 條詞條中未使用的 400 條未被打包進產出物，因此體積最小（36.3 KB）。 - 權衡：需要專屬的建置步驟（編譯生成 TS/JS 原始碼），不支援動態遠端熱更新字典檔案。
2. 輕量執行階段方案的隨需拆包優勢
- 無需程式碼生成：
ts-intl是純 TypeScript 執行時期程式庫，無需程式碼生成步驟，直接使用標準 TypeScript 物件或 JSON 檔案。 - 語言數量線性無關：在
locale-splitting模式下，利用打包工具的動態匯入（Dynamicimport()）特性，不同語言的詞典被自動分塊。客戶端僅下載目前啟用的語言分塊，因此當專案支援的語言數量由 5 種增加至 10+ 種時，單頁首頁網路傳輸體積基本保持恆定（約 30 KB ~ 57 KB）。 - 零外部執行階段相依：
ts-intl核心執行階段壓縮後僅約 2 KB，底層直接利用瀏覽器標準的 WebIntlAPI 處理複數與數字日期格式，避免攜帶大型解析引擎。
3. 傳統執行時期的體積膨脹成因
i18next自身包含豐富的配置系統、事件發送器、AST 解析器及自訂格式化工具，基礎執行程式庫體積較大。- 在常規配置下，開發者常透過靜態
import將各語言資源整體匯入主進入點，導致所有語言詞典無論是否使用均被打包到客戶端主 chunk 中。
本地重現基準測試
基準測試套件原始碼位於 apps/benchmark。可透過以下步驟在本地執行重現：
# 1. 安裝測試所需的 Chromium（僅首次執行）
pnpm --filter @aaakul/ts-intl-benchmark prebench
# 2. 執行完整基準測試矩陣（自動完成 SSG 建置並透過 Playwright 取樣）
pnpm --filter @aaakul/ts-intl-benchmark bench
# 3. 啟動本機預覽伺服器（可在 http://localhost:3005 造訪視覺化結果）
pnpm --filter @aaakul/ts-intl-benchmark preview