Thư viện i18n cho Svelte - Báo cáo Benchmark 2026

Trang này là báo cáo benchmark cho các giải pháp i18n trên Svelte.

Mục lục

Benchmark tương tác

Tham chiếu kết quả:

Xem dữ liệu benchmark đầy đủ

Xem toàn bộ kho lưu trữ benchmark tại đây.

Giới thiệu

Các giải pháp quốc tế hóa là một trong những phụ thuộc nặng nhất trong một ứng dụng Svelte. Rủi ro chính là việc gửi nội dung không cần thiết: bản dịch cho các trang khác và các ngôn ngữ khác trong bundle của một route duy nhất.

Khi ứng dụng của bạn phát triển, vấn đề đó có thể nhanh chóng làm bùng nổ lượng JavaScript gửi đến client và làm chậm quá trình điều hướng.

Trong thực tế, đối với các triển khai ít được tối ưu hóa nhất, một trang quốc tế hóa có thể nặng hơn gấp nhiều lần so với phiên bản không có i18n.

Tác động khác là đối với trải nghiệm nhà phát triển (DX): cách bạn khai báo nội dung, kiểu (types), tổ chức namespace, tải động và tính phản ứng khi thay đổi ngôn ngữ.

TL;DR

• Intlayer: Lựa chọn hiệu quả nhất về hiệu suất (v8.7.12) với dấu chân (footprint) nhỏ nhất.
• Paraglide: Đối thủ nặng ký cho tree-shaking nhưng có trải nghiệm nhà phát triển phức tạp hơn và overhead về tính phản ứng.
• svelte-i18n: Toàn diện và tiêu chuẩn cho Svelte, nhưng mang trọng lượng bundle lớn hơn nhiều (~7 lần Intlayer).

Kiểm tra ứng dụng của bạn

Để nhanh chóng phát hiện các vấn đề rò rỉ i18n, tôi đã thiết lập một trình quét miễn phí có sẵn tại đây.

Vấn đề

Hai đòn bẩy là thiết yếu để hạn chế chi phí của một ứng dụng đa ngôn ngữ:

• Chia nhỏ nội dung theo trang / namespace để bạn không tải toàn bộ từ điển khi không cần thiết.
• Tải ngôn ngữ chính xác một cách linh hoạt, chỉ khi cần thiết.

Hiểu các hạn chế kỹ thuật của các phương pháp này:

Tải động (Dynamic loading)

Nếu không có tải động, hầu hết các giải pháp giữ tin nhắn trong bộ nhớ từ lần render đầu tiên, điều này làm tăng đáng kể overhead cho các ứng dụng có nhiều route và ngôn ngữ.

Với tải động, bạn chấp nhận một sự đánh đổi: ít JS ban đầu hơn, nhưng đôi khi có thêm một request khi chuyển đổi ngôn ngữ.

Chia tách nội dung (Splitting)

Các cú pháp được xây dựng xung quanh t('a.b.c') rất tiện lợi nhưng thường khuyến khích giữ các đối tượng JSON lớn khi runtime. Mô hình đó làm cho tree-shaking trở nên khó khăn trừ khi thư viện cung cấp một chiến lược chia tách thực sự theo từng trang.

Phương pháp nghiên cứu

Đối với benchmark này, chúng tôi đã so sánh các thư viện sau:

• Base App (Không có thư viện i18n)
• svelte-intlayer (v8.7.12)
• svelte-i18n (v4.0.1)
• @inlang/paraglide-js (v2.17.0)

Framework là Svelte với một ứng dụng đa ngôn ngữ gồm 10 trang và 10 ngôn ngữ.

Chúng tôi đã so sánh bốn chiến lược tải:

Tóm tắt chiến lược

• Static: Đơn giản; không có độ trễ mạng sau lần tải đầu tiên. Nhược điểm: kích thước bundle lớn.
• Dynamic: Giảm trọng lượng ban đầu (lazy-loading). Lý tưởng khi bạn có nhiều ngôn ngữ.
• Scoped static: Giữ cho mã được tổ chức (tách biệt logic) mà không cần các request mạng bổ sung phức tạp.
• Scoped dynamic: Phương pháp tốt nhất cho code splitting và hiệu suất. Giảm thiểu bộ nhớ bằng cách chỉ tải những gì chế độ xem hiện tại và ngôn ngữ đang hoạt động cần.

Sao GitHub

Sao GitHub là một chỉ số mạnh mẽ về mức độ phổ biến của dự án, sự tin tưởng của cộng đồng và mức độ phù hợp lâu dài. Mặc dù không phải là thước đo trực tiếp về chất lượng kỹ thuật, chúng phản ánh số lượng nhà phát triển thấy dự án hữu ích, theo dõi tiến trình của nó và có khả năng áp dụng nó. Để ước tính giá trị của một dự án, các ngôi sao giúp so sánh sức hút giữa các lựa chọn thay thế và cung cấp thông tin chi tiết về sự phát triển của hệ sinh thái.

Kết quả chi tiết

1 - Các giải pháp cần tránh

Không có giải pháp rõ ràng nào cần tránh trong hệ sinh thái Svelte.

2 - Các giải pháp chấp nhận được

(Paraglide) (@inlang/[email protected]):

Paraglide đưa ra một cách tiếp cận sáng tạo, được cân nhắc kỹ lưỡng. Trong ngữ cảnh của một ứng dụng Vite + Svelte, tree-shaking mà công ty họ quảng cáo hoạt động như mong đợi, điều này thật tuyệt vời. Nhưng trong trường hợp React + TanStack Start, tree-shaking không hoạt động như mong đợi, Next.js cũng vậy. Điều đó có nghĩa là, việc sử dụng Paraglide trong một dự án Svelte và TanStack Start sẽ đáng để kiểm tra lại. Workflow và DX cũng phức tạp hơn các tùy chọn khác. Cá nhân tôi không thích việc phải tạo lại các file JS trước mỗi lần push, điều này tạo ra rủi ro xung đột merge liên tục thông qua các PR. Công cụ này dường như cũng tập trung vào Vite hơn là Next.js. Cuối cùng, so với các giải pháp khác, Paraglide không sử dụng store (ví dụ: Svelte store) để truy xuất ngôn ngữ hiện tại để render nội dung. Đối với mỗi node được phân tích cú pháp, nó sẽ yêu cầu ngôn ngữ từ localStorage / cookie, v.v. Nó dẫn đến việc thực thi logic không cần thiết ảnh hưởng đến tính phản ứng của component.

Lưu ý về paraglide: giải pháp này đưa mã vào mã nguồn của bạn cho các import; do đó, chỉ số 'lib size' trong báo cáo benchmark gần như bằng 0. Việc tạo mã (Code generation) là một điều tốt, bởi vì hàm được sử dụng sẽ chỉ bao gồm logic cần thiết (prefix ở mọi nơi so với không prefix, cookie so với storage, v.v.). So với đó, Intlayer thực hiện việc lọc này thông qua việc đưa biến môi trường vào build để buộc bundler thực hiện tree-shaking nội dung tùy thuộc vào logic. Nhờ đó, paraglide và intlayer cuối cùng là các giải pháp nhẹ hơn từ 6 đến 10 lần so với i18next hoặc next-intl.

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

Giải pháp này đáp ứng tất cả các nhu cầu i18n trong một dự án Svelte. Nhưng giống như trường hợp của i18next hoặc các giải pháp i18n lớn khác, nó hơi nặng (~15.9kb, gấp khoảng 7 lần svelte-intlayer).

3 - Khuyến nghị

(Intlayer) ([email protected]):

Tôi sẽ không đích thân đánh giá svelte-intlayer vì tính khách quan, vì đó là giải pháp của chính tôi.

Ghi chú cá nhân

Ghi chú này mang tính cá nhân và không ảnh hưởng đến kết quả benchmark. Tuy nhiên, trong thế giới i18n, bạn thường thấy sự đồng thuận xung quanh một mẫu như const t = useTranslation('xx') + <>{t('xx.xx')}</> cho nội dung được dịch.

Trong các ứng dụng Svelte, việc đưa một hàm vào như một Slot theo quan điểm của tôi là một anti-pattern. Nó cũng thêm vào sự phức tạp có thể tránh được và overhead thực thi JavaScript (ngay cả khi nó khó nhận thấy).