@intlayer/docs 9.5.6 → 9.5.8

package/blog/id/i18next_vs_intlayer.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "i18next vs Intlayer: Benchmark & Perbandingan 2026"
 description: "react-i18next dan next-i18next diuji terhadap Intlayer pada Next.js dan TanStack Start. Ukuran bundle, kebocoran konten, responsivitas pergantian bahasa, dan pengalaman pengembang."
 keywords:
@@ -25,6 +25,8 @@ author: aymericzip
 
 # i18next VS Intlayer | Benchmark Internasionalisasi (i18n) React & Next.js
 
+![i18next VS Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18next-next-intl-intlayer.webp?raw=true)
+
 `i18next` adalah framework i18n yang paling banyak digunakan dalam ekosistem JavaScript. Melalui `react-i18next` dan `next-i18next`, library ini mendukung sebagian besar aplikasi React dan Next.js. Intlayer hadir sebagai alternatif modern berbasis kompilator dengan cakupan konten per komponen.
 
 Artikel ini membandingkan keduanya berdasarkan pengukuran riil, bukan sekadar daftar fitur. Angka-angka ini diperoleh dari [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom), sebuah suite pengujian sumber terbuka yang membangun aplikasi yang sama persis dengan masing-masing library dan mencatat data yang diunduh oleh peramban secara akurat.
@@ -99,6 +101,10 @@ Metrik yang dicatat untuk setiap build:
 
 ### Hasil pada Next.js (`next-i18next`)
 
+Pilih metrik dan pustaka yang Anda minati:
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | Library                           | Strategi       | Lib size (gz) | Page JS avg (gz) | Kebocoran Bahasa | Kebocoran Halaman | Rata-rata Komp. (gz) | Reaktivitas E2E | Hydration |
 | --------------------------------- | -------------- | ------------: | ---------------: | ---------------: | ----------------: | -------------------: | --------------: | --------: |
 | **base** (tanpa i18n)             | -              |        0.0 KB |         141.0 KB |             0.0% |              0.0% |               0.9 KB |         13.4 ms |   11.8 ms |
@@ -119,6 +125,15 @@ Metrik yang dicatat untuk setiap build:
 - **Ukuran per komponen**: Komponen yang memanggil `useTranslation()` menghasilkan ukuran 26-79 KB; komponen yang sama dengan `useIntlayer()` hanya berukuran 6.9 KB.
 - **Waktu hidrasi**: Pada konfigurasi `dynamic`, waktu hidrasi melonjak menjadi 27.7 ms karena instance i18next harus diinisialisasi dan meminta data backend di sisi klien sebelum React dapat menyelesaikan hidrasi.
 
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-nextjs.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> Tabel lengkap, setiap pustaka dan setiap strategi, ada di [laporan benchmark Next.js](https://intlayer.org/id/doc/benchmark/nextjs).
+
 ### Hasil pada TanStack Start (`react-i18next`)
 
 Aplikasi yang sama pada TanStack Start dengan `react-i18next` murni untuk memisahkan faktor arsitektur Next.js:
@@ -141,8 +156,19 @@ Aplikasi yang sama pada TanStack Start dengan `react-i18next` murni untuk memisa
 - Mode `static` pada Intlayer secara bawaan memiliki **0% kebocoran halaman** karena hanya kamus yang diimpor oleh komponen halaman tersebut yang dimasukkan ke bundle. Mengaktifkan `importMode: 'dynamic'` juga langsung meniadakan kebocoran bahasa.
 - **Ukuran per komponen**: 24-27 KB pada `react-i18next` berbanding 6-8 KB pada Intlayer. `useTranslation()` mengikat setiap komponen ke instance global i18next.
 
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-tanstack.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> Tabel lengkap ada di [laporan benchmark TanStack Start](https://intlayer.org/id/doc/benchmark/tanstack).
+
 ## Mengapa Perbedaannya Begitu Nyata? Global Instance vs Kamus Terkompilasi
 
+![Centralized catalogs versus per-component dictionaries](https://github.com/aymericzip/intlayer/blob/main/docs/assets/project_stucture_18n_vs_intlayer.png?raw=true)
+
 `i18next` dirancang pada tahun 2012 sebagai pustaka runtime: Satu instance global menyimpan data teks, serangkaian plugin memperluas fungsinya, dan fungsi `t()` mencari kunci saat perenderan. Pola ini sangat fleksibel namun memicu penumpukan ukuran:
 
 ```bash
@@ -166,7 +192,13 @@ Aplikasi yang sama pada TanStack Start dengan `react-i18next` murni untuk memisa
                 └── page.tsx     # harus tahu bahwa halaman ini membutuhkan ["common", "about"]
 ```
 
-Instance global tidak dapat mengetahui kunci apa saja yang akan dipanggil oleh suatu komponen; sehingga ia menampung seluruh namespace yang diminta. Mengoptimalkannya berarti **Anda** harus membagi file, **Anda** harus mencatat namespace yang dibutuhkan setiap halaman, dan **Anda** harus memperbaruinya saat ada komponen yang dipindahkan. Seperti dikutip dalam [laporan benchmark](https://github.com/intlayer-org/benchmark-bloom/blob/main/report/NOTE.md): "Menjaga keamanan tipe data sambil memastikan namespace mana yang harus disertakan di setiap halaman adalah mimpi buruk".
+Instance global tidak dapat mengetahui kunci apa saja yang akan dipanggil oleh suatu komponen; sehingga ia menampung seluruh namespace yang diminta. Mengoptimalkannya berarti **Anda** harus membagi file, **Anda** harus mencatat namespace yang dibutuhkan setiap halaman, dan **Anda** harus memperbaruinya saat ada komponen yang dipindahkan.
+
+Biaya membengkak pada dua sumbu sekaligus, halaman dan bahasa:
+
+![Theoretical content leakage by architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
+
+Seperti dikutip dalam [laporan benchmark](https://github.com/intlayer-org/benchmark-bloom/blob/main/report/NOTE.md): "Menjaga keamanan tipe data sambil memastikan namespace mana yang harus disertakan di setiap halaman adalah mimpi buruk".
 
 Intlayer meniadakan instance global tersebut. Konten dideklarasikan langsung di sebelah komponen, dan kompilator menyelesaikan grafik ketergantungan pada fase build:
 
@@ -193,7 +225,8 @@ Intlayer meniadakan instance global tersebut. Konten dideklarasikan langsung di
 
 ### Perbandingan Konfigurasi Awal
 
-**next-i18next (App Router)**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-i18next" value="i18next">
 
 ```ts fileName="src/app/i18n/server.ts"
 import { createInstance } from "i18next";
@@ -228,7 +261,8 @@ export const initI18next = async (
 
 Pengembang juga harus mengelola `I18nProvider` di klien, mengatur `generateStaticParams`, serta mendefinisikan array `namespaces` pada tiap halaman.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="intlayer.config.ts"
 import { type IntlayerConfig, Locales } from "intlayer";
@@ -264,9 +298,13 @@ const LocaleLayout: NextLayoutIntlayer = async ({ children, params }) => {
 export default LocaleLayout;
 ```
 
+</Tab>
+</Tabs>
+
 ### Komponen Klien
 
-**react-i18next**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="react-i18next" value="i18next">
 
 ```json fileName="src/locales/en/about.json"
 {
@@ -304,7 +342,8 @@ export const Counter = () => {
 
 > Halaman yang memuat komponen ini wajib menyertakan namespace `about`, dan `t("counter.label")` hanyalah string biasa tanpa bantuan tipe TypeScript sebelum `CustomTypeOptions` diperluas.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="src/components/Counter/index.content.ts"
 import { t, type Dictionary } from "intlayer";
@@ -345,9 +384,13 @@ export const Counter = () => {
 
 Properti `label` dan `increment` memiliki tipe data yang sangat ketat; kesalahan ketik akan langsung terdeteksi oleh TypeScript dan terjemahan bahasa Prancis yang belum diisi akan menggagalkan proses build.
 
+</Tab>
+</Tabs>
+
 ### Komponen Server Sinkron (RSC)
 
-**next-i18next**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-i18next" value="i18next">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 type ServerCounterProps = {
@@ -366,7 +409,8 @@ export const ServerCounter = ({ t, locale, count }: ServerCounterProps) => (
 
 Halaman harus menjalankan `i18n.getFixedT(locale, "about")` dan meneruskan `t` serta `locale` ke bawah melalui props.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 import { useIntlayer } from "next-intlayer/server";
@@ -385,6 +429,9 @@ export const ServerCounter = ({ count }: { count: number }) => {
 };
 ```
 
+</Tab>
+</Tabs>
+
 ## Gunakan API i18next, Nikmati Keringanan Intlayer
 
 Anda tidak harus menulis ulang komponen yang ada untuk menikmati keuntungan benchmark di atas. Adaptor `@intlayer/i18next`, `@intlayer/react-i18next`, dan `@intlayer/next-i18next` dapat langsung dipasang: pemanggilan `useTranslation`, `t()`, `<Trans>`, dan bentuk jamak tetap berfungsi seperti biasa, disuplai oleh kamus yang dioptimalkan kompilator Intlayer di latar belakang.
@@ -415,18 +462,85 @@ Pelajari panduan migrasinya: [i18next](https://intlayer.org/id/doc/migration/i18
 
 ## Kapan Memilih yang Mana?
 
-- **Pilih i18next**: Jika Anda sangat bergantung pada ekosistem pluginnya (pendeteksi khusus, backend unik, ICU, Locize), menerapkan lokalisasi di luar React (Node services, vanilla JS, framework lain), tim Anda sudah terbiasa, atau sistem penerjemah mengharuskan struktur `locales/{lng}/{ns}.json`. Namun, pastikan Anda menyisihkan waktu untuk mengelola namespace dan rute jika kinerja adalah prioritas.
-- **Pilih Intlayer**: Jika Anda mengutamakan **konten per komponen**, **keamanan tipe TypeScript yang ketat**, **deteksi terjemahan hilang saat build**, **tree-shaking dan lazy loading otomatis tanpa repot**, pergantian bahasa instan, komponen server sinkron, dan alat terintegrasi (Visual Editor, CMS, terjemahan AI, server MCP). Pilihan sempurna untuk aplikasi modular dan design system.
-- **Pilih adaptor `@intlayer/*-i18next`**: Jika proyek Anda sudah berjalan menggunakan i18next dan ingin segera memangkas ukuran bundle serta mempercepat waktu muat tanpa perlu refactoring besar-besaran.
+<AccordionGroup>
+<Accordion header="Pilih i18next">
+
+Jika Anda sangat bergantung pada ekosistem pluginnya (pendeteksi khusus, backend unik, ICU, Locize), menerapkan lokalisasi di luar React (Node services, vanilla JS, framework lain), tim Anda sudah terbiasa, atau sistem penerjemah mengharuskan struktur `locales/{lng}/{ns}.json`. Namun, pastikan Anda menyisihkan waktu untuk mengelola namespace dan rute jika kinerja adalah prioritas.
+
+</Accordion>
+<Accordion header="Pilih Intlayer">
+
+Anda menginginkan **konten berbasis komponen**, **TypeScript yang ketat**, **kesalahan kunci yang hilang saat waktu build**, **tree-shaking dan lazy loading tanpa usaha**, pergantian bahasa instan, komponen server sinkron, dan alat editorial bawaan ([Visual Editor](https://intlayer.org/id/doc/concept/editor), [CMS](https://intlayer.org/id/doc/concept/cms), [terjemahan AI](https://intlayer.org/id/doc/concept/auto-fill), [server MCP](https://intlayer.org/id/doc/mcp-server)). Sangat relevan untuk basis kode modular yang besar dan sistem desain.
+
+</Accordion>
+<Accordion header="Pilih adaptor @intlayer/*-i18next">
+
+Anda sudah menggunakan i18next dan menginginkan efisiensi bundle serta peningkatan reaktivitas tanpa perlu menulis ulang komponen. Berkas `locales/{lng}/{ns}.json` Anda tetap menjadi sumber kebenaran utama. Diukur berdampingan dalam [i18next vs @intlayer/i18next](https://intlayer.org/id/blog/i18next-vs-intlayer-i18next).
+
+</Accordion>
+</AccordionGroup>
+
+## FAQ
+
+<FAQ>
+
+<Question title="Mengapa i18next jauh lebih berat dibandingkan pustaka lainnya?">
+
+Ia dirancang sebagai runtime agnostik framework: instance global, pipeline plugin, repositori sumber daya, resolver kunci. Fleksibilitas tersebut dikompilasi ke dalam setiap bundel. Komponen kosong yang hanya mengimpor pustaka berbobot **19.7 KB gzip** dengan `next-i18next` berbanding **5.5 KB** dengan `next-intlayer`, dan biaya tersebut dibayar pada setiap halaman apa pun isi konten Anda.
+
+</Question>
+
+<Question title="Apakah lazy loading dengan backend memperbaikinya?">
+
+Itu memperbaiki ukuran byte, bukan latensi. Beralih ke `i18next-resources-to-backend` menghemat ~49 KB per halaman tetapi menambahkan round-trip jaringan pada pergantian bahasa: **123 ms** dalam pengaturan `dynamic` dan **185 ms** dalam `scoped-static`, berbanding **3-4 ms** dengan Intlayer. Hidrasi juga melonjak ke 27.7 ms karena instance menyelesaikan backend-nya sebelum React dapat melakukan hidrasi.
+
+</Question>
+
+<Question title="Bisakah saya mencapai 0% kebocoran konten dengan i18next?">
+
+Bisa, dengan `scoped-dynamic`: satu namespace per rute, backend sumber daya, dan pemetaan halaman ke namespace yang dikelola secara manual. Ini menghasilkan 163.4 KB per halaman di Next.js, masih **+22 KB** lebih besar daripada 141.3 KB milik Intlayer yang tidak memerlukan konfigurasi tambahan. Lihat [optimasi bundel](https://intlayer.org/id/doc/concept/bundle-optimization).
+
+</Question>
+
+<Question title="Apakah saya harus menulis ulang komponen untuk bermigrasi?">
+
+Tidak. `@intlayer/i18next`, `@intlayer/react-i18next`, dan `@intlayer/next-i18next` mempertahankan `useTranslation`, `t()`, `<Trans>`, `{{interpolation}}`, bentuk jamak `_one` / `_other`, sufiks konteks, dan `returnObjects`. Cukup satu baris plugin di `next.config.ts` atau `vite.config.ts`. Panduan langkah demi langkah ada di [panduan migrasi next-i18next](https://intlayer.org/id/doc/migration/next-i18next).
+
+</Question>
+
+<Question title="Apa yang terjadi pada plugin i18next saya?">
+
+Backend dan pendeteksi bahasa tetap diterima tetapi menjadi tidak aktif: tidak ada lagi yang perlu dimuat atau dideteksi saat runtime. Deteksi bahasa menjadi konfigurasi routing Intlayer (awalan URL, cookie, header). Jika aplikasi Anda mengambil terjemahan dari CMS saat permintaan tiba, gunakan [Intlayer CMS](https://intlayer.org/id/doc/concept/cms) atau perintah `intlayer pull` / `push` sebagai gantinya.
+
+</Question>
+
+</FAQ>
 
 ## Perbandingan Terkait
 
-- [next-intl vs Intlayer](https://intlayer.org/id/blog/next-intl-vs-intlayer) (benchmark yang sama)
-- [Lingui vs Intlayer](https://intlayer.org/id/blog/lingui-vs-intlayer) (benchmark yang sama)
-- [vue-i18n vs Intlayer benchmark](https://intlayer.org/id/blog/vue-i18n-vs-intlayer-benchmark) (benchmark yang sama)
+Benchmark yang sama, pustaka lain:
+
+- [next-intl vs Intlayer](https://intlayer.org/id/blog/next-intl-vs-intlayer)
+- [Lingui vs Intlayer](https://intlayer.org/id/blog/lingui-vs-intlayer)
+- [vue-i18n vs Intlayer benchmark](https://intlayer.org/id/blog/vue-i18n-vs-intlayer-benchmark)
 - [next-i18next vs next-intl vs Intlayer](https://intlayer.org/id/blog/next-i18next-vs-next-intl-vs-intlayer)
 - [react-i18next vs react-intl vs Intlayer](https://intlayer.org/id/blog/react-i18next-vs-react-intl-vs-intlayer)
+
+Mendalami i18next lebih lanjut:
+
+- [i18next vs @intlayer/i18next](https://intlayer.org/id/blog/i18next-vs-intlayer-i18next), perbandingan adaptor yang diukur pada aplikasi yang sama
 - [Apakah i18next sudah ketinggalan zaman?](https://intlayer.org/id/blog/is-i18next-outdated)
+- [Menggunakan Intlayer dengan i18next](https://intlayer.org/id/blog/intlayer-with-i18next) dan [dengan react-i18next](https://intlayer.org/id/blog/intlayer-with-react-i18next)
+- [Cara menginternasionalkan aplikasi Next.js dengan next-i18next](https://intlayer.org/id/blog/nextjs-internationalization-using-next-i18next)
+
+Dokumentasi referensi:
+
+- [Laporan benchmark Next.js](https://intlayer.org/id/doc/benchmark/nextjs) dan [laporan benchmark TanStack Start](https://intlayer.org/id/doc/benchmark/tanstack)
+- Adaptor kompatibilitas: [i18next](https://intlayer.org/id/doc/compatibility/i18next), [react-i18next](https://intlayer.org/id/doc/compatibility/react-i18next), [next-i18next](https://intlayer.org/id/doc/compatibility/next-i18next)
+- Panduan migrasi: [i18next](https://intlayer.org/id/doc/migration/i18next), [react-i18next](https://intlayer.org/id/doc/migration/react-i18next), [next-i18next](https://intlayer.org/id/doc/migration/next-i18next)
+- [Optimasi bundel](https://intlayer.org/id/doc/concept/bundle-optimization) dan [kompiler Intlayer](https://intlayer.org/id/doc/compiler)
+- [i18n per komponen vs terpusat](https://intlayer.org/id/blog/per-component-vs-centralized-i18n)
+- [i18n berbasis kompilator vs deklaratif](https://intlayer.org/id/blog/compiler-vs-declarative-i18n)
 
 ## Bintang GitHub
 

package/blog/id/is_intlayer_lighter_than_paraglide.md

@@ -0,0 +1,284 @@
+---
+createdAt: 2026-09-23
+updatedAt: 2026-09-23
+title: Apakah Intlayer lebih ringan dari Paraglide?
+description: Paraglide terlihat hampir tanpa beban dalam tolok ukur i18n karena kodenya dibuat langsung di repositori Anda. Berikut analisis ke mana beban tersebut sebenarnya berada, mengapa pembacaan lokal per-node membebani performa, dan bagaimana pemuatan dinamis Intlayer mengirimkan satu bahasa saja alih-alih semuanya.
+keywords:
+  - Paraglide
+  - Intlayer
+  - Internasionalisasi
+  - i18n
+  - Bundle size
+  - Tree shaking
+  - Benchmark
+  - Blog
+slugs:
+  - blog
+  - is-intlayer-lighter-than-paraglide
+author: aymericzip
+---
+
+# Apakah Intlayer lebih ringan dari Paraglide?
+
+Ya.
+
+`Paraglide` memiliki reputasi yang sangat baik sebagai solusi i18n paling ringan, dan sekilas hasil [benchmark](https://intlayer.org/id/doc/benchmark/tanstack) mengonfirmasi hal tersebut: ukuran pustakanya mendekati nol. Namun, ukuran pustaka nol tidak berarti nol bita yang dikirim ke peramban. Itu hanya berarti bita-bita tersebut berada di tempat yang tidak diukur oleh metrik tersebut.
+
+<TOC/>
+
+## Poin Kunci
+
+**Ukuran pustaka disembunyikan, bukan dihilangkan:**
+
+Paraglide membuat kode runtime dan fungsi pesannya langsung di dalam codebase Anda. Kode tersebut tetap dikirim ke peramban, tetapi dihitung sebagai kode _Anda_, bukan sebagai kode pustaka pihak ketiga.
+
+**Tanpa provider bukan berarti kemenangan cuma-cuma:**
+
+Setiap pemanggilan `m.my_key()` menyelesaikan penentuan lokal secara mandiri, membaca cookie atau penyimpanan untuk setiap node yang dirender, alih-alih membacanya sekali saja dari sebuah konteks.
+
+**Tidak ada pemuatan dinamis (Dynamic Loading):**
+
+Paraglide mengimpor seluruh bahasa dari sebuah pesan ke dalam bundle klien Anda. Sebaliknya, Intlayer dengan `importMode: 'dynamic'` atau `'fetch'` hanya memuat bahasa yang sedang dirender.
+
+**Tree shaking tidak selalu terjamin:**
+
+Dalam beberapa pengujian tolok ukur kami, tree shaking yang digadang-gadang oleh Paraglide tidak bekerja efektif. Sebaiknya periksa bundle aplikasi Anda sendiri.
+
+## Ke Mana Sebenarnya Beban Paraglide Berada?
+
+Dalam laporan tolok ukur, metrik "ukuran pustaka" mengukur provider dan hook dari masing-masing pustaka i18n pada komponen kosong, sebelum konten apa pun ditambahkan.
+
+| Pustaka (TanStack Start)      | Ukuran lib (gz) | Ukuran lib (min) |
+| ----------------------------- | --------------- | ---------------- |
+| `@inlang/paraglide-js@2.15.1` | 1.8 KB          | 4.5 KB           |
+| `react-intlayer@9.5.1`        | 5.0 KB          | 15.2 KB          |
+
+Jika dibaca secara terpisah, Paraglide tampak unggul. Namun Paraglide adalah sebuah kompilator: ia membaca berkas `messages/*.json` Anda dan menulis folder `paraglide/` ke repositori Anda, yang berisi `runtime.js` (deteksi lokal, strategi cookie dan penyimpanan, pelokalan URL) serta satu fungsi JavaScript per pesan.
+
+```bash
+src/paraglide/
+├── runtime.js      # deteksi lokal, strategi, helper URL
+├── server.js
+├── messages.js     # mengekspor kembali semua pesan
+└── messages/
+    ├── _index.js
+    ├── en.js
+    └── fr.js
+```
+
+Karena kode ini berada di dalam folder `src/` Anda dan diimpor menggunakan jalur relatif, bundler menganggapnya sebagai bagian dari aplikasi Anda, bukan paket luar di `node_modules`. Kolom ukuran pustaka memperlihatkan angka mendekati nol, padahal logika yang sama tetap dikirim dalam bundle halaman Anda.
+
+Menghasilkan kode otomatis bukanlah ide buruk: runtime yang dihasilkan hanya memuat logika yang benar-benar dibutuhkan konfigurasi Anda (strategi awalan, cookie vs local storage, dll.). Intlayer mencapai hasil yang sama dengan cara berbeda, yaitu menyuntikkan variabel lingkungan saat proses build sehingga bundler membuang percabangan kode yang tidak digunakan konfigurasi Anda. Kedua pendekatan ini berakhir 3 hingga 10 kali lebih ringan daripada `i18next` atau `next-intl`.
+
+Oleh karena itu, perbandingan yang adil bukanlah ukuran pustakanya, melainkan **JavaScript yang benar-benar dikirimkan per halaman**.
+
+## Beban Halaman yang Terukur
+
+Aplikasi TanStack Start, 10 halaman, diukur pada rute `en` dan `fr`, dikompresi dengan gzip:
+
+| Konfigurasi                        | Rata-rata JS Hal (gz) | Di atas dasar | Kebocoran lokal | Kebocoran hal lain |
+| ---------------------------------- | --------------------- | ------------- | --------------- | ------------------ |
+| Dasar (tanpa i18n)                 | 111.0 KB              | -             | 0.0%            | 0.0%               |
+| `paraglide` (semua strategi)       | 125.1 KB              | +14.1 KB      | 49.7%           | 0.0%               |
+| `intlayer` (`importMode: static`)  | 125.8 KB              | +14.8 KB      | 50.0%           | 0.0%               |
+| `intlayer` (`importMode: dynamic`) | **118.6 KB**          | **+7.6 KB**   | **0.0%**        | **0.0%**           |
+
+Next.js 16 App Router, aplikasi yang sama:
+
+| Konfigurasi        | Rata-rata JS Hal (gz) | Di atas dasar |
+| ------------------ | --------------------- | ------------- |
+| Dasar (tanpa i18n) | 141.0 KB              | -             |
+| `paraglide-next`   | 155.3 KB              | +14.3 KB      |
+| `next-intlayer`    | **141.3 KB**          | **+0.3 KB**   |
+
+<I18nBenchmark framework="tanstack" vertical/>
+
+> Data lengkap tersedia di [laporan benchmark TanStack Start](https://intlayer.org/id/doc/benchmark/tanstack) dan [laporan benchmark Next.js](https://intlayer.org/id/doc/benchmark/nextjs). Setiap bundle dapat diperiksa langsung di [repositori benchmark](https://github.com/intlayer-org/benchmark-i18n).
+
+Dua hal terlihat sangat jelas:
+
+- Dalam mode `static`, Intlayer mengirimkan konten yang hampir sama persis dengan Paraglide (125.8 KB vs 125.1 KB). Hal ini wajar: keduanya menyertakan semua bahasa dari pesan yang digunakan oleh halaman tersebut.
+- Paraglide tetap berada di angka 125.1 KB apa pun strateginya, karena tidak memiliki mode dinamis. Setiap baris pada tabel di atas mewakili mode statis.
+
+## Tanpa Provider: Ide yang Tampak Bagus Namun Berisiko
+
+Paraglide tidak memerlukan provider. Anda cukup mengimpor pesan dan memanggilnya:
+
+```tsx fileName="Hero.tsx"
+import { m } from "../paraglide/messages.js";
+
+export const Hero = () => (
+  <section>
+    <h1>{m.hero_title()}</h1>
+    <p>{m.hero_description()}</p>
+    <button>{m.hero_cta()}</button>
+  </section>
+);
+```
+
+Tanpa konteks, tanpa wrapper, tanpa hook. Tampak lebih sederhana. Namun, informasi bahasa tetap harus diperoleh dari suatu tempat. Setiap fungsi pesan yang dihasilkan kurang lebih tampak seperti ini (disederhanakan):
+
+```js fileName="paraglide/messages/_index.js"
+export const hero_title = (inputs = {}, options = {}) => {
+  const locale = options.locale ?? getLocale(); // diselesaikan pada setiap pemanggilan
+
+  if (locale === "en") return en.hero_title(inputs);
+  if (locale === "fr") return fr.hero_title(inputs);
+  // ...satu percabangan per bahasa
+};
+```
+
+Dan `getLocale()` menelusuri seluruh strategi yang dikonfigurasi (cookie, penyimpanan lokal, URL, bahasa dasar) untuk menemukan lokal aktif. Akibatnya, setiap node teks yang Anda render (`<>{m.my_key()}</>`) menjalankan proses resolusi lokalnya sendiri, termasuk membaca `document.cookie` di peramban. Halaman dengan 200 string terjemahan akan menyelesaikan lokal sebanyak 200 kali per render, dan berulang kembali pada setiap re-render.
+
+Pustaka berbasis provider membaca lokal **hanya sekali**, menyimpannya dalam konteks (atau sinyal, atau store), dan setiap node hanya membaca nilai yang sudah tersedia di memori. Biaya provider hanya beberapa ratus bita. Menghilangkannya justru membebani kerja CPU pada setiap render. Hal ini terbukti dalam tolok ukur: waktu muat halaman dan pergantian bahasa Paraglide konsisten berada di belakang Intlayer pada TanStack Start (waktu muat halaman 22.1 ms vs 14.6 ms, reaktivitas E2E 4.3 ms vs 3.2 ms).
+
+## Pengalaman Pengembang (DX)
+
+Sumber kebenaran Paraglide adalah berkas JSON, tetapi Anda tidak pernah mengimpor berkas JSON secara langsung. Anda mengimpor berkas `.js` yang dihasilkan:
+
+<Tabs defaultTab="intlayer" group="techno">
+  <Tab label="Paraglide" value="paraglide">
+
+```json fileName="messages/en.json"
+{
+  "hero_title": "Ship your app in every language"
+}
+```
+
+```json fileName="messages/id.json"
+{
+  "hero_title": "Rilis aplikasi Anda dalam semua bahasa"
+}
+```
+
+```tsx fileName="Hero.tsx"
+// Hanya ada setelah kompilator membuatnya ulang dari JSON
+import { m } from "../paraglide/messages.js";
+
+export const Hero = () => <h1>{m.hero_title()}</h1>;
+```
+
+  </Tab>
+  <Tab label="Intlayer" value="intlayer">
+
+```ts fileName="Hero.content.ts"
+import { t, type Dictionary } from "intlayer";
+
+export default {
+  key: "hero",
+  content: {
+    title: t({
+      id: "Rilis aplikasi Anda dalam semua bahasa",
+      en: "Ship your app in every language",
+    }),
+  },
+} satisfies Dictionary;
+```
+
+```tsx fileName="Hero.tsx"
+import { useIntlayer } from "react-intlayer";
+
+export const Hero = () => {
+  const { title } = useIntlayer("hero");
+
+  return <h1>{title}</h1>;
+};
+```
+
+  </Tab>
+</Tabs>
+
+Alur kerja semacam ini menimbulkan konsekuensi:
+
+- Setiap perubahan pada berkas JSON memerlukan pembuatan ulang (regeneration) sebelum import dapat dikenali atau tipe data diperbarui.
+- Folder `paraglide/` yang dibuat harus diikutsertakan dalam commit git (memicu konflik merge pada berkas buatan di setiap PR teks), atau diabaikan (mengharuskan langkah kompilasi sebelum pemeriksaan tipe, pengujian, dan tugas CI).
+- Setiap string berubah menjadi pemanggilan fungsi. Konstanta berubah menjadi `m.key()` di mana-mana, bahkan di tempat yang sebenarnya cukup dengan nilai statis biasa.
+
+## Tree Shaking: Periksa Bundle Anda
+
+Janji utama Paraglide adalah bahwa pesan yang tidak digunakan akan dibuang melalui tree shaking, karena setiap pesan merupakan ekspor mandiri. Pada tolok ukur Svelte + Vite, fitur ini bekerja sesuai klaim.
+
+Namun dalam konfigurasi lain, hal itu tidak terjadi. Pada pengujian [Next.js](https://intlayer.org/id/doc/benchmark/nextjs) kami, halaman Paraglide berbobot 14 KB lebih berat daripada aplikasi dasar, sedangkan `next-intlayer` hanya menambahkan 0.3 KB. Pengujian awal di TanStack Start juga memperlihatkan pesan dari halaman lain ikut terbawa ke dalam bundle rute yang sedang dibuka.
+
+Tree shaking sangat bergantung pada bundler Anda (Turbopack, Rolldown, Rollup), cara pesan diimpor (`import { m }` vs `import * as m`), dan analisis efek samping (side effects). Jika Anda memilih Paraglide karena pertimbangan ukuran, buka visualizer bundle Anda dan pastikan fitur tersebut bekerja di aplikasi Anda.
+
+## Tanpa Pemuatan Dinamis
+
+Inilah batasan struktural utamanya. Paraglide tidak memiliki mekanisme untuk memuat satu bahasa dalam satu waktu: setiap fungsi pesan secara statis mengimpor implementasi setiap bahasa, sehingga seluruh bahasa berakhir di dalam bundle klien Anda.
+
+Dengan 2 bahasa, separuh muatan terjemahan terbuang sia-sia, cocok dengan ~50% kebocoran lokal yang diukur sebelumnya. Dengan 10 bahasa, pemborosan mencapai 90%. Dengan 30 bahasa, melonjak hingga 97%.
+
+Beralih ke pemuatan dinamis pun tidak serta-merta menyelesaikan masalah: dengan satu fungsi untuk setiap pesan, memuat setiap fungsi secara lazy akan memicu ribuan permintaan jaringan yang terpisah-pisah.
+
+Intlayer memberi Anda fleksibilitas untuk memilih secara global maupun per kamus:
+
+```ts fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH, Locales.SPANISH],
+    defaultLocale: Locales.ENGLISH,
+  },
+  dictionary: {
+    importMode: "dynamic", // 'static' | 'dynamic' | 'fetch'
+  },
+};
+
+export default config;
+```
+
+| `importMode` | Yang dikirimkan ke klien                                | vs. Paraglide                           |
+| ------------ | ------------------------------------------------------- | --------------------------------------- |
+| `static`     | Seluruh bahasa dari kamus yang digunakan halaman        | Secara teori muatan sama                |
+| `dynamic`    | Hanya bahasa aktif, dimuat secara lazy per kamus        | **N kali lebih ringan** dengan N bahasa |
+| `fetch`      | Hanya bahasa aktif, diambil langsung dari Live Sync API | **N kali lebih ringan** dengan N bahasa |
+
+Dengan [transformasi build](https://intlayer.org/id/doc/concept/bundle-optimization) dan `importMode: 'static'`, Intlayer secara teoritis memuat konten yang sama persis dengan Paraglide. Namun dengan mode `'dynamic'` atau `'fetch'`, ia hanya memuat apa yang dibutuhkan bahasa saat ini: untuk aplikasi dengan N bahasa, beban terjemahan menjadi N kali lebih kecil daripada Paraglide.
+
+## Kapan Paraglide Masih Relevan?
+
+<AccordionGroup>
+<Accordion header="Svelte + Vite dengan sedikit bahasa">
+
+Jika teknologi Anda menggunakan Svelte bersama Vite dan Anda hanya mendukung dua atau tiga bahasa, tree shaking bekerja sesuai harapan dan overhead bahasa tambahan tetap minim.
+
+</Accordion>
+<Accordion header="Alur kerja inlang yang sudah ada">
+
+Jika tim Anda sudah terbiasa menggunakan ekosistem inlang (Fink, Sherlock, plugin format pesan), Paraglide terintegrasi secara mulus.
+
+</Accordion>
+</AccordionGroup>
+
+## Uji Sendiri di Aplikasi Anda
+
+Periksa ukuran muatan dan kebocoran lokal aplikasi produksi Anda dengan [i18n SEO Scanner](https://intlayer.org/i18n-seo-scanner) gratis:
+
+<ClickToOpenIframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+Untuk menyiapkan Intlayer:
+
+```bash packageManager="npm"
+npx intlayer init --interactive
+```
+
+```bash packageManager="pnpm"
+pnpm dlx intlayer init --interactive
+```
+
+```bash packageManager="yarn"
+yarn dlx intlayer init --interactive
+```
+
+```bash packageManager="bun"
+bunx intlayer init --interactive
+```
+
+## Bacaan Lanjutan
+
+- [Benchmark i18n TanStack Start](https://intlayer.org/id/doc/benchmark/tanstack)
+- [Benchmark i18n Next.js](https://intlayer.org/id/doc/benchmark/nextjs)
+- [Optimasi Bundle dan `importMode`](https://intlayer.org/id/doc/concept/bundle-optimization)
+- [Cara Memilih Pustaka i18n untuk React](https://intlayer.org/id/blog/how-to-pick-react-i18n-library)
+- [Alasan Memilih Internasionalisasi Berbasis Kompilator](https://intlayer.org/id/blog/compiler-vs-declarative-i18n)