Задайте питання та отримайте підсумок документа, вказавши цю сторінку та обраного вами постачальника штучного інтелекту
Історія версій
- "Додати порівняння зірок GitHub"v8.9.818.05.2026
- "Ініціалізація бенчмарку"v8.7.1206.01.2026
Вміст цієї сторінки перекладено за допомогою штучного інтелекту.
Переглянути останню версію оригінального вмісту англійськоюЯкщо у вас є ідея щодо покращення цієї документації, будь ласка, долучіться, надіславши pull request на GitHub.
Посилання на документацію на GitHubСкопіювати документацію у форматі Markdown в буфер обміну
Бібліотеки i18n для Svelte - Звіт про бенчмарк 2026
Ця сторінка є звітом про бенчмарк рішень i18n на Svelte.
Зміст
Інтерактивний бенчмарк
Посилання на результати:
Переглянути повні дані бенчмарку
Повний репозиторій бенчмарку можна знайти тут.
Вступ
Рішення для інтернаціоналізації є одними з найважчих залежностей у додатку Svelte. Основний ризик полягає у відправці непотрібного контенту: перекладів для інших сторінок та інших локалей у бандлі одного маршруту.
З ростом вашого додатка ця проблема може швидко збільшити обсяг JavaScript, що надсилається клієнту, і сповільнити навігацію.
На практиці, для найменш оптимізованих реалізацій, інтернаціоналізована сторінка може виявитися в кілька разів важчою, ніж версія без i18n.
Інший вплив стосується досвіду розробника (DX): як ви оголошуєте контент, типи, організацію просторів імен, динамічне завантаження та реактивність при зміні локалі.
TL;DR
- Intlayer: Найефективніший за продуктивністю вибір (v8.7.12) з найменшим слідом (footprint).
- Paraglide: Сильний претендент для tree-shaking, але має складніший досвід розробника та накладні витрати на реактивність.
- svelte-i18n: Комплексний та стандартний для Svelte, але несе значно більшу вагу бандла (~7 разів більше за Intlayer).
Протестуйте свій додаток
Щоб швидко виявити проблеми з витоком i18n, я налаштував безкоштовний сканер, доступний тут.
Проблема
Два важелі є важливими для обмеження вартості багатомовного додатка:
- Розділіть контент за сторінками / просторами імен, щоб не завантажувати цілі словники, коли вони не потрібні.
- Завантажуйте потрібну локаль динамічно, тільки коли це необхідно.
Розуміння технічних обмежень цих підходів:
Динамічне завантаження
Без динамічного завантаження більшість рішень зберігають повідомлення в пам'яті з першого рендеру, що додає значне навантаження для додатків з багатьма маршрутами та локалями.
З динамічним завантаженням ви приймаєте компроміс: менше початкового JS, але іноді додатковий запит при зміні мови.
Поділ контенту (Splitting)
Синтаксис, побудований навколо 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: Зменшує початкову вагу (lazy-loading). Ідеально, коли у вас багато локалей.
- Scoped static: Зберігає код організованим (логічне розділення) без складних додаткових мережевих запитів.
- Scoped dynamic: Найкращий підхід для code splitting та продуктивності. Мінімізує пам'ять, завантажуючи лише те, що потрібно поточному перегляду та активній локалі.
Зірки на GitHub
Зірки на GitHub є потужним індикатором популярності проекту, довіри спільноти та довгострокової актуальності. Хоча вони не є прямим показником технічної якості, вони відображають, скільки розробників вважають проект корисним, стежать за його розвитком і, ймовірно, впровадять його. Для оцінки цінності проекту зірки допомагають порівняти інтерес до альтернатив і дають уявлення про зростання екосистеми.
Результати детально
1 - Рішення, яких слід уникати
В екосистемі Svelte немає очевидних рішень, яких слід уникати.
2 - Прийнятні рішення
(Paraglide) (@inlang/[email protected]):
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 / cookie тощо. Це призводить до виконання непотрібної логіки, яка впливає на реактивність компонентів.
Примітка щодо paraglide: рішення впорскує код у вашу кодову базу для імпорту; як результат, метрика 'lib size' у звіті бенчмарку становить майже 0. Генерація коду - це добре, тому що використана функція включатиме лише необхідну логіку (префікс скрізь проти відсутності префікса, кукі проти сховища тощо). Для порівняння, Intlayer виконує цю фільтрацію за допомогою впорскування змінних оточення під час збірки, щоб змусити бандлер виконувати tree-shaking контенту залежно від логіки. Завдяки цьому paraglide та intlayer стають у 6–10 разів легшими рішеннями, ніж i18next або next-intl.
(svelte-i18n) ([email protected]):
Це рішення задовольняє всі потреби i18n у проєкті Svelte. Але як і у випадку з i18next або іншими великими i18n рішеннями, воно трохи важке (~15.9kb, що приблизно в 7 разів більше за svelte-intlayer).
3 - Рекомендації
(Intlayer) ([email protected]):
Я не буду особисто оцінювати svelte-intlayer заради об'єктивності, оскільки це моє власне рішення.
Особиста примітка
Ця примітка є особистою і не впливає на результати бенчмарку. Тим не менш, у світі i18n часто можна побачити консенсус щодо патерну на кшталт const t = useTranslation('xx') + <>{t('xx.xx')}</> для перекладеного контенту.
У додатках Svelte впорскування функції як Slot, на мій погляд, є антипатерном. Це також додає зайву складність та накладні витрати на виконання JavaScript (навіть якщо це ледь помітно).