next-intl VS Intlayer

next-intl - самая популярная библиотека i18n для Next.js. Intlayer - это альтернатива на основе компилятора с областью видимости компонента. Обе локализуют приложение App Router. Вопрос в том, какие затраты каждая из них влечет после сборки приложения.

Эта статья - не учебное пособие. Это сравнение, подкрепленное числами из Benchmark Bloom, открытого набора инструментов для тестирования, который создает одно и то же приложение с каждой библиотекой и измеряет то, что браузер фактически загружает и выполняет.

tl;dr: На одном и том же приложении Next.js next-intl добавляет +12.6 KB gzip JavaScript на каждую страницу, против +0.3 KB для Intlayer. Без дополнительной работы next-intl поставляет ~90% строк иностранных страниц с каждой страницей. Чтобы достичь утечки 0% с next-intl, требуется область видимости namespace и per-page pick(messages, [...]). Intlayer достигает 0% по умолчанию, потому что его компилятор ограничивает контент для каждого компонента. Если вы хотите API next-intl с выходом Intlayer, адаптер @intlayer/next-intl показал 147.5 KB на страницу против 153.6 KB с оригиналом.

Вкратце

• next-intl - Легковесная, хорошо документированная, поддержка ICU message format, встроенная поддержка App Router с middleware, форматировщиками и помощниками навигации. Контент хранится в централизованных JSON каталогах; оптимизация производительности (namespaces, выборка сообщений для каждой страницы, ленивая загрузка) - ваша ответственность.
• Intlayer - Компонентоцентричная модель контента. Словари .content.ts находятся рядом с компонентом, который они обслуживают, compiler во время сборки выполняет tree-shaking и ленивую загрузку для каждого компонента и локали, строгие типы TypeScript генерируются из вашего контента, и отсутствующие переводы вызывают ошибку во время сборки. Поставляется с middleware, помощниками SEO, Visual Editor / CMS и переводом с поддержкой AI.

Показать все данные таблицы

Показать все данные таблицы

Открыть таблицу в модальном окне для четкого просмотра всех данных

Библиотека	GitHub Stars	Всего коммитов	Последний коммит	Первая версия	NPM версия	Загрузки NPM
aymericzip/intlayer				Апрель 2024
amannn/next-intl				Nov 2020

Значки обновляются автоматически. Снимки экрана будут изменяться с течением времени.

Сравнение функций "рядом"

Бенчмарк

Что было измерено

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 библиотеку. Фиксированная стоимость runtime.
• Page JS: gzip JavaScript, скачанный на страницу, усреднённый по всем страницам и локалям.
• Locale leak %: доля переведённых строк, найденных в скачанном JS, которые принадлежат локали, которую пользователь не просматривает (отпечатано на en и fr, поэтому 50% означает "другая измеренная локаль полностью присутствует"; с 10 связанными локалями, реальные потери выше).
• Page leak %: доля переведённых строк, найденных в скачанном JS, которые принадлежат странице, на которой пользователь не находится.
• Component avg: средний gzip размер каждого компонента, скомпилированного в изоляции. Показывает, сколько i18n runtime один компонент тянет за собой.
• E2E reactivity: время в реальном масштабе времени между выбором нового языка и обновлением html[lang] в DOM (Playwright, 5 итераций).
• Hydration: продолжительность фазы гидрации React.

Приведённые ниже числа получены из запуска от 2026-09-12 с next-intl 4.14.2, use-intl 4.14.2 и intlayer 9.5.1. Тестовое приложение намеренно небольшое (несколько десятков строк на язык), поэтому процентные значения утечек описывают паттерн: они растут вместе с вашим контентом, тогда как стоимость runtime остаётся постоянной.

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

Выберите метрики и библиотеки, которые вас интересуют:

Как это читать

• Стоимость runtime. Базовое приложение весит 141.0 KB на страницу. next-intl доводит это значение до 153.6 KB (+12.6 KB gzip на каждой странице), Intlayer до 141.3 KB (+0.3 KB). Этот разрыв не зависит от количества строк: это runtime библиотеки.
• Leakage. В двух конфигурациях, которые большинство команд фактически используют (static и dynamic), next-intl доставляет ~90% строк иностранных страниц на каждую страницу: весь en.json попадает в клиентский провайдер. Чтобы достичь 0%, требуются конфигурации scoped-*: разделить каталоги на namespaces, затем выбрать нужные с помощью pick() на каждой странице. Intlayer находится на 0% в обоих случаях без всего этого.
• JavaScript на странице не изменился для next-intl между стратегиями. Тестовое содержимое небольшое, поэтому утечка ~90% составляет всего несколько KB здесь. В реальном приложении со сотнями строк на странице это соотношение становится доминирующей стоимостью. Тем временем +12.6 KB runtime оплачивается в каждой конфигурации.
• Размер компонента. Компонент, который вызывает useTranslations(), компилируется в среднем до 21.8 KB; тот же компонент с useIntlayer() компилируется до 6.9 KB. В конфигурации scoped-static компоненты next-intl увеличиваются до 80.1 KB, потому что каждый встраивает свой каталог пространства имен.
• Реактивность и гидратация находятся в одном диапазоне для обеих библиотек на Next.js (15-18 мс). Ни одна из них не является узким местом здесь.

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

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

use-intl - это не зависящее от фреймворка ядро next-intl. Тот же API, тот же формат сообщений. Его сравнение с intlayer на TanStack Start исключает из уравнения части, специфичные для Next.js.

Как это читать

• Наивная конфигурация use-intl доставляет на 68.8 KB больше JS на страницу чем базовое приложение, причём половина строк принадлежит неправильной локали и 90% неправильной странице.
• use-intl в режиме dynamic достигает 119.4 KB, близко к 118.6 KB Intlayer, но все еще несет 89.8% утечку страницы: строки всех страниц для активной локали загружаются на каждой странице. Их группировка по маршруту (scoped-*) устраняет утечку, но добавляет еще ~9 KB накладных расходов на chunk.
• В Intlayer строка static уже имеет 0% утечку страницы: компилятор собирает только словари, используемые компонентами на странице. Включение importMode: 'dynamic' (одна строка в intlayer.config.ts) также устраняет утечку локали.
• Размер компонента показывает разницу в архитектуре: 76-87 KB на компонент с use-intl против 6-8 KB с Intlayer. useTranslations() привязывает каждый компонент к глобальному дереву сообщений; useIntlayer() привязывает его к собственному словарю.
• Переключение локали в 2-4 раза быстрее с Intlayer (3 мс против 7-21 мс).

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

Почему такая разница? Централизованные каталоги vs скомпилированные словари

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 не может знать, какие ключи будет использовать страница, поэтому безопасный стандарт - отправить весь каталог. Оптимизация означает, что вы разделяете каталог на пространства имён, вы решаете, какие пространства имён нужны каждой странице, и вы поддерживаете это соответствие в синхронизации при перемещении компонентов. Строка scoped-dynamic в тесте производительности - это награда за эту работу, и большинство команд туда никогда не доходят.

Цена недостижения этой цели растет сразу по двум осям, страницы и локали:

Intlayer переворачивает ответственность. Контент объявляется рядом с компонентом:

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

При сборке компилятор (@intlayer/swc / @intlayer/babel) видит, какой компонент импортирует какой словарь. Он объединяет только те словари, только для активной локали, и удаляет те, которые ничто не импортирует. Паттерн "scoped-dynamic" становится результатом сборки вместо дисциплины, которую команда должна поддерживать.

Чтобы получить цифры dynamic строки, установите dictionary.importMode: 'dynamic' в intlayer.config.ts. См. документацию по оптимизации bundle.

Опыт разработчика

Client компонент

{
  "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({ ru: "Счётчик", en: "Counter", fr: "Compteur" }),
    increment: t({ ru: "Увеличить", 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>
  );
};

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

Компоненты системы проектирования (navbar, footer, карточки) часто являются серверными компонентами, отрендеренными как дочерние элементы клиентских компонентов, поэтому они не могут быть 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 plurals и помощники next-intl/navigation, и предоставляет их из словарей Intlayer, скомпилированных компилятором Intlayer.

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

const withIntlayer = createNextIntlPlugin();

const nextConfig: NextConfig = {};

export default withIntlayer(nextConfig);

В benchmark, compat-сборка того же приложения сократилась с 153.6 KB до 147.5 KB за страницу, с 21.8 KB до 8.1 KB за компонент, и с ~90% page leakage на 0%, при этом код приложения остался без изменений. Ваши существующие файлы messages/{locale}.json могут остаться источником истины благодаря JSON sync plugin.

Смотрите руководство миграции next-intl для пошагового процесса.

Когда выбрать что?

Часто задаваемые вопросы

Связанные сравнения

Тот же бенчмарк, другие библиотеки:

Подробнее о next-intl:

Справочная документация:

Чтобы понять, откуда взялись эти библиотеки, прочитайте историю i18n в JavaScript.

GitHub STARs

GitHub stars - это сильный индикатор популярности проекта, доверия сообщества и долгосрочной актуальности. Хотя это не прямая мера технического качества, они отражают, сколько разработчиков находят проект полезным, следят за его развитием и, вероятно, готовы его использовать.

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

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

Intlayer это монорепозиторий, поэтому в счёт входят все пакеты для фреймворков, CLI и документация. Считайте коммиты показателем активности, а не качества.

Загрузки npm

Число загрузок вознаграждает самые старые решения, а не лучшие. Библиотеку, выпущенную много лет назад, до сих пор устанавливает каждый проект, который выбрал её тогда, каждый запуск CI и каждый зависящий от неё пакет. Эта цифра измеряет инерцию, а не осознанный выбор.

ИИ-ассистенты усиливают этот эффект. next-intl, i18next и vue-i18n повсюду встречаются в коде, на котором они обучались, поэтому ассистенты предлагают их по умолчанию, не сравнивая альтернативы. Каждая подсказка добавляет загрузки, которые подпитывают следующую. Сравнивайте по бенчмарку, а не по числу загрузок.

Заключение

next-intl - это надежная, хорошо поддерживаемая библиотека, и benchmark подтверждает, что это далеко не худший вариант для Next.js. Однако её централизованная модель каталога возлагает все оптимизации на разработчика: наивная конфигурация пропускает ~90% контента иностранных страниц, а само runtime стоит +12,6 KB gzip на каждой странице.

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

Все необработанные данные, тестовые приложения и скрипты находятся в репозитории Benchmark Bloom. Запустите его самостоятельно.

Обратитесь к документации 'Why Intlayer?' для получения дополнительных сведений.