next-intl проти Intlayer | Бенчмарк інтернаціоналізації (i18n) у React та Next.js

next-intl на сьогодні є стандартним вибором для i18n у Next.js App Router: тісна інтеграція з маршрутизацією, повна підтримка ICU MessageFormat та звичний досвід розробника для всіх, хто працював із класичними системами i18n.

Intlayer повністю переосмислює цей підхід: жодних централізованих словників, жодної потреби вручну прив'язувати простори імен (namespaces) до маршрутів. Контент оголошується безпосередньо поруч із кожним компонентом, а компілятор часу збирання пакує лише те, що дійсно потрібно кожній окремій сторінці.

У цій статті порівнюються дві бібліотеки на основі даних із Benchmark Bloom, відкритого набору тестів, який збирає однаковий додаток з кожною бібліотекою та фіксує те, що браузер насправді завантажує і виконує.

Коротко (tl;dr): next-intl додає щонайменше +12.6 КБ gzip на кожній сторінці лише через свій runtime і призводить до витоку ~90% рядків з інших сторінок у стандартних конфігураціях (static та dynamic). Щоб усунути цей витік, потрібно вручну розбивати каталоги на простори імен та підключати їх окремо для кожної сторінки. Натомість компілятор Intlayer гарантує 0% витоку, втричі менші компоненти та лише +0.3 КБ понад базовий додаток без будь-яких ручних налаштувань.

Короткий огляд

• next-intl - Стандарт спільноти Next.js. Централізовані словники JSON для кожної мови, повна підтримка ICU MessageFormat і глибока інтеграція з обробкою запитів та маршрутизацією Next.js.
• Intlayer - Модель контенту, орієнтована на компоненти. Файли .content.ts розташовані поруч із компонентами, компілятор часу збирання автоматично виконує tree-shaking та ліниве завантаження для кожного компонента і локалі, а також генерує суворі типи TypeScript.

Показати весь вміст таблиці

Показати весь вміст таблиці

Відкрийте таблицю в модальному вікні, щоб чітко переглянути всі дані

Бібліотека	Зірки GitHub	Всього комітів	Останній коміт	Перша версія	Версія NPM	Завантаження NPM
aymericzip/intlayer				Квітень 2024
amannn/next-intl				Березень 2021

Значки оновлюються автоматично.

Порівняння функціональності

Бенчмарк

Що вимірювалося

Набір тестів Benchmark Bloom збирає однаковий додаток з кожною бібліотекою: 10 сторінок (home, about, blog, careers, contact, FAQ, pricing, products, settings, team), 10 локалей (en, fr, es, de, it, pt, zh, ja, ko, ru), однакові компоненти та ідентичний вміст. Сторінки вимірюються мовами en та fr. Кожна бібліотека протестована в чотирьох стратегіях завантаження:

Intlayer не має варіанта "scoped": компілятор автоматично обмежує контекст контенту для кожного компонента, тому рядки static і dynamic уже оптимізовані за маршрутами.

Для кожного збирання фіксувалося:

• Розмір бібліотеки (Lib size): розмір gzip порожнього компонента, який імпортує лише бібліотеку i18n.
• JS сторінки (Page JS): кількість стиснутого gzip JavaScript на сторінку.
• % витоку локалі (Locale leak %): частка рядків мови, яку користувач не переглядає.
• % витоку сторінки (Page leak %): частка рядків сторінки, на якій користувач не перебуває.
• Середній розмір компонента (Component avg): середній розмір gzip кожного компонента, скомпільованого окремо.
• Реактивність E2E: час між перемиканням мови та оновленням html[lang] у DOM.
• Гідратація: тривалість фази гідратації React.

Наведені дані отримані під час тестування від 2026-09-12 з next-intl 4.14.2 та intlayer 9.5.1.

Результати на Next.js (App Router)

Як інтерпретувати результати

• Витрати runtime. Базовий додаток важить 141.0 КБ на сторінку. next-intl збільшує це значення до 153.6 КБ (+12.6 КБ gzip на кожній сторінці), тоді як Intlayer додає лише 141.3 КБ (+0.3 КБ).
• Витік контенту. У найпоширеніших конфігураціях (static та dynamic) next-intl відправляє на кожну сторінку ~90% рядків з інших сторінок, оскільки весь файл en.json потрапляє до клієнтського провайдера. Щоб зменшити цей показник до 0%, потрібен складний ручний поділ на простори імен, тоді як в Intlayer це працює за замовчуванням.
• Розмір компонента. Компонент із useTranslations() важить у середньому 21.8 КБ; той самий компонент з useIntlayer() важить лише 6.9 КБ.

Результати на TanStack Start (use-intl)

Як інтерпретувати результати

• Просте налаштування use-intl передає на 68.8 КБ більше JS на сторінку, ніж базовий додаток.
• У режимі dynamic use-intl досягає 119.4 КБ, але все одно зберігає 89.8% витоку сторінок.
• Архітектурна різниця особливо помітна у розмірі компонентів: 76-87 КБ у use-intl проти 6-8 КБ в Intlayer.
• Перемикання локалі відбувається у 2-4 рази швидше з Intlayer (3 мс проти 7-21 мс).

Чому виникає різниця? Централізовані каталоги проти скомпільованих словників

next-intl слідує класичній моделі: один JSON для кожної мови, завантажується в getRequestConfig, передається в NextIntlClientProvider і зчитується через t("namespace.key").

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

Runtime не може передбачити, які саме ключі знадобляться сторінці, тому відправка всього каталогу є єдиним безпечним варіантом.

Intlayer змінює цей підхід. Контент декларується безпосередньо поруч із компонентом:

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

Під час збирання компілятор визначає, який компонент імпортує конкретний словник, і пакує тільки ці словники для активної локалі.

Щоб отримати показники рядка dynamic, встановіть dictionary.importMode: 'dynamic' у intlayer.config.ts. Дивіться документацію з оптимізації бандла.

Досвід розробника

Клієнтський компонент

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

Синхронні серверні компоненти

Елементи дизайн-системи (навігаційні панелі, підвали, картки) часто є серверними компонентами, що відображаються всередині клієнтських компонентів, тому вони не можуть бути 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>
  );
};

Метадані

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

Збережіть API next-intl, отримайте оптимізований вихід Intlayer

Вам не потрібно переписувати компоненти, щоб отримати наведені вище результати продуктивності. Пакет @intlayer/next-intl є сумісним адаптером: він зберігає useTranslations, getTranslations, useFormatter, t.rich() та множинні форми ICU, обслуговуючи їх зі словників, скомпільованих компілятором Intlayer.

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

const withIntlayer = createNextIntlPlugin();

const nextConfig: NextConfig = {};

export default withIntlayer(nextConfig);

У бенчмарку сумісна збірка того самого додатка зменшила розмір сторінки з 153.6 КБ до 147.5 КБ, розмір компонентів з 21.8 КБ до 8.1 КБ, а витік сторінки знизився з ~90% до 0% без внесення змін у код самого додатка. Ваші наявні файли messages/{locale}.json можуть залишатися основним джерелом даних завдяки плагіну синхронізації JSON.

Дивіться посібник із міграції з next-intl для отримання покрокових інструкцій.

Що і коли обрати?

• Обирайте next-intl, якщо вам потрібен стандарт спільноти Next.js, ви повністю спираєтесь на ICU MessageFormat, ваш проєкт невеликий або середній, або ви використовуєте платформи перекладу з централізованими JSON (Crowdin, Phrase, Lokalise...).
• Обирайте Intlayer, якщо вам потрібен контент з прив'язкою до компонентів, суворий TypeScript, помилки про відсутні ключі під час збирання, автоматичний tree-shaking та ліниве завантаження, синхронні серверні компоненти та вбудовані інструменти редагування (Візуальний редактор, CMS, переклад за допомогою ШІ, сервер MCP).
• Обирайте @intlayer/next-intl, якщо ви вже використовуєте next-intl і бажаєте отримати переваги в оптимізації бандла без переписування коду.

Схожі порівняння

• i18next проти Intlayer (той самий бенчмарк)
• Lingui проти Intlayer (той самий бенчмарк)
• Бенчмарк vue-i18n проти Intlayer (той самий бенчмарк)
• next-i18next проти next-intl проти Intlayer
• Чи застарів next-intl?

Зірки GitHub

Зірки на GitHub є важливим показником популярності проєкту, довіри спільноти та його довгострокової актуальності.

Висновок

next-intl - це надійна, перевірена часом бібліотека, і бенчмарк підтверджує, що вона залишається хорошим вибором для Next.js. Проте централізована модель каталогів перекладає всю оптимізацію на розробника: стандартне налаштування призводить до витоку близько 90% вмісту інших сторінок, а сам runtime коштує +12.6 КБ gzip на кожній сторінці.

Intlayer переносить усю цю роботу до компілятора. Словники для кожного компонента, ліниве завантаження для кожної мови та очищення невикористаного контенту стають автоматичними результатами збирання. Результат на тому ж додатку: +0.3 КБ на сторінку, 0% витоку, компоненти втричі менші, а перемикання мови у 2-4 рази швидше на TanStack Start.

Усі вихідні дані, тестові додатки та скрипти доступні у репозиторії Benchmark Bloom.

Зверніться до документа 'Чому Intlayer?' для отримання детальнішої інформації.