Pustaka i18n Solid - Laporan Benchmark 2026

Halaman ini adalah laporan benchmark untuk solusi i18n pada Solid.

Daftar Isi

Benchmark Interaktif

Referensi hasil:

Pendahuluan

Solusi internasionalisasi adalah salah satu dependensi terberat dalam aplikasi Solid. Risiko utamanya adalah mengirimkan konten yang tidak perlu: terjemahan untuk halaman lain dan bahasa lain dalam satu bundle rute.

Seiring berkembangnya aplikasi Anda, masalah tersebut dapat dengan cepat membengkak JavaScript yang dikirim ke klien dan memperlambat navigasi.

Dalam praktiknya, untuk implementasi yang paling tidak dioptimalkan, halaman yang diinternasionalisasi bisa berakhir beberapa kali lebih berat daripada versi tanpa i18n.

Dampak lainnya adalah pada pengalaman pengembang (DX): bagaimana Anda mendeklarasikan konten, tipe data, organisasi namespace, pemuatan dinamis, dan reaktivitas saat bahasa berubah.

Untuk memahami asal-usul pustaka-pustaka ini, baca sejarah i18n di JavaScript.

TL;DR

• Intlayer: Pilihan yang direkomendasikan untuk aplikasi Solid profesional yang membutuhkan fitur canggih dan optimasi (v9.5.10).
• @solid-primitives/i18n: Alternatif ringan yang sangat baik untuk proyek sederhana, meskipun tidak memiliki fitur canggih seperti lazy loading.
• solid-i18next: Opsi standar tetapi berat (~3.5× Intlayer) dengan kelemahan yang sama seperti React i18next.
• Tolgee: Platform penerjemahan kaya fitur, tetapi cukup berat (~12.7kb, sekitar 3.0× Intlayer), tidak memiliki primitif Solid khusus (bergantung pada @tolgee/web), dan pada pengaturan statis dapat membocorkan terjemahan antar halaman (90% kebocoran halaman).
• Paraglide: Pendekatan inovatif tetapi DX yang kompleks dan masalah tree-shaking di beberapa pengaturan.

Uji aplikasi Anda

Untuk mendeteksi masalah kebocoran i18n dengan cepat, Anda dapat mencoba pemindai SEO i18n gratis.

Masalahnya

Dua tuas sangat penting untuk membatasi biaya aplikasi multibahasa:

• Pisahkan konten berdasarkan halaman / namespace agar Anda tidak memuat seluruh kamus saat tidak dibutuhkan.
• Muat bahasa yang tepat secara dinamis, hanya saat dibutuhkan.

Memahami batasan teknis dari pendekatan ini:

Pemuatan dinamis

Tanpa pemuatan dinamis, sebagian besar solusi menyimpan pesan dalam memori sejak render pertama, yang menambah overhead signifikan untuk aplikasi dengan banyak rute dan bahasa.

Dengan pemuatan dinamis, Anda menerima kompromi: JS awal yang lebih sedikit, tetapi terkadang permintaan ekstra saat mengganti bahasa.

Pemisahan konten (Splitting)

Sintaks yang dibangun di sekitar t('a.b.c') sangat nyaman tetapi sering kali mendorong penyimpanan objek JSON besar saat runtime. Model tersebut membuat tree-shaking sulit kecuali pustaka menawarkan strategi pemisahan per halaman yang nyata.

Metodologi Penelitian

Untuk benchmark ini, kami membandingkan pustaka berikut:

• Base App (Tanpa pustaka i18n)
• solid-intlayer (v9.5.10)
• @solid-primitives/i18n (v2.2.1)
• i18next (v26.0.8) + @mbarzda/solid-i18next (v1.4.1)
• @tolgee/web (v7.2.0)
• @inlang/paraglide-js (v2.25.1)

Framework yang digunakan adalah Solid dengan aplikasi multibahasa yang terdiri dari 10 halaman dan 10 bahasa.

Kami membandingkan empat strategi pemuatan:

Ringkasan strategi

• Static: Sederhana; tidak ada latensi jaringan setelah pemuatan awal. Kekurangan: ukuran bundle besar.
• Dynamic: Mengurangi beban awal (lazy-loading). Ideal bila Anda memiliki banyak bahasa.
• Scoped static: Menjaga kode tetap teratur (pemisahan logis) tanpa permintaan jaringan ekstra yang kompleks.
• Scoped dynamic: Pendekatan terbaik untuk code splitting dan performa. Meminimalkan memori dengan hanya memuat apa yang dibutuhkan oleh tampilan saat ini dan bahasa yang aktif.

Apa yang saya ukur:

Saya menjalankan aplikasi multibahasa yang sama di browser nyata untuk setiap stack, kemudian mencatat apa yang benar-benar muncul di wire dan berapa lama waktu yang dibutuhkan. Ukuran dilaporkan setelah kompresi web normal, karena itu lebih dekat dengan apa yang orang-orang unduh daripada penghitungan sumber mentah.

• Ukuran library internationalization: Setelah bundling, tree-shaking dan minification, ukuran library i18n adalah ukuran providers + hooks/primitives code dalam komponen kosong. Ini tidak termasuk loading file terjemahan. Ini menjawab betapa mahalnya library sebelum konten Anda memasuki gambar.

• JavaScript per halaman: Untuk setiap rute benchmark, berapa banyak script yang browser tarik untuk kunjungan itu, rata-rata di seluruh halaman dalam suite (dan di seluruh locale di mana laporan menggabungkannya). Halaman berat adalah halaman lambat.

• Leakage dari locale lain: Ini adalah konten halaman yang sama tetapi dalam bahasa lain yang akan dimuat secara tidak disengaja di halaman yang diaudit. Konten ini tidak perlu dan harus dihindari. (mis. konten halaman /fr/about dalam bundle halaman /en/about)

• Leakage dari rute lain: Ide yang sama untuk layar lain dalam aplikasi: apakah salinannya berjalan bersama saat Anda hanya membuka satu halaman. (mis. konten halaman /en/about dalam bundle halaman /en/contact). Skor tinggi menunjukkan splitting yang lemah atau bundle yang terlalu luas.

• Ukuran bundle komponen rata-rata: Piece UI umum diukur satu per satu alih-alih menyembunyikan dalam satu angka aplikasi raksasa. Ini menunjukkan apakah internationalization diam-diam mengobarkan komponen sehari-hari. Misalnya, jika komponen Anda di-rerender, itu akan memuat semua data itu dari memori. Melampirkan JSON besar ke komponen apa pun seperti menghubungkan toko besar data yang tidak digunakan yang akan memperlambat kinerja komponen Anda.

• Responsivitas pengalihan bahasa: Saya membalik bahasa menggunakan kontrol aplikasi sendiri dan mencatat berapa lama waktu yang dibutuhkan sampai halaman jelas beralih, apa yang akan diperhatikan pengunjung, bukan langkah mikro lab.

• Rendering work setelah perubahan bahasa: Tindak lanjut yang lebih sempit: berapa banyak upaya yang diambil interface untuk repaint untuk bahasa baru setelah switch dalam penerbangan. Berguna ketika waktu "terasa" dan biaya framework berbeda.

• Waktu loading halaman awal: Dari navigasi ke browser mempertimbangkan halaman sepenuhnya dimuat untuk skenario yang saya uji. Baik untuk membandingkan cold start.

• Waktu hydration: Ketika aplikasi mengeksposnya, berapa lama client menghabiskan waktu mengubah server HTML menjadi sesuatu yang benar-benar dapat Anda klik. Dash dalam tabel berarti implementasi itu tidak memberikan angka hydration yang andal dalam benchmark ini.

Bintang GitHub

Bintang GitHub adalah indikator kuat dari popularitas proyek, kepercayaan komunitas, dan relevansi jangka panjang. Meskipun bukan ukuran langsung dari kualitas teknis, bintang-bintang tersebut mencerminkan berapa banyak pengembang yang menganggap proyek tersebut berguna, mengikuti kemajuannya, dan kemungkinan akan mengadopsinya. Untuk memperkirakan nilai suatu proyek, bintang membantu membandingkan daya tarik di berbagai alternatif dan memberikan wawasan tentang pertumbuhan ekosistem.

Aktivitas commit

Bintang menunjukkan popularitas. Commit menunjukkan seberapa banyak kerja yang masuk ke sebuah proyek. Saat tulisan ini dibuat, Intlayer memiliki sekitar 7.500 commit, lebih banyak dari sebagian besar library yang dibandingkan di sini, dan sekitar 5 kali lebih banyak dari next-intl atau next-i18next.

Intlayer adalah monorepo, jadi jumlah ini mencakup setiap paket framework, CLI, dan dokumentasi. Baca commit sebagai sinyal aktivitas, bukan kualitas.

Unduhan npm

Jumlah unduhan menghargai solusi yang paling lama, bukan yang terbaik. Library yang dirilis bertahun-tahun lalu masih diinstal oleh setiap proyek yang memilihnya saat itu, oleh setiap eksekusi CI, dan oleh setiap paket yang bergantung padanya. Angka ini lebih mengukur inersia daripada pilihan baru.

Asisten AI memperkuat efek ini. next-intl, i18next, dan vue-i18n ada di mana-mana dalam kode yang menjadi data latih mereka, sehingga mereka menyarankannya secara default tanpa membandingkan alternatif. Setiap saran menambah unduhan, yang kemudian mendorong saran berikutnya. Bandingkan berdasarkan benchmark, bukan jumlah unduhan.

Hasil secara mendetail

1 - Solusi yang harus dihindari

Tidak ada solusi yang jelas untuk dihindari dalam ekosistem Solid.

2 - Solusi yang dapat diterima

(solid-i18next) (i18next@26.0.8):

solid-i18next mungkin merupakan opsi yang paling populer karena merupakan salah satu yang pertama memenuhi kebutuhan i18n aplikasi JavaScript. Ia juga memiliki serangkaian plugin komunitas yang luas untuk masalah tertentu.

Paketnya berat (~14.9kb, yang mana sekitar 3.5× solid-intlayer).

Namun, ia memiliki kelemahan utama yang sama dengan stack yang dibangun di atas t('a.b.c'): optimasi dimungkinkan tetapi sangat memakan waktu, dan proyek besar berisiko terkena praktik buruk (namespace + pemuatan dinamis + tipe).

(@solid-primitives/i18n) (@solid-primitives/i18n@2.2.1):

Solid primitive sangat ringan dan efisien. Saya merekomendasikan solusi tersebut untuk proyek ringan, tetapi fitur-fiturnya mungkin cepat terasa kurang untuk solusi profesional yang mencakup manajemen cookie, pengalihan proxy, formatter, dll. Ia juga tidak memiliki lazy loading dan scoping namespace untuk optimasi ukuran halaman.

(Tolgee) (@tolgee/web@7.2.0):

Tolgee menyediakan platform manajemen terjemahan yang kaya fitur dengan kemampuan pengeditan in-context.

Pada Solid, saat ini belum ada adaptor bawaan resmi (seperti @tolgee/solid), sehingga pengembang harus berintegrasi melalui @tolgee/web dengan sinyal kustom.

Paket ini relatif berat (~12.7kb, sekitar 3.0× solid-intlayer).

Tanpa mekanisme pemisahan per halaman yang terperinci di Solid, semua terjemahan dimuat ke memori di awal dalam pengaturan statis. Hal ini menyebabkan kebocoran bundel yang tinggi (kebocoran lokal 44.5%, kebocoran halaman 90.0%) dan ukuran bundel halaman rata-rata ~91.8kb (dibandingkan dengan ~35.4kb untuk Intlayer).

Responsivitas peralihan bahasa sangat cepat (0.6ms), selaras dengan reaktivitas Solid yang halus, meskipun overhead hidrasi sedikit lebih tinggi (~5.6ms vs ~2.9ms untuk Intlayer).

(Paraglide) (@inlang/paraglide-js@2.25.1):

Paraglide menawarkan pendekatan yang inovatif dan dipikirkan dengan matang. Meskipun demikian, dalam benchmark ini, tree-shaking yang diiklankan perusahaan mereka tidak berhasil untuk implementasi saya. Alur kerja dan DX juga lebih kompleks daripada opsi lainnya. Secara pribadi saya tidak suka harus meregenerasi file JS sebelum setiap push, yang menciptakan risiko konflik merge yang konstan melalui PR. Terakhir, dibandingkan dengan solusi lain, Paraglide tidak menggunakan store (misalnya Solid signal) untuk mengambil locale saat ini guna merender konten. Untuk setiap node yang di-parse, ia akan meminta locale dari localStorage / cookie dll. Hal ini menyebabkan eksekusi logika yang tidak perlu yang berdampak pada reaktivitas komponen.

3 - Rekomendasi

(Intlayer) (solid-intlayer@9.5.10):

Saya tidak akan menilai solid-intlayer secara pribadi demi objektivitas, karena ini adalah solusi saya sendiri.

Catatan pribadi

Catatan ini bersifat pribadi dan tidak memengaruhi hasil benchmark. Namun, di dunia i18n Anda sering melihat konsensus seputar pola seperti const t = useTranslation('xx') + <>{t('xx.xx')}</> untuk konten terjemahan.

Dalam aplikasi Solid, menginjeksi fungsi sebagai JSX.Element menurut pandangan saya adalah sebuah anti-pattern. Hal ini juga menambah kompleksitas yang dapat dihindari dan overhead eksekusi JavaScript (meskipun hampir tidak terlihat).