i18next VS Intlayer | Benchmark internacjonalizacji (i18n) w React i Next.js

i18next to najczęściej używany framework i18n w ekosystemie JavaScript. Poprzez react-i18next i next-i18next zasila ogromną część aplikacji React i Next.js. Intlayer to nowoczesna alternatywa oparta na kompilatorze i izolacji na poziomie komponentów.

Ten artykuł porównuje oba rozwiązania na podstawie twardych pomiarów, a nie list funkcji. Liczby pochodzą z Benchmark Bloom, otwartoźródłowego pakietu testów, który buduje tę samą aplikację z każdą biblioteką i rejestruje, co przeglądarka faktycznie pobiera.

tl;dr: i18next to najcięższe środowisko wykonawcze (runtime) w tym benchmarku: +77 KB gzip na stronę w Next.js w konfiguracji naiwnej, oraz +22 KB po pełnej optymalizacji przestrzeni nazw (namespaces) i leniwego ładowania (lazy-loading). Intlayer dodaje zaledwie +0.3 KB. Każda konfiguracja i18next z wyjątkiem w pełni wyizolowanej (scoped) wysyła ~90% ciągów z innych stron; Intlayer domyślnie wysyła 0%. Zmiana języka z leniwie ładowanym backendem zajęła 123-185 ms w react-i18next wobec 3-4 ms w Intlayer. Adapter @intlayer/next-i18next zachowuje API i18next i osiągnął 150.7 KB na stronę w porównaniu z 218.5 KB oryginału.

W skrócie

• i18next / react-i18next / next-i18next - Dojrzały, bogaty w pluginy, niezależny od frameworka. Przestrzenie nazw, detektory języka, backendy, ICU przez wtyczki, <Trans> dla treści sformatowanych. Zawartość jest scentralizowana w locales/{lng}/{ns}.json. Bardzo potężny, ale każda optymalizacja (podział przestrzeni nazw, ładowanie per strona, bezpieczeństwo typów) wymaga ręcznej konfiguracji i ciągłego utrzymania.
• Intlayer - Model zorientowany na komponenty. Słowniki .content.ts znajdują się bezpośrednio przy komponencie, który obsługują; kompilator w czasie budowania usuwa zbędny kod (tree-shaking) i ładuje treści leniwie per komponent i język. Ścisłe typy TypeScript są generowane automatycznie z treści, a brakujące tłumaczenia powodują błąd budowania. Zawiera middleware, pomocniki SEO, Edytor Wizualny / CMS i tłumaczenie wspomagane AI.

Pokaż całą zawartość tabeli

Pokaż całą zawartość tabeli

Otwórz tabelę w oknie modalnym, aby wyraźnie zobaczyć całą zawartość

Biblioteka	Gwiazdki GitHub	Łącznie commitów	Ostatni commit	Pierwsza wersja	Wersja NPM	Pobrania NPM (miesięcznie)
aymericzip/intlayer				Kwiecień 2024
i18next/i18next				Styczeń 2012
i18next/react-i18next				Grudzień 2015
i18next/next-i18next				Listopad 2018

Odznaki aktualizują się automatycznie. Wartości zmieniają się w czasie.

Porównanie funkcji

Benchmark

Co było mierzone

Pakiet testowy Benchmark Bloom buduje dokładnie tę samą aplikację z każdą biblioteką: 10 stron (home, about, blog, careers, contact, FAQ, pricing, products, settings, team), 10 języków (en, fr, es, de, it, pt, zh, ja, ko, ru), identyczne komponenty i identyczną zawartość. Pomiary przeprowadzono dla stron w językach angielskim i francuskim. Każdą bibliotekę wdrożono w maksymalnie czterech strategiach ładowania:

Intlayer nie posiada wariantu "scoped": kompilator automatycznie ogranicza zakres treści na poziomie komponentu, dlatego wiersze static i dynamic są już w pełni zoptymalizowane.

Dla każdego buildu rejestrowane są wskaźniki:

• Lib size: rozmiar gzip pustego komponentu importującego tylko bibliotekę i18n (stały koszt runtime).
• Page JS: średni pobierany JavaScript gzip na stronę dla wszystkich stron i języków.
• Locale leak %: odsetek przetłumaczonych ciągów w pobranym JS należących do języka, którego użytkownik nie przegląda.
• Page leak %: odsetek przetłumaczonych ciągów w pobranym JS należących do strony, na której użytkownik nie przebywa.
• Component avg: średni rozmiar gzip każdego komponentu skompilowanego w izolacji.
• E2E reactivity: rzeczywisty czas od wyboru nowego języka do zaktualizowania html[lang] w DOM (Playwright, 5 prób).
• Hydration: czas trwania fazy hydratacji React.

Poniższe wyniki pochodzą z testów przeprowadzonych 2026-09-12 z wersjami next-i18next 16.3.0, react-i18next 17.0.13 i intlayer 9.5.1. Aplikacja testowa jest celowo zwarta, dlatego procenty wycieków opisują wzorzec: rosną one wraz z rozrostem treści, podczas gdy stały koszt środowiska wykonawczego nie ulega zmianie.

Wyniki w Next.js (next-i18next)

Analiza wyników

• Koszt środowiska wykonawczego: rdzeń i18next wraz z react-i18next to najcięższy mierzony runtime: 19.7 KB gzip dla pustego komponentu, wobec 5.5 KB w next-intlayer.
• Naiwna konfiguracja jest kosztowna: Wstrzyknięcie resources w init() generuje 218.5 KB na stronę (+77.5 KB w stosunku do aplikacji bazowej). Każda strona nosi w sobie wszystkie przestrzenie nazw.
• Optymalizacja wymaga dużych nakładów pracy: Przejście na backend (dynamic) oszczędza 49 KB, lecz wciąż przepuszcza 90% ciągów z innych stron, a w tej konfiguracji połowa pobranych ciągów należy do nieaktywnego języka. Dopiero podział na przestrzenie nazw per trasa (scoped-dynamic) zatrzymuje wycieki przy rozmiarze 163.4 KB, co wciąż daje +22.4 KB na stronę więcej niż w Intlayer (141.3 KB), który nie wymagał żadnej żmudnej konfiguracji.
• Wielkość komponentów: Komponent wywołujący useTranslation() kompiluje się do 26-79 KB; ten sam komponent z useIntlayer() zajmuje zaledwie 6.9 KB.
• Czas hydratacji: w konfiguracji dynamic wzrasta do 27.7 ms, ponieważ instancja i18next musi zainicjalizować się i przetworzyć backend po stronie klienta, zanim React ukończy hydratację.

Wyniki w TanStack Start (react-i18next)

Ta sama aplikacja na TanStack Start z czystym react-i18next, co eliminuje specyfikę Next.js z testu porównawczego.

Analiza wyników

• Zwykła aplikacja react-i18next wysyła +69 KB na stronę więcej niż aplikacja bazowa, a hydratacja trwa aż 85 ms (4-krotnie dłużej), gdyż całe drzewo zasobów musi zostać przetworzone i zarejestrowane na kliencie przed pierwszym wyrenderowaniem.
• Opóźnienie przy zmianie języka: Przy leniwym ładowaniu zmiana języka pociąga za sobą żądanie sieciowe zanim nastąpi aktualizacja html[lang]: 123 ms w dynamic, 185 ms w scoped-static. Intlayer aktualizuje DOM w 3-4 ms w obu trybach: przełączenie jest natychmiastowe i niezależne od sieci.
• Zoptymalizowana konfiguracja scoped-dynamic osiąga 0% wycieków przy 127.2 KB, co nadal przewyższa Intlayer w trybie dynamic o +8.6 KB, wymagając mapowania tras i granic Suspense.
• Intlayer w trybie static wykazuje 0% wycieku stron już na starcie, ponieważ pakowane są tylko te słowniki, które zostały zaimportowane przez komponenty danej strony. Włączenie importMode: 'dynamic' eliminuje także wyciek języka.
• Rozmiar komponentu: 24-27 KB w react-i18next wobec 6-8 KB w Intlayer. useTranslation() wiąże każdy komponent z globalną instancją i18next.

Skąd ta różnica? Globalna instancja vs skompilowane słowniki

i18next powstał w 2012 roku jako runtime: pojedyncza globalna instancja trzyma repozytorium zasobów, wtyczki je rozszerzają, a t() szuka kluczy w czasie renderowania. Daje to wszechstronność, ale generuje narzut:

.
├── 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     # musi wiedzieć, że potrzebuje ["common", "about"]

Instancja nie wie z góry, o jakie klucze zapyta komponent, dlatego trzyma wszystkie przestrzenie nazw przekazane do załadowania. Optymalizacja wymaga, aby programista dzielił katalogi, wyliczał przestrzenie dla każdej strony i na bieżąco korygował te powiązania. Jak zauważono w notatkach z benchmarku: "Utrzymanie typowania i dokładna wiedza o tym, który namespace dołączyć do danej strony, to koszmar".

Intlayer eliminuje instancję globalną. Treści deklarowane są tuż obok komponentu, a kompilator rozwiązuje graf zależności podczas budowania:

.
├── 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 rozpoznaje, który komponent importuje dany słownik, dołącza do paczki tylko te niezbędne dla aktywnego języka i usuwa nieużywane. Wzorzec "scoped-dynamic" staje się bezpośrednim efektem buildu, a nie uciążliwą procedurą do ręcznego pilnowania.

Aby uzyskać liczby z wiersza dynamic, ustaw dictionary.importMode: 'dynamic' w pliku intlayer.config.ts. Szczegóły opisano w dokumentacji optymalizacji bundle.

Doświadczenie programisty (DX)

Konfiguracja

next-i18next (App Router)

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;
};

Do tego dochodzi kliencki I18nProvider, generateStaticParams oraz deklarowanie tablicy namespaces na każdej podstronie.

Intlayer

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;

Komponent kliencki

react-i18next

{
  "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>
  );
};

Strona renderująca ten komponent musi załadować namespace about, a t("counter.label") pozostaje zwykłym stringiem bez rozszerzenia CustomTypeOptions.

Intlayer

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>
  );
};

Pola label oraz increment posiadają ścisłe typowanie; każda literówka natychmiast generuje błąd TypeScript, a brak tłumaczenia dla języka francuskiego zablokuje proces budowania.

Synchroniczny komponent serwerowy (RSC)

next-i18next

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>
);

Na poziomie strony wywołuje się i18n.getFixedT(locale, "about"), po czym przekazuje t i locale w dół za pomocą props.

Intlayer

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>
  );
};

Zachowaj API i18next, zyskaj wydajność Intlayer

Nie musisz przepisywać istniejących komponentów, aby cieszyć się zyskami z powyższego benchmarku. Adaptery @intlayer/i18next, @intlayer/react-i18next i @intlayer/next-i18next działają bezpośrednio jako zamienniki typu drop-in: wywołania useTranslation, t(), <Trans>, obsługa liczb mnogich i kontekstów działają bez zmian, serwowane przez zoptymalizowane słowniki Intlayer.

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()],
});

W benchmarku wersja z adapterem dla tej samej aplikacji Next.js zmniejszyła się z 218.5 KB do 150.7 KB na stronę, z 78.5 KB do 9.7 KB na komponent, wyciek spadł z ~90% do 0%, a czas hydratacji skrócił się z 15.6 ms do 11.3 ms - bez modyfikacji kodu komponentów. Twoje dotychczasowe pliki locales/{lng}/{ns}.json mogą pozostać źródłem danych dzięki wtyczce do synchronizacji JSON.

Zobacz przewodniki migracji: i18next, react-i18next, next-i18next.

Kiedy wybrać dane rozwiązanie?

• Wybierz i18next: jeśli bezwzględnie wymagasz jego ekosystemu wtyczek (specyficzne detektory, niestandardowe backendy, ICU, Locize), lokalizujesz treści także poza środowiskiem React (serwisy Node, czysty JS, inne frameworki), zespół ma już opanowane narzędzia lub zewnętrzna platforma tłumaczeniowa wymaga struktury locales/{lng}/{ns}.json. Zadbaj o czas na ręczną organizację przestrzeni nazw i mapowanie tras.
• Wybierz Intlayer: jeśli zależy Ci na treściach przypisanych bezpośrednio do komponentów, ścisłym bezpieczeństwie TypeScript, wykrywaniu brakujących kluczy podczas budowania, automatycznym tree-shakingu i leniwym ładowaniu bez wysiłku, natychmiastowej zmianie języka, synchronicznych komponentach serwerowych i zintegrowanych narzędziach (Edytor Wizualny, CMS, tłumaczenie AI, serwer MCP). Znakomity wybór dla aplikacji modułowych i systemów projektowych (Design Systems).
• Wybierz adaptery @intlayer/*-i18next: jeśli posiadasz istniejący kod oparty na i18next i chcesz natychmiast zredukować wagę paczki oraz przyspieszyć działanie bez konieczności refaktoryzacji.

Powiązane porównania

• next-intl vs Intlayer (ten sam benchmark)
• Lingui vs Intlayer (ten sam benchmark)
• vue-i18n vs Intlayer benchmark (ten sam benchmark)
• next-i18next vs next-intl vs Intlayer
• react-i18next vs react-intl vs Intlayer
• Czy i18next jest przestarzały?

Gwiazdki na GitHub

Gwiazdki na GitHubie to przejrzysty wskaźnik popularności, zaufania społeczności i długoterminowego rozwoju projektu. Choć nie określają bezpośrednio jakości kodu, pokazują, jak wielu inżynierów uważa projekt za wartościowy i decyduje się na jego wdrożenie.

Podsumowanie

i18next w pełni zasłużył na swoją pozycję: działa wszędzie, posiada wtyczki do wszystkiego i jest rozwijany od ponad dekady. Benchmark ten ujawnia jednak koszty architektury zorientowanej na runtime. Typowa konfiguracja dodaje +70-77 KB gzip na stronę, przesyła ~90% zbędnych tekstów z innych podstron, a zmiana języka z leniwym ładowaniem trwa ponad 100 ms. Osiągnięcie 0% wycieków jest możliwe, lecz wymaga backendów i manualnego mapowania, a i tak pozostaje o +9-22 KB cięższe niż Intlayer.

Intlayer przenosi cały ten wysiłek na kompilator. Słowniki przy komponentach, automatyczne leniwe ładowanie per język i usuwanie martwych treści to bezpośrednie efekty procesu budowania. W tej samej aplikacji: +0.3 KB na stronę, 0% wycieków, komponenty 3-10x lżejsze oraz zmiana języka w 3-4 ms.

Wszystkie surowe dane, aplikacje testowe i skrypty znajdują się w repozytorium Benchmark Bloom. Możesz uruchomić je i sprawdzić samodzielnie.

Więcej szczegółów znajdziesz w dokumentacji 'Dlaczego Intlayer?'.