next-intl VS Intlayer | Benchmark internacjonalizacji (i18n) w React i Next.js

next-intl to obecnie domyślny wybór w zakresie i18n dla Next.js App Router: ścisła integracja z routingiem, pełna obsługa ICU MessageFormat i środowisko pracy znane każdemu, kto korzystał z klasycznych bibliotek i18n.

Intlayer podchodzi do tematu od nowa: brak scentralizowanych słowników, brak konieczności ręcznego dopasowywania przestrzeni nazw (namespaces) do tras. Treści deklarowane są bezpośrednio przy komponentach, a kompilator w czasie budowania pakuje wyłącznie to, czego wymaga dana strona.

Poniższy artykuł porównuje obie biblioteki na podstawie danych z Benchmark Bloom, otwartoźródłowego zestawu testów, który buduje tę samą aplikację z każdą biblioteką i rejestruje realny kod pobierany oraz wykonywany przez przeglądarkę.

W skrócie (tl;dr): next-intl dodaje co najmniej +12.6 KB gzip na każdej stronie wyłącznie ze względu na swój runtime i powoduje wyciek ~90% ciągów z innych stron w standardowych konfiguracjach (static i dynamic). Wyeliminowanie tego wycieku wymaga podziału katalogów na przestrzenie nazw i ręcznego ich wybierania per strona. Z kolei kompilator Intlayer zapewnia 0% wycieku, 3x mniejsze komponenty i narzut rzędu zaledwie +0.3 KB ponad bazową aplikację bez żadnej konfiguracji.

Podsumowanie

• next-intl - Standard społeczności Next.js. Scentralizowane pliki JSON per język, pełna obsługa ICU MessageFormat i głęboka integracja z obsługą żądań i routingiem Next.js.
• Intlayer - Model zorientowany na komponenty. Słowniki .content.ts umieszczane są tuż obok komponentów, kompilator automatycznie wykonuje tree-shaking oraz leniwe ładowanie per komponent i per język, a także generuje ścisłe typy TypeScript.

Pokaż całą zawartość tabeli

Pokaż całą zawartość tabeli

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

Biblioteka	Gwiazdki na GitHub	Łączna liczba commitów	Ostatni commit	Pierwsza wersja	Wersja NPM	Pobrania NPM
aymericzip/intlayer				Kwiecień 2024
amannn/next-intl				Marzec 2021

Odznaki aktualizują się automatycznie.

Porównanie funkcji

Benchmark

Co było mierzone

Zestaw testów Benchmark Bloom buduje tę samą aplikację z każdą biblioteką: 10 stron (home, about, blog, careers, contact, FAQ, pricing, products, settings, team), 10 lokalizacji (en, fr, es, de, it, pt, zh, ja, ko, ru), identyczne komponenty i identyczną zawartość. Pomiary przeprowadzono na stronach w językach en i fr. Każda biblioteka została przetestowana w maksymalnie czterech strategiach ładowania:

Intlayer nie wymaga wariantu "scoped": kompilator automatycznie ogranicza zakres treści per komponent, więc wiersze static i dynamic są już zoptymalizowane pod tym kątem.

Dla każdego wariantu rejestrowano:

• Rozmiar biblioteki (Lib size): rozmiar gzip pustego komponentu importującego wyłącznie bibliotekę i18n.
• JS strony (Page JS): ilość JavaScript gzip pobieranego na stronę.
• % wycieku języka (Locale leak %): odsetek ciągów należących do języka, którego użytkownik nie przegląda.
• % wycieku strony (Page leak %): odsetek ciągów należących do innej podstrony.
• Średnia komponentu (Component avg): średni rozmiar gzip każdego komponentu skompilowanego w izolacji.
• Reaktywność E2E: czas od wyboru nowego języka do zaktualizowania html[lang] w DOM.
• Hydratacja: czas trwania fazy hydratacji w React.

Dane poniżej pochodzą z testu z dnia 2026-09-12 z użyciem bibliotek next-intl 4.14.2 i intlayer 9.5.1.

Wyniki w Next.js (App Router)

Jak interpretować wyniki

• Koszt środowiska uruchomieniowego. Aplikacja bazowa to 141.0 KB na stronę. next-intl zwiększa tę wartość do 153.6 KB (+12.6 KB gzip na każdej stronie), podczas gdy Intlayer narzuca zaledwie 141.3 KB (+0.3 KB).
• Wyciek treści. W najczęstszych konfiguracjach (static i dynamic) next-intl wysyła na każdej stronie ~90% ciągów z innych stron, ponieważ cały plik en.json trafia do dostawcy klienta. Osiągnięcie 0% wymaga ręcznego dzielenia katalogów, podczas gdy Intlayer robi to automatycznie.
• Rozmiar komponentu. Komponent wywołujący useTranslations() waży średnio 21.8 KB; ten sam komponent z useIntlayer() waży jedynie 6.9 KB.

Wyniki w TanStack Start (use-intl)

Jak interpretować wyniki

• Naiwna konfiguracja use-intl wysyła o 68.8 KB więcej kodu JS na stronę niż aplikacja bazowa.
• W trybie dynamic use-intl osiąga 119.4 KB, ale nadal generuje 89.8% wycieku stron.
• Różnica architektoniczna jest widoczna w rozmiarze komponentów: 76-87 KB w use-intl w porównaniu do 6-8 KB w Intlayerze.
• Przełączanie języka jest 2-4x szybsze w Intlayerze (3 ms vs 7-21 ms).

Dlaczego jest taka różnica? Scentralizowane katalogi vs kompilowane słowniki

next-intl podąża za klasycznym wzorcem: jeden plik JSON per język, ładowany w getRequestConfig, przekazywany do NextIntlClientProvider i odczytywany przez t("namespace.key").

.
├── messages
│   ├── en.json
│   └── fr.json
└── src
    ├── i18n
    │   ├── request.ts
    │   └── routing.ts
    ├── middleware.ts
    └── app
        └── [locale]
            ├── layout.tsx
            └── about
                └── page.tsx

Runtime nie może wiedzieć, jakich kluczy użyje dana strona, dlatego domyślnie wysyła cały katalog.

Intlayer odwraca tę relację. Treść deklarowana jest tuż obok komponentu:

.
├── intlayer.config.ts
└── src
    ├── middleware.ts
    └── app
        └── [locale]
            ├── layout.tsx
            └── about
                ├── page.tsx
                └── page.content.ts
    └── components
        └── Counter
            ├── index.tsx
            └── index.content.ts

Podczas budowania kompilator analizuje, które komponenty importują poszczególne słowniki i dołącza do paczki tylko to, co jest niezbędne dla aktywnego języka.

Aby uzyskać wyniki z wiersza dynamic, ustaw dictionary.importMode: 'dynamic' w intlayer.config.ts. Zobacz dokumentację optymalizacji paczki.

Doświadczenie programisty

Komponent klienta

next-intl

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

"use client";

import { useState } from "react";
import { useTranslations, useFormatter } from "next-intl";

export const Counter = () => {
  const t = useTranslations("counter");
  const format = useFormatter();
  const [count, setCount] = useState(0);

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

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

Synchroniczne komponenty serwerowe

Wspólne elementy interfejsu (pasek nawigacji, stopka, karty) są często komponentami serwerowymi renderowanymi wewnątrz komponentów klienckich, więc nie mogą być asynchroniczne (async).

next-intl

type ServerCounterProps = {
  t: (key: string) => string;
  formattedCount: string;
};

export const ServerCounter = ({ t, formattedCount }: ServerCounterProps) => (
  <div>
    <p>{formattedCount}</p>
    <button aria-label={t("label")}>{t("increment")}</button>
  </div>
);

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

Metadane

next-intl

import type { Metadata } from "next";
import { getTranslations } from "next-intl/server";
import { routing } from "@/i18n/routing";

const localizedPath = (locale: string, path: string) =>
  locale === routing.defaultLocale ? path : `/${locale}${path}`;

export const generateMetadata = async ({
  params,
}: {
  params: Promise<{ locale: string }>;
}): Promise<Metadata> => {
  const { locale } = await params;
  const t = await getTranslations({ locale, namespace: "about" });

  const languages = Object.fromEntries(
    routing.locales.map((l) => [l, localizedPath(l, "/about")])
  );

  return {
    title: t("title"),
    description: t("description"),
    alternates: {
      canonical: localizedPath(locale, "/about"),
      languages: { ...languages, "x-default": "/about" },
    },
  };
};

Intlayer

import { getIntlayer, getMultilingualUrls } from "intlayer";
import type { Metadata } from "next";
import type { LocalPromiseParams } from "next-intlayer";

export const generateMetadata = async ({
  params,
}: LocalPromiseParams): Promise<Metadata> => {
  const { locale } = await params;
  const metadata = getIntlayer("about-metadata", locale);
  const multilingualUrls = getMultilingualUrls("/about");

  return {
    ...metadata,
    alternates: {
      canonical: multilingualUrls[locale as keyof typeof multilingualUrls],
      languages: { ...multilingualUrls, "x-default": "/about" },
    },
  };
};

Zachowaj API next-intl, zyskaj lekki bundle z Intlayer

Nie musisz przepisywać komponentów, aby zyskać powyższe wyniki wydajnościowe. @intlayer/next-intl to adapter typu drop-in: zachowuje useTranslations, getTranslations, useFormatter, t.rich() i formaty ICU, serwując je ze słowników skompilowanych przez Intlayera.

import type { NextConfig } from "next";
import { createNextIntlPlugin } from "@intlayer/next-intl/plugin";

const withIntlayer = createNextIntlPlugin();

const nextConfig: NextConfig = {};

export default withIntlayer(nextConfig);

W testach wersja kompatybilna tej samej aplikacji zmniejszyła rozmiar z 153.6 KB do 147.5 KB na stronę, rozmiar komponentów z 21.8 KB do 8.1 KB, a wyciek strony spadł z ~90% do 0%, bez ingerencji w kod źródłowy aplikacji. Dotychczasowe pliki messages/{locale}.json mogą pozostać źródłem prawdy dzięki wtyczce synchronizacji JSON.

Zobacz przewodnik migracji z next-intl, aby poznać szczegóły krok po kroku.

Kiedy wybrać którą bibliotekę?

• Wybierz next-intl, jeśli zależy Ci na standardzie społeczności Next.js, intensywnie korzystasz z ICU MessageFormat, Twoja aplikacja jest mała lub średnia, albo integrujesz się ze scentralizowanymi platformami TMS (Crowdin, Phrase, Lokalise...).
• Wybierz Intlayer, jeśli zależy Ci na treści powiązanej z komponentami, ścisłym TypeScripcie, wykrywaniu brakujących kluczy w czasie budowania, automatycznym tree-shakingu i leniwym ładowaniu, synchronicznych komponentach serwerowych oraz wbudowanych narzędziach edycyjnych (Wizualny Edytor, CMS, tłumaczenia AI, serwer MCP).
• Wybierz @intlayer/next-intl, jeśli używasz już next-intl i chcesz zredukować rozmiar paczki bez konieczności przepisywania kodu.

Powiązane porównania

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

Gwiazdki na GitHub

Gwiazdki na GitHub to silny wskaźnik popularności projektu, zaufania społeczności i długoterminowej perspektywy rozwoju.

Podsumowanie

next-intl to solidna, dobrze utrzymywana biblioteka, a testy potwierdzają, że jest rozsądnym wyborem w świecie Next.js. Jednak scentralizowany model katalogów przerzuca całą odpowiedzialność za optymalizację na programistę: podstawowa konfiguracja powoduje wyciek około 90% treści z innych podstron, a sam runtime kosztuje +12.6 KB gzip na każdej stronie.

Intlayer przenosi tę pracę do kompilatora. Słowniki per komponent, leniwe ładowanie per język i usuwanie nieużywanych tłumaczeń to efekty procesu budowania. Rezultat w tej samej aplikacji: +0.3 KB na stronę, 0% wycieku, komponenty 3x mniejsze i przełączanie języka 2-4x szybsze w TanStack Start.

Wszystkie surowe dane, aplikacje testowe i skrypty znajdują się w repozytorium Benchmark Bloom.

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