Решения для интернационализации являются одними из самых тяжелых зависимостей в Svelte-приложении. Основной риск заключается в передаче ненужного контента: переводов для других страниц и других локалей в бандле одного маршрута.

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

На практике в наименее оптимизированных реализациях интернационализированная страница может оказаться в несколько раз тяжелее версии без i18n.

Другой аспект - это опыт разработчика: то, как вы объявляете контент, типы, организацию пространств имен, динамическую загрузку и реактивность при смене локали.

TL;DR

Intlayer: Самый эффективный выбор с точки зрения производительности (v8.7.12) с минимальным влиянием на размер.
Paraglide: Сильный конкурент для tree-shaking, но имеет более сложный опыт разработки и накладные расходы на реактивность.
svelte-i18n: Полнофункциональный и стандартный для Svelte, но имеет гораздо больший вес бандла (~7 раз больше Intlayer).

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

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

intlayer.org

Проблема

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

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

Понимание технических ограничений этих подходов:

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

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

При использовании динамической загрузки вы идете на компромисс: меньше начального JS, но иногда дополнительный запрос при переключении языка.

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

Синтаксис, построенный вокруг t('a.b.c'), очень удобен, но часто способствует хранению больших JSON-объектов во время выполнения. Эта модель затрудняет tree-shaking, если библиотека не предлагает реальную стратегию разделения контента для каждой страницы.

Методология

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

Base App (Без библиотеки i18n)
svelte-intlayer (v8.7.12)
svelte-i18n (v4.0.1)
@inlang/paraglide-js (v2.17.0)

Фреймворк - Svelte с мультиязычным приложением из 10 страниц и 10 языков.

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

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

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

Стратегия	Без пространств имен (глобальная)	С пространствами имен (локальная/scoped)
Статическая загрузка	Static: Все в памяти при запуске.	Scoped static: Разделено по пространствам имен; все загружается при запуске.
Динамическая загрузка	Dynamic: Загрузка по требованию для локали.	Scoped dynamic: Гранулярная загрузка по пространствам имен и локалям.

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

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

Звезды на GitHub

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

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

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

В экосистеме Svelte нет однозначных решений, которых следует избегать.

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

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

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

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

(svelte-i18n) (svelte-i18n@3.4.0):

Это решение отвечает всем потребностям i18n в Svelte-проекте. Но, как и в случае с i18next или другими основными решениями i18n, оно немного тяжеловато (~15.9 КБ, что примерно в 7 раз больше svelte-intlayer).

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

(Intlayer) (svelte-intlayer@8.7.12):

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

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

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

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

Solid