i18next VS Intlayer: Benchmark Internasionalisasi (i18n) React & Next.js

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, sebuah suite pengujian sumber terbuka yang membangun aplikasi yang sama persis dengan masing-masing library dan mencatat data yang diunduh oleh peramban secara akurat.

Ringkasan (tl;dr): i18next merupakan runtime terberat dalam pengujian benchmark ini: menambah +77 KB gzip per halaman pada Next.js dalam konfigurasi dasar (naive), dan masih menambah +22 KB bahkan setelah optimasi penuh namespace dan lazy-loading. Sebaliknya, Intlayer hanya menambah +0.3 KB. Setiap konfigurasi i18next kecuali konfigurasi yang diisolasi penuh (scoped) mengirimkan sekitar 90% string dari halaman lain yang tidak dibuka; sementara Intlayer secara bawaan mencatat 0% kebocoran. Pergantian bahasa menggunakan backend lazy-load membutuhkan 123-185 ms dengan react-i18next, dibandingkan hanya 3-4 ms dengan Intlayer. Adaptor @intlayer/next-i18next mempertahankan API i18next dan menurunkan ukuran per halaman dari 218.5 KB menjadi 150.7 KB.

Ringkasan Singkat

• i18next / react-i18next / next-i18next - Matang, kaya akan plugin, dan agnostik terhadap framework. Mendukung namespaces, detektor bahasa, backend, ICU via plugin, serta <Trans> untuk konten kaya. Konten dikelola terpusat di locales/{lng}/{ns}.json. Sangat andal, namun setiap langkah optimasi (pemecahan namespace, pemuatan per halaman, keamanan tipe data) membutuhkan konfigurasi manual yang harus Anda pelihara sendiri.
• Intlayer - Model konten berbasis komponen. Kamus .content.ts ditempatkan langsung di samping komponen terkait, kompilator saat build otomatis menerapkan tree-shaking dan lazy loading per komponen serta per bahasa, tipe data TypeScript yang ketat dibuat otomatis dari konten, dan terjemahan yang hilang akan langsung memicu error saat build. Menyediakan middleware bawaan, pembantu SEO, Visual Editor / CMS, dan penerjemahan dengan bantuan AI.

Tampilkan semua isi tabel

Tampilkan semua isi tabel

Buka tabel dalam modal untuk melihat semua isi data dengan jelas

Library	Bintang GitHub	Total Commit	Commit Terakhir	Versi Perdana	Versi NPM	Unduhan Bulanan NPM
aymericzip/intlayer				April 2024
i18next/i18next				Januari 2012
i18next/react-i18next				Desember 2015
i18next/next-i18next				November 2018

Lencana diperbarui secara otomatis. Angka dapat berubah seiring waktu.

Perbandingan Fitur

Pengujian Benchmark

Apa yang Diukur?

Suite pengujian Benchmark Bloom membangun aplikasi yang identik dengan setiap library: 10 halaman (home, about, blog, careers, contact, FAQ, pricing, products, settings, team), 10 bahasa (en, fr, es, de, it, pt, zh, ja, ko, ru), dengan komponen dan konten yang sama persis. Pengukuran diuji pada bahasa Inggris (en) dan Prancis (fr). Setiap library diuji dengan hingga empat strategi pemuatan:

Intlayer tidak memerlukan varian "scoped": Kompilator secara otomatis mengisolasi konten pada level komponen, sehingga baris static dan dynamic sudah teroptimasi sejak awal.

Metrik yang dicatat untuk setiap build:

• Lib size: Ukuran gzip komponen kosong yang hanya mengimpor library i18n (biaya runtime tetap).
• Page JS: Rata-rata ukuran gzip JavaScript yang diunduh per halaman (di seluruh halaman dan bahasa).
• Locale leak %: Persentase string terjemahan dalam file JS yang diunduh yang berasal dari bahasa yang tidak sedang dilihat pengguna.
• Page leak %: Persentase string terjemahan dalam file JS yang berasal dari halaman tempat pengguna tidak berada.
• Component avg: Rata-rata ukuran gzip setiap komponen yang dikompilasi secara terisolasi.
• E2E reactivity: Waktu aktual dari pemilihan bahasa baru hingga pembaruan tag html[lang] di DOM (Playwright, rata-rata 5 kali percobaan).
• Hydration: Durasi fase hidrasi React.

Data di bawah ini diambil dari pengujian tanggal 2026-09-12 menggunakan next-i18next 16.3.0, react-i18next 17.0.13, dan intlayer 9.5.1. Aplikasi pengujian dirancang ringkas, sehingga persentase kebocoran mencerminkan pola struktural: Kebocoran akan bertambah besar seiring bertambahnya teks aplikasi, sementara biaya runtime tetap statis.

Hasil pada Next.js (next-i18next)

Pilih metrik dan pustaka yang Anda minati:

Analisis Hasil

• Biaya runtime: Inti i18next yang digabungkan dengan react-i18next merupakan runtime paling berat yang diuji: 19.7 KB gzip untuk sebuah komponen kosong, dibandingkan hanya 5.5 KB pada next-intlayer.
• Konfigurasi standar sangat membebani: Menyematkan resources langsung pada init() menghasilkan 218.5 KB per halaman (+77.5 KB di atas aplikasi dasar). Setiap halaman dipaksa mengunduh seluruh namespace.
• Optimasi manual memakan waktu: Beralih ke backend (dynamic) menghemat 49 KB namun tetap membocorkan 90% teks halaman lain, dan separuh dari teks yang terunduh berasal dari bahasa yang salah. Pemecahan namespace per rute (scoped-dynamic) berhasil menghentikan kebocoran pada angka 163.4 KB, namun tetap +22.4 KB per halaman lebih besar daripada Intlayer (141.3 KB) yang tidak memerlukan pengaturan manual sama sekali.
• 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.

Tabel lengkap, setiap pustaka dan setiap strategi, ada di laporan benchmark Next.js.

Hasil pada TanStack Start (react-i18next)

Aplikasi yang sama pada TanStack Start dengan react-i18next murni untuk memisahkan faktor arsitektur Next.js:

Analisis Hasil

• Aplikasi dasar react-i18next mengunduh +69 KB per halaman lebih banyak dari aplikasi tanpa i18n, dan hidrasi membutuhkan 85 ms (4 kali lebih lama) karena seluruh struktur data diterjemahkan dan didaftarkan di klien sebelum render pertama.
• Keterlambatan saat berganti bahasa: Saat menggunakan pemuatan bertahap (lazy load), pergantian bahasa mengharuskan komunikasi bolak-balik ke jaringan sebelum html[lang] diperbarui: 123 ms pada dynamic, dan 185 ms pada scoped-static. Sedangkan Intlayer memperbarui DOM dalam 3-4 ms pada kedua mode tanpa tertahan oleh antrean jaringan.
• Konfigurasi scoped-dynamic yang sangat dioptimalkan mencapai 127.2 KB, yang masih +8.6 KB lebih berat daripada Intlayer di mode dynamic, serta menuntut pengaturan peta rute, backend sumber daya, dan batasan Suspense yang rumit.
• 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.

Tabel lengkap ada di laporan benchmark TanStack Start.

Mengapa Perbedaannya Begitu Nyata? Global Instance vs Kamus Terkompilasi

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:

.
├── i18n.ts                      # createInstance().use(...).use(...).init({...})
└── src
    ├── locales
    │   ├── en
    │   │   ├── common.json
    │   │   ├── home.json
    │   │   └── about.json
    │   └── fr
    │       ├── common.json
    │       ├── home.json
    │       └── about.json
    ├── components
    │   └── Counter.tsx          # useTranslation("about") + t("counter.label")
    └── app
        └── [locale]
            └── about
                └── 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.

Biaya membengkak pada dua sumbu sekaligus, halaman dan bahasa:

Seperti dikutip dalam laporan benchmark: "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:

.
├── intlayer.config.ts
└── src
    ├── components
    │   └── Counter
    │       ├── index.tsx        # useIntlayer("counter")
    │       └── index.content.ts
    └── app
        └── [locale]
            └── about
                ├── page.tsx
                └── page.content.ts

@intlayer/swc / @intlayer/babel mendeteksi komponen mana yang memakai kamus mana, mengemas hanya kamus tersebut untuk bahasa aktif, dan membersihkan teks yang tidak terpakai. Pola "scoped-dynamic" menjadi output alami dari proses build, bukan lagi tugas manual yang harus dipelihara pengembang.

Untuk menerapkan performa pada baris dynamic, setel dictionary.importMode: 'dynamic' di file intlayer.config.ts. Silakan pelajari lebih lanjut di panduan optimasi bundle.

Pengalaman Pengembang (DX)

Perbandingan Konfigurasi Awal

import { createInstance } from "i18next";
import { initReactI18next } from "react-i18next/initReactI18next";
import resourcesToBackend from "i18next-resources-to-backend";
import { defaultLocale } from "@/i18n.config";

const backend = resourcesToBackend(
  (locale: string, namespace: string) =>
    import(`../../locales/${locale}/${namespace}.json`)
);

export const initI18next = async (
  locale: string,
  namespaces: string[] = ["common"]
) => {
  const i18n = createInstance();
  await i18n
    .use(initReactI18next)
    .use(backend)
    .init({
      lng: locale,
      fallbackLng: defaultLocale,
      ns: namespaces,
      defaultNS: "common",
      interpolation: { escapeValue: false },
      react: { useSuspense: false },
    });
  return i18n;
};

import { type IntlayerConfig, Locales } from "intlayer";

const config: IntlayerConfig = {
  internationalization: {
    locales: [Locales.ENGLISH, Locales.FRENCH],
    defaultLocale: Locales.ENGLISH,
  },
};

export default config;

import { getHTMLTextDir } from "intlayer";
import { IntlayerClientProvider, type NextLayoutIntlayer } from "next-intlayer";

const LocaleLayout: NextLayoutIntlayer = async ({ children, params }) => {
  const { locale } = await params;

  return (
    <html lang={locale} dir={getHTMLTextDir(locale)}>
      <body>
        <IntlayerClientProvider locale={locale}>
          {children}
        </IntlayerClientProvider>
      </body>
    </html>
  );
};

export default LocaleLayout;

Komponen Klien

{
  "counter": {
    "label": "Counter",
    "increment": "Increment"
  }
}

"use client";

import { useState } from "react";
import { useTranslation } from "react-i18next";

export const Counter = () => {
  const { t, i18n } = useTranslation("about");
  const [count, setCount] = useState(0);
  const numberFormat = new Intl.NumberFormat(i18n.language);

  return (
    <div>
      <p>{numberFormat.format(count)}</p>
      <button
        aria-label={t("counter.label")}
        onClick={() => setCount((c) => c + 1)}
      >
        {t("counter.increment")}
      </button>
    </div>
  );
};

import { t, type Dictionary } from "intlayer";

const counterContent = {
  key: "counter",
  content: {
    label: t({ en: "Counter", fr: "Compteur" }),
    increment: t({ en: "Increment", fr: "Incrémenter" }),
  },
} satisfies Dictionary;

export default counterContent;

"use client";

import { useState } from "react";
import { useIntlayer } from "next-intlayer";
import { useNumber } from "next-intlayer/format";

export const Counter = () => {
  const { label, increment } = useIntlayer("counter");
  const number = useNumber();
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>{number(count)}</p>
      <button aria-label={label} onClick={() => setCount((c) => c + 1)}>
        {increment}
      </button>
    </div>
  );
};

Komponen Server Sinkron (RSC)

type ServerCounterProps = {
  t: (key: string) => string;
  locale: string;
  count: number;
};

export const ServerCounter = ({ t, locale, count }: ServerCounterProps) => (
  <div>
    <p>{new Intl.NumberFormat(locale).format(count)}</p>
    <button aria-label={t("counter.label")}>{t("counter.increment")}</button>
  </div>
);

import { useIntlayer } from "next-intlayer/server";
import { useNumber } from "next-intlayer/server/format";

export const ServerCounter = ({ count }: { count: number }) => {
  const { label, increment } = useIntlayer("counter");
  const number = useNumber();

  return (
    <div>
      <p>{number(count)}</p>
      <button aria-label={label}>{increment}</button>
    </div>
  );
};

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.

import type { NextConfig } from "next";
import { createNextI18nPlugin } from "@intlayer/next-i18next/plugin";

const withIntlayer = createNextI18nPlugin();

const nextConfig: NextConfig = {};

export default withIntlayer(nextConfig);

import { defineConfig } from "vite";
import { reactI18nextVitePlugin } from "@intlayer/react-i18next/plugin";

export default defineConfig({
  plugins: [reactI18nextVitePlugin()],
});

Dalam pengujian benchmark, build kompatibel pada aplikasi Next.js yang sama mengalami penyusutan dari 218.5 KB menjadi 150.7 KB per halaman, dari 78.5 KB menjadi 9.7 KB per komponen, kebocoran halaman turun dari ~90% ke 0%, dan waktu hidrasi membaik dari 15.6 ms ke 11.3 ms, tanpa merombak kode komponen Anda. File locales/{lng}/{ns}.json Anda yang sudah ada tetap bisa dijadikan sumber data melalui plugin sinkronisasi JSON.

Pelajari panduan migrasinya: i18next, react-i18next, next-i18next.

Kapan Memilih yang Mana?

FAQ

Perbandingan Terkait

Benchmark yang sama, pustaka lain:

Mendalami i18next lebih lanjut:

Dokumentasi referensi:

Adaptor kompatibilitas:

Panduan migrasi:

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

Bintang GitHub

Bintang GitHub mencerminkan popularitas, kepercayaan komunitas, dan prospek jangka panjang sebuah proyek open-source. Meskipun bukan penentu tunggal dari kualitas kode, angka ini memperlihatkan antusiasme dan kesiapan adopsi di kalangan developer.

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.

Kesimpulan

i18next telah mengukir reputasi kuat: berjalan di mana saja, memiliki plugin untuk segala kebutuhan, dan dipelihara secara konsisten selama lebih dari sepuluh tahun. Namun, benchmark ini membuktikan beban dari arsitektur yang berpusat pada runtime. Penyiapan standar menambah beban +70-77 KB gzip per halaman, membocorkan ~90% konten halaman lain, dan memakan waktu lebih dari 100 ms saat berpindah bahasa. Menghilangkan kebocoran hingga 0% memang dapat dilakukan, tetapi butuh pengelolaan manual yang rumit dan tetap 9-22 KB lebih berat daripada Intlayer.

Intlayer memindahkan seluruh beban kerja tersebut ke kompilator. Pengelolaan kamus per komponen, pemuatan bertahap per bahasa, dan pembersihan teks tak terpakai menjadi hasil otomatis dari proses build. Pada aplikasi yang sama, hasilnya: Hanya +0.3 KB per halaman, 0% kebocoran, komponen 3-10 kali lebih kecil, dan pergantian bahasa instan dalam 3-4 ms.

Seluruh data mentah, aplikasi pengujian, dan skrip dapat diakses di repositori Benchmark Bloom. Anda bebas mengujinya sendiri.

Untuk pemahaman lebih mendalam, kunjungi dokumentasi 'Mengapa Intlayer?'.