Las soluciones de internacionalización se encuentran entre las dependencias más pesadas en una aplicación Svelte. El riesgo principal es enviar contenido innecesario: traducciones para otras páginas y otros idiomas en el paquete de una sola ruta.

A medida que su aplicación crece, ese problema puede aumentar rápidamente el JavaScript enviado al cliente y ralentizar la navegación.

En la práctica, para las implementaciones menos optimizadas, una página internacionalizada puede terminar siendo varias veces más pesada que la versión sin i18n.

El otro impacto es en la experiencia del desarrollador (DX): cómo se declara el contenido, los tipos, la organización de los namespaces, la carga dinámica y la reactividad cuando cambia el idioma.

TL;DR

Intlayer: La opción más eficiente en cuanto a rendimiento (v8.7.12) con la menor huella.
Paraglide: Candidato fuerte para el tree-shaking pero tiene una experiencia de desarrollador más compleja y sobrecarga de reactividad.
svelte-i18n: Completo y estándar para Svelte, pero conlleva un peso de paquete mucho mayor (~7 veces Intlayer).

Pruebe su aplicación

Para detectar rápidamente problemas de fugas de i18n, he configurado un escáner gratuito disponible aquí.

intlayer.org

El problema

Dos palancas son esenciales para limitar el costo de una aplicación multilingüe:

Dividir el contenido por página / namespace para no cargar diccionarios completos cuando no se necesitan.
Cargar el idioma correcto dinámicamente, solo cuando sea necesario.

Comprender las limitaciones técnicas de estos enfoques:

Carga dinámica

Sin carga dinámica, la mayoría de las soluciones mantienen los mensajes en memoria desde el primer renderizado, lo que añade una sobrecarga significativa para aplicaciones con muchas rutas e idiomas.

Con la carga dinámica, se acepta un compromiso: menos JS inicial, pero a veces una solicitud adicional al cambiar de idioma.

División de contenido (Splitting)

Las sintaxis construidas en torno a t('a.b.c') son muy convenientes pero a menudo fomentan el mantenimiento de grandes objetos JSON en runtime. Ese modelo dificulta el tree-shaking a menos que la biblioteca ofrezca una estrategia real de división por página.

Metodología

Para este benchmark, comparamos las siguientes bibliotecas:

Base App (Sin biblioteca i18n)
svelte-intlayer (v8.7.12)
svelte-i18n (v4.0.1)
@inlang/paraglide-js (v2.17.0)

El framework es Svelte con una aplicación multilingüe de 10 páginas y 10 idiomas.

Comparamos quatro estrategias de carga:

Mostrar todo el contenido de la tabla

Abrir la tabla en una ventana flotante para ver todo el contenido claramente

Estrategia	Sin namespaces (global)	Con namespaces (scoped)
Carga estática	Static: Todo en memoria al inicio.	Scoped static: Dividido por namespace; todo cargado al inicio.
Carga dinámica	Dynamic: Carga bajo demanda por idioma.	Scoped dynamic: Carga granular por namespace e idioma.

Resumen de estrategias

Static: Simple; sin latencia de red después de la carga inicial. Desventaja: gran tamaño del bundle.
Dynamic: Reduce el peso inicial (lazy-loading). Ideal cuando se tienen muchos idiomas.
Scoped static: Mantiene el código organizado (separación lógica) sin solicitudes de red adicionales complejas.
Scoped dynamic: El mejor enfoque para el code splitting y el rendimiento. Minimiza la memoria cargando solo lo que la vista actual y el idioma activo necesitan.

Lo que medí:

Ejecuté la misma aplicación multilingüe en un navegador real para cada stack, luego anoté lo que realmente apareció en la red y cuánto tiempo tomó. Los tamaños se reportan después de la compresión web normal, porque eso es más cercano a lo que las personas descargan que los recuentos de código fuente sin procesar.

Tamaño de la biblioteca de internacionalización: Después del bundling, tree-shaking y minificación, el tamaño de la biblioteca i18n es el tamaño del código de providers + stores en un componente vacío. No incluye la carga de archivos de traducción. Responde qué tan costosa es la biblioteca antes de que tu contenido entre en juego.
JavaScript por página: Para cada ruta de benchmark, cuánto script descarga el navegador en esa visita, promediado en todas las páginas de la suite (y en locales donde el reporte las agrupa). Las páginas pesadas son páginas lentas.
Fuga de otros idiomas: Es el contenido de la misma página pero en otro idioma que se cargaría por error en la página auditada. Este contenido es innecesario y debe evitarse. (p. ej., contenido de la página /fr/about en el bundle de la página /en/about)
Fuga de otras rutas: La misma idea para otras pantallas en la aplicación: si su contenido se lleva cuando solo abriste una página. (p. ej., contenido de la página /en/about en el bundle de la página /en/contact). Una puntuación alta sugiere splitting débil o bundles demasiado amplios.
Tamaño promedio del bundle de componentes: Las piezas comunes de la interfaz de usuario se miden una a la vez en lugar de ocultarse dentro de un número de aplicación gigante. Muestra si la internacionalización infla silenciosamente los componentes cotidianos. Por ejemplo, si tu componente se reenderiza, cargará todos esos datos de la memoria. Adjuntar un JSON gigante a cualquier componente es como conectar un almacén grande de datos no utilizados que ralentizará el rendimiento de tus componentes.
Capacidad de respuesta del cambio de idioma: Cambio el idioma usando el control de la aplicación y mido cuánto tarda hasta que la página se haya cambiado claramente, lo que un visitante notaría, no un micro-paso de laboratorio.
Trabajo de renderizado después de un cambio de idioma: Un seguimiento más estrecho: cuánto esfuerzo tomó la interfaz para repintarse en el nuevo idioma una vez que el cambio está en vuelo. Útil cuando el tiempo "sentido" y el costo del framework divergen.
Tiempo de carga inicial de la página: Desde la navegación hasta que el navegador considere la página completamente cargada para los escenarios que probé. Bueno para comparar arranques en frío.
Tiempo de hidratación: Cuando la aplicación la expone, cuánto tiempo gasta el cliente convirtiendo HTML del servidor en algo que puedas hacer clic. Un guión en las tablas significa que esa implementación no proporcionó una cifra de hidratación confiable en este benchmark.

Estrellas de GitHub

Las estrellas de GitHub son un fuerte indicador de la popularidad de un proyecto, la confianza de la comunidad y la relevancia a largo plazo. Si bien no son una medida directa de la calidad técnica, reflejan cuántos desarrolladores encuentran útil el proyecto, siguen su progreso y es probable que lo adopten. Para estimar el valor de un proyecto, las estrellas ayudan a comparar la tracción entre alternativas y brindan información sobre el crecimiento del ecosistema.

Resultados detallados

1 - Soluciones a evitar

No hay una solución clara a evitar en el ecosistema de Svelte.

2 - Soluciones aceptables

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

Paraglide ofrece un enfoque innovador y bien pensado. En el contexto de una aplicación Vite + Svelte, el tree-shaking que su empresa publicita funcionó como se esperaba, lo cual es excelente. Pero en el caso de React + TanStack Start, el tree-shaking no funcionó como se esperaba, lo mismo para Next.js. Dicho esto, valdría la pena volver a verificar el uso de Paraglide en un proyecto Svelte y TanStack Start. El flujo de trabajo y la DX también son más complejos que en otras opciones. Personalmente, no me gusta tener que regenerar archivos JS antes de cada push, lo que genera un riesgo constante de conflictos de fusión a través de los PR. La herramienta también parece estar más centrada en Vite que en Next.js. Finalmente, en comparación con otras soluciones, Paraglide no utiliza un almacén (ej. Svelte store) para recuperar el idioma actual para renderizar el contenido. Para cada nodo analizado, solicitará el idioma al localStorage / cookie, etc. Esto conduce a la ejecución de lógica innecesaria que impacta la reactividad del componente.

Nota sobre paraglide: la solución inyecta código en su base de código para las importaciones; como resultado, la métrica 'lib size' en el informe de benchmark es casi 0. La generación de código es algo bueno, porque la función utilizada incluirá solo la lógica necesaria (prefijo en todas partes vs sin prefijo, cookie vs almacenamiento, etc.). En comparación, Intlayer realiza este filtrado mediante inyecciones de variables de entorno durante la compilación para obligar al bundler a realizar tree-shaking del contenido según la lógica. Gracias a esto, paraglide e intlayer terminan siendo soluciones de 6 a 10 veces más ligeras que i18next o next-intl.

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

Esta solución satisface todas las necesidades de i18n en un proyecto Svelte. Pero como es el caso de i18next u otras soluciones importantes, es un poco pesada (~15.9kb, aproximadamente 7 veces svelte-intlayer).

3 - Recomendaciones

(Intlayer) (svelte-intlayer@8.7.12):

No juzgaré personalmente svelte-intlayer por objetividad, ya que es mi propia solución.

Nota personal

Esta nota es personal y no afecta los resultados del benchmark. Aun así, en el mundo del i18n a menudo se ve consenso en torno a un patrón como const t = useTranslation('xx') + <>{t('xx.xx')}</> para el contenido traducido.

En las aplicaciones Svelte, inyectar una función como un Slot es, en mi opinión, un antipatrón. También añade complejidad evitable y sobrecarga de ejecución de JavaScript (aunque sea apenas perceptible).

Solid