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

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

Ця стаття не є посібником. Це порівняння, підтверджене даними з 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 КБ.

Повна таблиця, кожна бібліотека та кожна стратегія, у звіті бенчмарку Next.js.

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

use-intl, це незалежне від фреймворку ядро next-intl. Той самий API, той самий формат повідомлень. Порівняння його з intlayer на TanStack Start усуває особливості Next.js із рівняння.

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

• Просте налаштування 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 мс).

Повна таблиця у звіті бенчмарку TanStack Start.

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

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. Дивіться документацію з оптимізації бандла.

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

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

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

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.

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

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

Метадані

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

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:

Довідкова документація:

Щоб зрозуміти, звідки взялися ці бібліотеки, прочитайте історію i18n у JavaScript.

Зірки GitHub

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

Активність комітів

Зірки показують популярність. Коміти показують, скільки роботи вкладено в проєкт. На момент написання Intlayer має близько 7 500 комітів: більше, ніж більшість порівнюваних тут бібліотек, і приблизно в 5 разів більше, ніж next-intl чи next-i18next.

Intlayer це монорепозиторій, тож до підрахунку входять усі пакети для фреймворків, CLI та документація. Сприймайте коміти як показник активності, а не якості.

Завантаження npm

Кількість завантажень винагороджує найстаріші рішення, а не найкращі. Бібліотеку, випущену багато років тому, досі встановлює кожен проєкт, що обрав її тоді, кожен запуск CI і кожен пакет, який від неї залежить. Ця цифра вимірює інерцію, а не свідомий вибір.

ШІ-асистенти посилюють цей ефект. next-intl, i18next і vue-i18n трапляються всюди в коді, на якому їх навчали, тож вони пропонують їх за замовчуванням, не порівнюючи альтернатив. Кожна підказка додає завантажень, які живлять наступну підказку. Порівнюйте за бенчмарком, а не за кількістю завантажень.

Висновок

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

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

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

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