Библиотеки i18n для Next.js - Отчет о бенчмарке 2026

Эта страница представляет собой отчет о бенчмарке i18n-решений для Next.js.

Содержание

Интерактивный бенчмарк

Ссылка на результаты:

Посмотреть полные данные бенчмарка

Полный репозиторий бенчмарка можно найти здесь.

Введение

Библиотеки интернационализации оказывают серьезное влияние на ваше приложение. Основной риск заключается в загрузке контента для каждой страницы и каждого языка, когда пользователь посещает только одну страницу.

По мере роста вашего приложения размер бандла может расти экспоненциально, что может заметно снизить производительность.

Например, в худших случаях после интернационализации ваша страница может стать почти в 4 раза больше.

Еще одним последствием использования библиотек i18n является замедление разработки. Превращение компонентов в мультиязычный контент на разных языках отнимает много времени.

Поскольку проблема сложна, существует множество решений - одни ориентированы на DX, другие на производительность или масштабируемость и так далее.

Intlayer пытается оптимизировать все эти аспекты.

TL;DR

• Intlayer и next-translate: Лучшие варианты для производительности Next.js, предлагающие минимальный размер и лучшую поддержку статического рендеринга.
• next-intl: Самый модный вариант, но тяжелый и сложный в оптимизации для больших приложений.
• next-i18next: Популярный и богатый плагинами, но имеет значительный вес бандла (~3× Intlayer).
• Избегайте: gt-next и lingo.dev из-за серьезных проблем с производительностью, привязки к вендору и багов, ломающих сборку.

Проверьте свое приложение

Чтобы выявить эти проблемы, я создал бесплатный сканер, который вы можете попробовать здесь.

Проблема

Существует два основных способа ограничить влияние мультиязычного приложения на ваш бандл:

• Разделение вашего JSON (или контента) по файлам / переменным / пространствам имен (namespaces), чтобы сборщик мог исключить (tree-shake) неиспользуемый контент для конкретной страницы.
• Динамическая загрузка контента страницы только на языке пользователя.

Технические ограничения этих подходов:

Динамическая загрузка

Даже если вы объявляете маршруты типа [locale]/page.tsx, с Webpack или Turbopack, и даже если определен generateStaticParams, сборщик не рассматривает locale как статическую константу. Это означает, что он может включить контент для всех языков в каждую страницу. Основной способ ограничить это - загружать контент через динамический импорт (например, import('./locales/${locale}.json')).

На этапе сборки Next.js создает один JS-бандл на локаль (например, ./locales_fr_12345.js). Когда сайт отправляется клиенту и страница запускается, браузер выполняет дополнительный HTTP-запрос для необходимого JS-файла (например, ./locales_fr_12345.js).

Другой способ решения той же проблемы - использование fetch() для динамической загрузки JSON. Так работает Tolgee, когда JSON находится в /public, или next-translate, который полагается на getStaticProps для загрузки контента. Процесс тот же: браузер делает дополнительный HTTP-запрос для загрузки ресурса.

Разделение контента

Если вы используете синтаксис типа const t = useTranslation() + t('my-object.my-sub-object.my-key'), весь JSON обычно должен быть в бандле, чтобы библиотека могла его проанализировать и разрешить ключ. Большая часть этого контента попадает в сборку, даже если он не используется на странице.

Чтобы смягчить это, некоторые библиотеки просят вас указывать для каждой страницы, какие пространства имен загружать - например, next-i18next, next-intl, lingui, next-translate, next-international.

Напротив, Paraglide добавляет дополнительный шаг перед сборкой, чтобы превратить JSON в плоские символы, такие как const en_my_var = () => 'my value'. Теоретически это позволяет исключать неиспользуемый контент на странице. Как мы увидим, у этого метода все же есть свои компромиссы.

Наконец, Intlayer применяет оптимизацию на этапе сборки, поэтому useIntlayer('my-key') заменяется на соответствующий контент напрямую.

Методология

Для этого бенчмарка мы сравнили следующие библиотеки:

• Base App (Без библиотеки i18n)
• next-intlayer (v8.7.12)
• next-i18next (v16.0.5)
• next-intl (v4.9.1)
• @lingui/core (v5.3.0)
• next-translate (v3.1.2)
• next-international (v1.3.1)
• @inlang/paraglide-js (v2.15.1)
• @tolgee/react (v7.0.0)
• @lingo.dev/compiler (v0.4.0)
• wuchale (v0.22.11)
• gt-next (v6.16.5)

Я использовал Next.js версии 16.2.4 с App Router.

Я построил мультиязычное приложение с 10 страницами и 10 языками.

Я сравнил четыре стратегии загрузки:

Резюме стратегий

• Статическая (Static): Простота; отсутствие задержек сети после начальной загрузки. Минус: большой размер бандла.
• Динамическая (Dynamic): Уменьшает начальный вес (ленивая загрузка). Идеально при наличии множества локалей.
• Локальная статическая (Scoped static): Позволяет организовать код (логическое разделение) без сложных дополнительных сетевых запросов.
• Локальная динамическая (Scoped dynamic): Лучший подход для разделения кода и производительности. Минимизирует использование памяти, загружая только то, что нужно для текущего представления и активной локали.

Что я измерял:

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

• Размер библиотеки интернационализации: После сборки, tree-shaking и минимизации, размер i18n-библиотеки - это размер провайдеров (например, NextIntlClientProvider) + код хуков (например, useTranslations) в пустом компоненте. Это не включает загрузку файлов перевода. Это ответ на вопрос, насколько "дорогая" библиотека сама по себе до добавления вашего контента.

• JavaScript на страницу: Для каждого маршрута бенчмарка - сколько скриптов браузер загружает при посещении, усредненное по страницам в наборе (и по локалям, где отчет их объединяет). Тяжелые страницы - это медленные страницы.

• Утечка из других локалей: Это контент той же страницы, но на другом языке, который ошибочно загружается на проверяемую страницу. Этого контента следует избегать (например, контент страницы /fr/about в бандле страницы /en/about).

• Утечка из других маршрутов: Та же идея для других экранов в приложении: попадает ли их текст в сборку, когда вы открыли только одну страницу (например, контент страницы /en/about в бандле страницы /en/contact). Высокий показатель указывает на плохое разделение или слишком широкие бандлы.

• Средний размер бандла компонента: Общие элементы пользовательского интерфейса измеряются по отдельности, а не прячутся внутри одного гигантского числа приложения. Это показывает, не раздувает ли интернационализация обычные компоненты. Например, если ваш компонент перерендеривается, он будет загружать все эти данные из памяти. Привязка гигантского JSON-файла к любому компоненту подобна подключению большого хранилища неиспользуемых данных, которое замедлит работу ваших компонентов.

• Скорость переключения языка: Я переключаю язык с помощью собственного элемента управления приложения и засекаю время, пока страница явно не переключится - то, что заметит посетитель, а не лабораторный микро-шаг.

• Работа по рендерингу после смены языка: Более узкое наблюдение: сколько усилий потребовалось интерфейсу для перерисовки на новом языке после начала переключения. Полезно, когда "ощущаемое" время и стоимость фреймворка расходятся.

• Время начальной загрузки страницы: От перехода до того момента, когда браузер считает страницу полностью загруженной для протестированных сценариев. Хорошо для сравнения "холодных стартов".

• Время гидратации: Когда приложение предоставляет такие данные - сколько времени клиент тратит на превращение серверного HTML в нечто, на что можно нажать. Прочерк в таблицах означает, что данная реализация не предоставила надежных данных по гидратации в этом бенчмарке.

Звезды на GitHub

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

Результаты в деталях

1 - Решения, которых следует избегать

Некоторых решений, таких как gt-next или lingo.dev, явно лучше избегать. Они сочетают в себе привязку к вендору с загрязнением вашей кодовой базы. Несмотря на многие часы попыток их внедрить, мне так и не удалось заставить их работать - ни на TanStack Start, ни на Next.js.

Встреченные проблемы:

(General Translation) (gt-next@6.16.5):

• Для приложения весом 110 КБ gt-next добавляет более 440 КБ сверху.
• Quota Exceeded, please upgrade your plan (Квота превышена, пожалуйста, обновите тарифный план) при самой первой сборке с General Translation.
• Переводы не отображаются; я получаю ошибку Error: <T> used on the client-side outside of <GTProvider>, что кажется багом библиотеки.
• При внедрении gt-next я также столкнулся с проблемой в библиотеке: does not provide an export named 'printAST' - @formatjs/icu-messageformat-parser, которая приводила к поломке приложения. После сообщения об этой проблеме сопровождающий исправил ее в течение 24 часов.
• Библиотека блокирует статический рендеринг страниц Next.js.

(Lingo.dev) (@lingo.dev/compiler@0.4.0):

• Квота AI превышена, что полностью блокирует сборку - вы не можете отправить приложение в продакшн без оплаты.
• Компилятор пропустил почти 40% переведенного контента. Мне пришлось переписать все вызовы .map в плоские блоки компонентов, чтобы это заработало.
• Их CLI работает с ошибками и периодически сбрасывает конфигурационный файл без причины.
• При сборке он полностью удалял сгенерированные JSON-файлы при добавлении нового контента. В результате несколько ключей могли стереть более 300 существующих ключей.

2 - Экспериментальные решения

(Wuchale) (wuchale@0.22.11):

Идея Wuchale интересна, но проект пока не жизнеспособен. Я столкнулся с проблемами реактивности и был вынужден принудительно перерендеривать провайдер, чтобы приложение заработало. Документация также довольно неясная, что затрудняет начало работы.

(Paraglide) (@inlang/paraglide-js@2.15.1):

Paraglide предлагает инновационный, хорошо продуманный подход. Тем не менее, в этом бенчмарке разрекламированный tree-shaking не сработал для моих настроек Next.js или TanStack Start. Процесс работы и DX сложнее, чем у других вариантов. Лично мне не нравится необходимость перегенерировать JS-файлы перед каждым пушем, что создает постоянный риск конфликтов слияния в PR. Инструмент также кажется более ориентированным на Vite, чем на Next.js. Наконец, по сравнению с другими решениями, Paraglide не использует хранилище (например, React context) для получения текущей локали для рендеринга контента. Для каждого обрабатываемого узла он запрашивает локаль из localStorage / куки и т.д. Это приводит к выполнению ненужной логики, которая влияет на реактивность компонентов.

Примечание по paraglide: решение внедряет код в вашу кодовую базу для импорта, в результате показатель 'размер библиотеки' в отчете о бенчмарке практически равен 0. Генерация кода - это хорошо, так как используемая функция будет включать только необходимую логику (все префиксы против отсутствия префиксов, куки против хранилища и т.д.). В сравнении с этим, Intlayer выполняет фильтрацию с помощью внедрения переменных окружения в сборку, чтобы заставить сборщик исключить контент в зависимости от логики. Благодаря этому paraglide и intlayer оказываются в 6-10 раз легче, чем i18next или next-intl.

3 - Приемлемые решения

(Tolgee) (@tolgee/react@7.0.0):

Tolgee решает многие из упомянутых ранее проблем. Мне показалось, что его сложнее внедрить, чем аналогичные инструменты. Он не обеспечивает типобезопасность, что также затрудняет отлов отсутствующих ключей на этапе компиляции. Мне пришлось обернуть функции Tolgee своими собственными, чтобы добавить обнаружение отсутствующих ключей.

(Next Intl) (next-intl@4.9.1):

next-intl - самый модный вариант, который чаще всего продвигают AI-агенты, но, на мой взгляд, ошибочно. Начать работу легко. На практике оптимизация для ограничения утечек сложна. Сочетание динамической загрузки + пространств имен + типов TypeScript сильно замедляет разработку. Пакет также довольно тяжелый (~13 КБ для NextIntlClientProvider + useTranslations, что более чем в 2 раза больше next-intlayer). next-intl раньше блокировал статический рендеринг страниц Next.js. Он предоставляет помощник под названием setRequestLocale(). Кажется, это частично решено для централизованных файлов типа en.json / fr.json, но статический рендеринг все равно ломается, когда контент разделен на пространства имен, такие как en/shared.json / fr/shared.json / es/shared.json.

(Next I18next) (next-i18next@16.0.5):

next-i18next, вероятно, является самым популярным вариантом, так как был одним из первых i18n-решений для JavaScript-приложений. У него много плагинов от сообщества. У него те же основные недостатки, что и у next-intl. Пакет особенно тяжелый (~18 КБ для I18nProvider + useTranslation, примерно в 3 раза тяжелее next-intlayer).

Форматы сообщений также различаются: next-intl использует ICU MessageFormat, тогда как i18next использует свой собственный формат.

(Next International) (next-international@1.3.1):

next-international также решает вышеуказанные проблемы, но не сильно отличается от next-intl или next-i18next. Он включает scopedT() для переводов внутри пространств имен, но его использование практически не влияет на размер бандла.

(Lingui) (@lingui/core@5.3.0):

Lingui часто хвалят. Лично мне рабочий процесс с lingui extract / lingui compile показался более сложным, чем у альтернатив, без явных преимуществ. Я также заметил непоследовательный синтаксис, который путает AI (например, t(), t'', i18n.t(), <Trans>).

4 - Рекомендации

(Next Translate) (next-translate@3.1.2):

next-translate - моя основная рекомендация, если вам нравится API в стиле t(). Он элегантен благодаря next-translate-plugin, загружая пространства имен через getStaticProps с помощью загрузчика Webpack / Turbopack. Это также самый легкий вариант (~2.5 КБ). Что касается пространств имен, их определение для каждой страницы или маршрута в конфиге хорошо продумано и проще в обслуживании, чем основные альтернативы, такие как next-intl или next-i18next. В версии 3.1.2 я заметил, что статический рендеринг не работал; Next.js откатывался к динамическому рендерингу.

(Intlayer) (next-intlayer@8.7.12):

Я не буду лично судить о next-intlayer ради объективности, так как это мое собственное решение.

Личное примечание

Это примечание является личным и не влияет на результаты бенчмарка. В мире i18n часто можно увидеть консенсус вокруг паттерна const t = useTranslation('xx') + <>{t('xx.xx')}</>.

В React-приложениях внедрение функции в качестве ReactNode, на мой взгляд, является антипаттерном. Это также добавляет лишнюю сложность и накладные расходы на выполнение JavaScript (хотя они почти незаметны).