@intlayer/docs 9.5.6 → 9.5.8

package/blog/es/i18next_vs_intlayer.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "i18next vs Intlayer: Benchmark y comparativa 2026"
 description: "react-i18next y next-i18next evaluados frente a Intlayer en Next.js y TanStack Start. Tamaño del bundle, fuga de contenido, reactividad al cambiar de idioma y experiencia de desarrollo."
 keywords:
@@ -25,6 +25,8 @@ author: aymericzip
 
 # i18next VS Intlayer | Benchmark de internacionalización (i18n) para React y Next.js
 
+![i18next VS Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18next-next-intl-intlayer.webp?raw=true)
+
 `i18next` es el framework de i18n más utilizado en el ecosistema JavaScript. A través de `react-i18next` y `next-i18next`, impulsa una gran parte de las aplicaciones React y Next.js. Intlayer es una alternativa basada en compilador con alcance por componente.
 
 Este artículo los compara mediante mediciones prácticas en lugar de listas de características. Los números provienen de [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom), una suite de código abierto que construye la misma aplicación con cada biblioteca y registra lo que el navegador realmente descarga.
@@ -99,6 +101,10 @@ Para cada build, la suite registra:
 
 ### Resultados en Next.js (`next-i18next`)
 
+Selecciona las métricas y las bibliotecas que te interesen:
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | Biblioteca                        | Estrategia     | Lib size (gz) | Page JS avg (gz) | Locale leak | Page leak | Component avg (gz) | Reactividad E2E | Hidratación |
 | --------------------------------- | -------------- | ------------: | ---------------: | ----------: | --------: | -----------------: | --------------: | ----------: |
 | **base** (sin i18n)               | -              |        0.0 KB |         141.0 KB |        0.0% |      0.0% |             0.9 KB |         13.4 ms |     11.8 ms |
@@ -119,6 +125,15 @@ Para cada build, la suite registra:
 - **Tamaño de componentes.** Un componente que invoca `useTranslation()` compila entre 26 y 79 KB según la configuración; el mismo componente con `useIntlayer()` compila en solo 6.9 KB.
 - **La hidratación** sube a 27.7 ms en la configuración `dynamic`: la instancia de i18next se inicializa y resuelve su backend en el cliente antes de que React pueda hidratar el DOM.
 
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-nextjs.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> Tabla completa, cada biblioteca y cada estrategia, en el [informe de benchmark de Next.js](https://intlayer.org/es/doc/benchmark/nextjs).
+
 ### Resultados en TanStack Start (`react-i18next`)
 
 La misma aplicación de prueba en TanStack Start con `react-i18next` puro, eliminando las particularidades de Next.js.
@@ -141,8 +156,19 @@ La misma aplicación de prueba en TanStack Start con `react-i18next` puro, elimi
 - La fila `static` de Intlayer ya cuenta con **0% de fuga de página** porque solo se empaquetan los diccionarios importados por los componentes de esa página. Activar `importMode: 'dynamic'` elimina además la fuga de idiomas.
 - **Tamaño por componente**: 24-27 KB con `react-i18next` frente a 6-8 KB con Intlayer. `useTranslation()` vincula cada componente a la instancia global de i18next.
 
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-tanstack.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> Tabla completa en el [informe de benchmark de TanStack Start](https://intlayer.org/es/doc/benchmark/tanstack).
+
 ## ¿Por qué esta diferencia? Instancia global vs. diccionarios compilados
 
+![Centralized catalogs versus per-component dictionaries](https://github.com/aymericzip/intlayer/blob/main/docs/assets/project_stucture_18n_vs_intlayer.png?raw=true)
+
 `i18next` fue diseñado en 2012 como un runtime: una instancia global almacena un almacén de recursos, los plugins la amplían y `t()` busca claves en tiempo de render. Esto le otorga una gran versatilidad (cualquier framework, backend o formato), pero también la hace pesada:
 
 ```bash
@@ -166,7 +192,13 @@ La misma aplicación de prueba en TanStack Start con `react-i18next` puro, elimi
                 └── page.tsx     # debe saber que necesita ["common", "about"]
 ```
 
-La instancia no puede saber qué claves necesitará un componente, por lo que retiene todos los namespaces cargados. Optimizar exige que **tú** dividas los catálogos en namespaces, que **tú** listes los namespaces que requiere cada página y que **tú** mantengas esa lista actualizada cuando los componentes cambian de ubicación. Como señalan las [notas del benchmark](https://github.com/intlayer-org/benchmark-bloom/blob/main/report/NOTE.md): "mantener la seguridad de tipos y saber con exactitud qué namespace incluir en cada página es una pesadilla".
+La instancia no puede saber qué claves necesitará un componente, por lo que retiene todos los namespaces cargados. Optimizar exige que **tú** dividas los catálogos en namespaces, que **tú** listes los namespaces que requiere cada página y que **tú** mantengas esa lista actualizada cuando los componentes cambian de ubicación.
+
+La factura crece en dos ejes a la vez, páginas e idiomas:
+
+![Theoretical content leakage by architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
+
+Como señalan las [notas del benchmark](https://github.com/intlayer-org/benchmark-bloom/blob/main/report/NOTE.md): "mantener la seguridad de tipos y saber con exactitud qué namespace incluir en cada página es una pesadilla".
 
 Intlayer elimina la instancia global. El contenido se define junto al componente y el compilador resuelve el árbol de dependencias en tiempo de compilación:
 
@@ -193,7 +225,8 @@ Intlayer elimina la instancia global. El contenido se define junto al componente
 
 ### Configuración
 
-**next-i18next (App Router)**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-i18next" value="i18next">
 
 ```ts fileName="src/app/i18n/server.ts"
 import { createInstance } from "i18next";
@@ -228,7 +261,8 @@ export const initI18next = async (
 
 Más un `I18nProvider` del lado del cliente que replica la instancia con idénticas opciones, `generateStaticParams` y una lista de `namespaces` por página.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="intlayer.config.ts"
 import { type IntlayerConfig, Locales } from "intlayer";
@@ -264,9 +298,13 @@ const LocaleLayout: NextLayoutIntlayer = async ({ children, params }) => {
 export default LocaleLayout;
 ```
 
+</Tab>
+</Tabs>
+
 ### Componente de cliente
 
-**react-i18next**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="react-i18next" value="i18next">
 
 ```json fileName="src/locales/en/about.json"
 {
@@ -304,7 +342,8 @@ export const Counter = () => {
 
 > La página que renderiza este componente debe cargar el namespace `about`, y `t("counter.label")` es un string genérico a menos que extiendas `CustomTypeOptions`.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="src/components/Counter/index.content.ts"
 import { t, type Dictionary } from "intlayer";
@@ -345,9 +384,13 @@ export const Counter = () => {
 
 `label` e `increment` están tipados de forma estricta; cualquier errata genera un error en TypeScript y un texto faltante en francés produce un fallo en el build.
 
+</Tab>
+</Tabs>
+
 ### Componente de servidor síncrono
 
-**next-i18next**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-i18next" value="i18next">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 type ServerCounterProps = {
@@ -366,7 +409,8 @@ export const ServerCounter = ({ t, locale, count }: ServerCounterProps) => (
 
 La página invoca `i18n.getFixedT(locale, "about")` y pasa `t` y `locale` hacia abajo vía props.
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 import { useIntlayer } from "next-intlayer/server";
@@ -385,6 +429,9 @@ export const ServerCounter = ({ count }: { count: number }) => {
 };
 ```
 
+</Tab>
+</Tabs>
+
 ## Conserva la API de i18next, obtén las ventajas de Intlayer
 
 No es necesario reescribir tus componentes para beneficiarte de las cifras del benchmark. `@intlayer/i18next`, `@intlayer/react-i18next` y `@intlayer/next-i18next` son adaptadores compatibles: `useTranslation`, `t()`, `<Trans>`, `{{interpolation}}`, plurales `_one` / `_other`, sufijos de contexto y `returnObjects` continúan funcionando, servidos desde los diccionarios generados por el compilador de Intlayer.
@@ -415,18 +462,85 @@ Consulta las guías de migración: [i18next](https://intlayer.org/es/doc/migrati
 
 ## ¿Cuándo elegir cada una?
 
-- **Elige i18next** si necesitas su ecosistema de plugins (detectores, backends, ICU, Locize), si traduces fuera de React (servicios Node, JavaScript vanilla u otros frameworks), si tu equipo ya lo domina o si tu plataforma de traducción requiere `locales/{lng}/{ns}.json`. Reserva tiempo para separar catálogos en namespaces, configurar un backend y mantener el mapa rutas-namespaces si el rendimiento es prioritario.
-- **Elige Intlayer** si buscas **contenido con alcance por componente**, **TypeScript estricto**, **detección de claves faltantes en tiempo de compilación**, **tree-shaking y lazy loading automáticos**, cambio instantáneo de idioma, componentes de servidor síncronos y herramientas editoriales nativas (Editor Visual, CMS, traducción con IA, servidor MCP). Ideal para aplicaciones modulares y sistemas de diseño.
-- **Elige los adaptadores `@intlayer/*-i18next`** si ya utilizas i18next y deseas obtener las mejoras de bundle y reactividad sin reescribir tus componentes.
+<AccordionGroup>
+<Accordion header="Elegir i18next">
+
+Si necesitas su ecosistema de plugins (detectores, backends, ICU, Locize), si traduces fuera de React (servicios Node, JavaScript vanilla u otros frameworks), si tu equipo ya lo domina o si tu plataforma de traducción requiere `locales/{lng}/{ns}.json`. Reserva tiempo para separar catálogos en namespaces, configurar un backend y mantener el mapa rutas-namespaces si el rendimiento es prioritario.
+
+</Accordion>
+<Accordion header="Elegir Intlayer">
+
+Quieres **contenido delimitado por componentes**, **TypeScript estricto**, **errores en tiempo de compilación por claves faltantes**, **tree-shaking y lazy loading sin esfuerzo**, cambio instantáneo de idioma, componentes de servidor síncronos y herramientas editoriales integradas ([Editor Visual](https://intlayer.org/es/doc/concept/editor), [CMS](https://intlayer.org/es/doc/concept/cms), [traducción con IA](https://intlayer.org/es/doc/concept/auto-fill), [servidor MCP](https://intlayer.org/es/doc/mcp-server)). Especialmente relevante para bases de código modulares y sistemas de diseño.
+
+</Accordion>
+<Accordion header="Elegir los adaptadores @intlayer/*-i18next">
+
+Ya usas i18next y quieres las ventajas de bundle y reactividad sin reescribir tus componentes. Tus archivos `locales/{lng}/{ns}.json` siguen siendo la fuente de la verdad. Medido cara a cara en [i18next vs @intlayer/i18next](https://intlayer.org/es/blog/i18next-vs-intlayer-i18next).
+
+</Accordion>
+</AccordionGroup>
+
+## Preguntas frecuentes
+
+<FAQ>
+
+<Question title="¿Por qué i18next es mucho más pesado que otras bibliotecas?">
+
+Fue diseñado como un runtime independiente del framework: una instancia global, una canalización de plugins, un almacén de recursos, un resolutor de claves. Esa flexibilidad se compila en cada bundle. Un componente vacío que solo importa la biblioteca cuesta **19.7 KB gzip** con `next-i18next` frente a **5.5 KB** con `next-intlayer`, y ese coste se paga en cada página sin importar el peso de tu contenido.
+
+</Question>
+
+<Question title="¿Cargar de forma diferida con un backend lo soluciona?">
+
+Soluciona los bytes, no la latencia. Pasar a `i18next-resources-to-backend` ahorra ~49 KB por página pero añade un viaje de ida y vuelta de red al cambiar de idioma: **123 ms** en la configuración `dynamic` y **185 ms** en `scoped-static`, frente a **3-4 ms** con Intlayer. La hidratación también sube a 27.7 ms porque la instancia resuelve su backend antes de que React pueda hidratar.
+
+</Question>
+
+<Question title="¿Puedo lograr 0% de fuga con i18next?">
+
+Sí, con `scoped-dynamic`: un espacio de nombres por ruta, un backend de recursos y un mapa de página a espacio de nombres mantenido a mano. Da como resultado 163.4 KB por página en Next.js, todavía **+22 KB** sobre los 141.3 KB de Intlayer, que no necesitó configuración. Consulta la [optimización del bundle](https://intlayer.org/es/doc/concept/bundle-optimization).
+
+</Question>
+
+<Question title="¿Tengo que reescribir mis componentes para migrar?">
+
+No. `@intlayer/i18next`, `@intlayer/react-i18next` y `@intlayer/next-i18next` mantienen `useTranslation`, `t()`, `<Trans>`, `{{interpolation}}`, plurales `_one` / `_other`, sufijos de contexto y `returnObjects`. Una sola línea de plugin en `next.config.ts` o `vite.config.ts`. Paso a paso en la [guía de migración de next-i18next](https://intlayer.org/es/doc/migration/next-i18next).
+
+</Question>
+
+<Question title="¿Qué ocurre con mis plugins de i18next?">
+
+Los backends y detectores de idioma se aceptan pero quedan inertes: no queda nada por cargar ni detectar en tiempo de ejecución. La detección de idioma pasa a ser la configuración de enrutamiento de Intlayer (prefijo de URL, cookie, cabecera). Si tu aplicación obtiene traducciones de un CMS en el momento de la solicitud, usa el [CMS de Intlayer](https://intlayer.org/es/doc/concept/cms) o `intlayer pull` / `push` en su lugar.
+
+</Question>
+
+</FAQ>
 
 ## Comparativas relacionadas
 
-- [next-intl vs Intlayer](https://intlayer.org/es/blog/next-intl-vs-intlayer) (mismo benchmark)
-- [Lingui vs Intlayer](https://intlayer.org/es/blog/lingui-vs-intlayer) (mismo benchmark)
-- [vue-i18n vs Intlayer benchmark](https://intlayer.org/es/blog/vue-i18n-vs-intlayer-benchmark) (mismo benchmark)
+Mismo benchmark, otras bibliotecas:
+
+- [next-intl vs Intlayer](https://intlayer.org/es/blog/next-intl-vs-intlayer)
+- [Lingui vs Intlayer](https://intlayer.org/es/blog/lingui-vs-intlayer)
+- [vue-i18n vs Intlayer benchmark](https://intlayer.org/es/blog/vue-i18n-vs-intlayer-benchmark)
 - [next-i18next vs next-intl vs Intlayer](https://intlayer.org/es/blog/next-i18next-vs-next-intl-vs-intlayer)
 - [react-i18next vs react-intl vs Intlayer](https://intlayer.org/es/blog/react-i18next-vs-react-intl-vs-intlayer)
+
+Más allá sobre i18next:
+
+- [i18next vs @intlayer/i18next](https://intlayer.org/es/blog/i18next-vs-intlayer-i18next), los adaptadores medidos en la misma aplicación
 - [¿Está desactualizado i18next?](https://intlayer.org/es/blog/is-i18next-outdated)
+- [Usar Intlayer con i18next](https://intlayer.org/es/blog/intlayer-with-i18next) y [con react-i18next](https://intlayer.org/es/blog/intlayer-with-react-i18next)
+- [Cómo internacionalizar una aplicación Next.js con next-i18next](https://intlayer.org/es/blog/nextjs-internationalization-using-next-i18next)
+
+Documentación de referencia:
+
+- [Informe de benchmark de Next.js](https://intlayer.org/es/doc/benchmark/nextjs) e [informe de benchmark de TanStack Start](https://intlayer.org/es/doc/benchmark/tanstack)
+- Adaptadores de compatibilidad: [i18next](https://intlayer.org/es/doc/compatibility/i18next), [react-i18next](https://intlayer.org/es/doc/compatibility/react-i18next), [next-i18next](https://intlayer.org/es/doc/compatibility/next-i18next)
+- Guías de migración: [i18next](https://intlayer.org/es/doc/migration/i18next), [react-i18next](https://intlayer.org/es/doc/migration/react-i18next), [next-i18next](https://intlayer.org/es/doc/migration/next-i18next)
+- [Optimización del bundle](https://intlayer.org/es/doc/concept/bundle-optimization) y [el compilador Intlayer](https://intlayer.org/es/doc/compiler)
+- [i18n por componente vs centralizada](https://intlayer.org/es/blog/per-component-vs-centralized-i18n)
+- [i18n basada en compilador vs declarativa](https://intlayer.org/es/blog/compiler-vs-declarative-i18n)
 
 ## Estrellas en GitHub
 

package/blog/es/is_intlayer_lighter_than_paraglide.md

@@ -0,0 +1,284 @@
+---
+createdAt: 2026-09-23
+updatedAt: 2026-09-23
+title: ¿Es Intlayer más ligero que Paraglide?
+description: Paraglide parece casi gratuito en los benchmarks de i18n porque su código se genera en tu repositorio. Aquí te mostramos a dónde va realmente ese peso, por qué la resolución de locale por nodo tiene un coste y cómo la carga dinámica de Intlayer envía un solo idioma en lugar de todos.
+keywords:
+  - Paraglide
+  - Intlayer
+  - Internacionalización
+  - i18n
+  - Bundle size
+  - Tree shaking
+  - Benchmark
+  - Blog
+slugs:
+  - blog
+  - is-intlayer-lighter-than-paraglide
+author: aymericzip
+---
+
+# ¿Es Intlayer más ligero que Paraglide?
+
+Sí.
+
+`Paraglide` tiene una sólida reputación por ser la solución de i18n más ligera del mercado, y a primera vista el [benchmark](https://intlayer.org/es/doc/benchmark/tanstack) coincide: el tamaño de su biblioteca es cercano a cero. Pero un tamaño de biblioteca de cero no significa que se envíen cero bytes. Significa que los bytes residen en un lugar donde la métrica no mira.
+
+<TOC/>
+
+## Puntos clave
+
+**El tamaño de la biblioteca está oculto, no eliminado:**
+
+Paraglide genera su runtime y funciones de mensajes dentro de tu codebase. Ese código se envía al navegador, pero se contabiliza como _tu_ código, no como el de la biblioteca.
+
+**Prescindir de un provider no es una ganancia gratuita:**
+
+Cada llamada a `m.my_key()` resuelve el locale por su cuenta, leyendo la cookie o el storage en cada nodo renderizado, en lugar de leerlo una sola vez desde un contexto.
+
+**Sin carga dinámica:**
+
+Paraglide importa todos los idiomas de un mensaje dentro del bundle de tu cliente. Intlayer con `importMode: 'dynamic'` o `'fetch'` carga únicamente el idioma que se está renderizando.
+
+**El tree shaking no está garantizado:**
+
+En algunos de nuestros benchmarks, el tree shaking anunciado por Paraglide no surtió efecto. Comprueba tu propio bundle.
+
+## ¿A dónde va el peso de Paraglide?
+
+En los informes de benchmark, la métrica "tamaño de la biblioteca" mide el provider y los hooks de cada biblioteca de i18n en un componente vacío, antes de agregar cualquier contenido.
+
+| Biblioteca (TanStack Start)   | Tamaño lib (gz) | Tamaño lib (min) |
+| ----------------------------- | --------------- | ---------------- |
+| `@inlang/paraglide-js@2.15.1` | 1.8 KB          | 4.5 KB           |
+| `react-intlayer@9.5.1`        | 5.0 KB          | 15.2 KB          |
+
+Visto de forma aislada, Paraglide gana. Pero Paraglide es un compilador: lee tus archivos `messages/*.json` y escribe una carpeta `paraglide/` en tu repositorio, la cual contiene un archivo `runtime.js` (detección de locale, estrategias de cookies y storage, localización de URLs) y una función de JavaScript por cada mensaje.
+
+```bash
+src/paraglide/
+├── runtime.js      # detección de locale, estrategias, helpers de URL
+├── server.js
+├── messages.js     # reexporta cada mensaje
+└── messages/
+    ├── _index.js
+    ├── en.js
+    └── fr.js
+```
+
+Debido a que este código se encuentra en tu carpeta `src/` y lo importas mediante una ruta relativa, el bundler lo atribuye a tu aplicación y no a un paquete en `node_modules`. La columna del tamaño de la biblioteca muestra casi nada, mientras que la misma lógica se sigue enviando en el bundle de tu página.
+
+Generar código no es una mala idea en sí misma: el runtime generado solo incluye la lógica que tu configuración necesita (estrategia de prefijo, cookie frente a local storage, etc.). Intlayer alcanza el mismo resultado de forma diferente, inyectando variables de entorno en tiempo de compilación para que el bundler elimine las ramas que tu configuración no utiliza. Ambos enfoques terminan siendo de 3 a 10 veces más ligeros que `i18next` o `next-intl`.
+
+Por lo tanto, la comparación justa no es el tamaño de la biblioteca. Es **el JavaScript que realmente se envía por página**.
+
+## Peso por página, medido
+
+Aplicación TanStack Start, 10 páginas, medido en las rutas `en` y `fr`, comprimido con gzip:
+
+| Configuración                      | JS pág prom (gz) | Sobre la base | Fuga de locale | Fuga de otras páginas |
+| ---------------------------------- | ---------------- | ------------- | -------------- | --------------------- |
+| Base (sin i18n)                    | 111.0 KB         | -             | 0.0%           | 0.0%                  |
+| `paraglide` (cualquier estrategia) | 125.1 KB         | +14.1 KB      | 49.7%          | 0.0%                  |
+| `intlayer` (`importMode: static`)  | 125.8 KB         | +14.8 KB      | 50.0%          | 0.0%                  |
+| `intlayer` (`importMode: dynamic`) | **118.6 KB**     | **+7.6 KB**   | **0.0%**       | **0.0%**              |
+
+Next.js 16 App Router, misma aplicación:
+
+| Configuración    | JS pág prom (gz) | Sobre la base |
+| ---------------- | ---------------- | ------------- |
+| Base (sin i18n)  | 141.0 KB         | -             |
+| `paraglide-next` | 155.3 KB         | +14.3 KB      |
+| `next-intlayer`  | **141.3 KB**     | **+0.3 KB**   |
+
+<I18nBenchmark framework="tanstack" vertical/>
+
+> Datos completos en el [informe de benchmark de TanStack Start](https://intlayer.org/es/doc/benchmark/tanstack) y en el [informe de benchmark de Next.js](https://intlayer.org/es/doc/benchmark/nextjs). Cada bundle se puede inspeccionar en el [repositorio del benchmark](https://github.com/intlayer-org/benchmark-i18n).
+
+Dos conclusiones destacan con claridad:
+
+- En modo `static`, Intlayer envía prácticamente el mismo contenido que Paraglide (125.8 KB frente a 125.1 KB). Esto es lo esperado: ambos incluyen todos los idiomas de los mensajes que utiliza una página.
+- Paraglide permanece en 125.1 KB independientemente de la estrategia, porque carece de un modo dinámico. Cada línea en la tabla anterior equivale a la opción estática.
+
+## Sin Provider: una buena idea que no lo es
+
+Paraglide no requiere provider. Importas un mensaje y lo ejecutas:
+
+```tsx fileName="Hero.tsx"
+import { m } from "../paraglide/messages.js";
+
+export const Hero = () => (
+  <section>
+    <h1>{m.hero_title()}</h1>
+    <p>{m.hero_description()}</p>
+    <button>{m.hero_cta()}</button>
+  </section>
+);
+```
+
+Sin contexto, sin wrapper, sin hook. Parece más sencillo. Sin embargo, el locale tiene que provenir de algún lugar. Cada función de mensaje generada se parece a esto (simplificado):
+
+```js fileName="paraglide/messages/_index.js"
+export const hero_title = (inputs = {}, options = {}) => {
+  const locale = options.locale ?? getLocale(); // se resuelve en cada llamada
+
+  if (locale === "en") return en.hero_title(inputs);
+  if (locale === "fr") return fr.hero_title(inputs);
+  // ...una rama por idioma
+};
+```
+
+Y `getLocale()` recorre las estrategias configuradas (cookie, local storage, URL, locale base) para determinar el locale activo. De modo que cada nodo de texto que renderizas (`<>{m.my_key()}</>`) ejecuta su propia resolución de locale, lo que incluye leer `document.cookie` en el navegador. Una página con 200 cadenas traducidas resuelve el locale 200 veces por renderizado, y nuevamente en cada re-renderizado.
+
+Una biblioteca basada en un provider lee el locale **una sola vez**, lo almacena en un contexto (o en una señal, o en un store), y cada nodo lee un valor que ya está en memoria. El provider cuesta unos pocos cientos de bytes. Omitirlo cuesta ciclos de CPU en cada renderizado, lo cual se refleja en el benchmark: los tiempos de carga de página y de cambio de idioma de Paraglide quedan sistemáticamente por detrás de Intlayer en TanStack Start (22.1 ms frente a 14.6 ms en carga de página, 4.3 ms frente a 3.2 ms en reactividad E2E).
+
+## Experiencia de desarrollo
+
+La fuente de verdad de Paraglide es JSON, pero nunca importas el JSON directamente. Importas el archivo `.js` generado:
+
+<Tabs defaultTab="intlayer" group="techno">
+  <Tab label="Paraglide" value="paraglide">
+
+```json fileName="messages/en.json"
+{
+  "hero_title": "Ship your app in every language"
+}
+```
+
+```json fileName="messages/es.json"
+{
+  "hero_title": "Publica tu app en todos los idiomas"
+}
+```
+
+```tsx fileName="Hero.tsx"
+// Solo existe después de que el compilador lo regenere desde el JSON
+import { m } from "../paraglide/messages.js";
+
+export const Hero = () => <h1>{m.hero_title()}</h1>;
+```
+
+  </Tab>
+  <Tab label="Intlayer" value="intlayer">
+
+```ts fileName="Hero.content.ts"
+import { t, type Dictionary } from "intlayer";
+
+export default {
+  key: "hero",
+  content: {
+    title: t({
+      es: "Publica tu app en todos los idiomas",
+      en: "Ship your app in every language",
+    }),
+  },
+} satisfies Dictionary;
+```
+
+```tsx fileName="Hero.tsx"
+import { useIntlayer } from "react-intlayer";
+
+export const Hero = () => {
+  const { title } = useIntlayer("hero");
+
+  return <h1>{title}</h1>;
+};
+```
+
+  </Tab>
+</Tabs>
+
+Ese ciclo de trabajo tiene un coste:
+
+- Cada cambio en un archivo JSON requiere una regeneración antes de que la importación se resuelva o los tipos se actualicen.
+- La carpeta generada `paraglide/` o bien se incluye en el control de versiones, lo que genera conflictos de merge en archivos generados en cada PR que toque textos, o bien se ignora en git, lo que exige un paso de generación previo a cada verificación de tipos, test y tarea de CI.
+- Cada cadena de texto se convierte en una llamada a función. Las constantes pasan a ser `m.key()` por todas partes, incluso donde un valor plano sería suficiente.
+
+## Tree Shaking: revisa tu bundle
+
+La principal promesa de Paraglide es que los mensajes no utilizados se eliminan mediante tree shaking, dado que cada mensaje representa una exportación independiente. En el benchmark de Svelte + Vite, funciona tal como se describe.
+
+En otros entornos, no fue así. En nuestras pruebas con [Next.js](https://intlayer.org/es/doc/benchmark/nextjs), las páginas de Paraglide pesan 14 KB más que la aplicación base, mientras que `next-intlayer` solo añade 0.3 KB. Pruebas anteriores en TanStack Start demostraron que mensajes de otras páginas también terminaban incorporándose en el bundle de la ruta.
+
+El tree shaking depende de tu bundler (Turbopack, Rolldown, Rollup), de la forma en que se importan los mensajes (`import { m }` frente a `import * as m`) y del análisis de efectos secundarios. Si eliges Paraglide por su tamaño, abre tu visualizador de bundle y comprueba que se cumpla en tu aplicación.
+
+## Sin carga dinámica
+
+Este es el límite estructural. Paraglide no dispone de un mecanismo para cargar un solo idioma a la vez: cada función de mensaje importa de manera estática la implementación de cada idioma, por lo que todos los idiomas acaban en el bundle de tu cliente.
+
+Con 2 idiomas, se desperdicia la mitad de los datos de traducción, lo cual coincide con el ~50% de fuga de locale medido anteriormente. Con 10 idiomas, el 90%. Con 30 idiomas, el 97%.
+
+Pasar a una carga dinámica tampoco solucionaría el problema: al tener una función por mensaje, cargar cada función de forma diferida implicaría miles de peticiones individuales.
+
+Intlayer te permite elegir la estrategia, ya sea de forma global o por diccionario:
+
+```ts fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH, Locales.SPANISH],
+    defaultLocale: Locales.ENGLISH,
+  },
+  dictionary: {
+    importMode: "dynamic", // 'static' | 'dynamic' | 'fetch'
+  },
+};
+
+export default config;
+```
+
+| `importMode` | Qué se envía al cliente                                     | vs. Paraglide                        |
+| ------------ | ----------------------------------------------------------- | ------------------------------------ |
+| `static`     | Todos los idiomas de los diccionarios que usa la página     | Teóricamente el mismo contenido      |
+| `dynamic`    | Solo el idioma actual, cargado bajo demanda por diccionario | **N veces más ligero** con N idiomas |
+| `fetch`      | Solo el idioma actual, obtenido desde la Live Sync API      | **N veces más ligero** con N idiomas |
+
+Mediante la [transformación en compilación](https://intlayer.org/es/doc/concept/bundle-optimization) y el modo `importMode: 'static'`, Intlayer carga, en teoría, exactamente el mismo contenido que Paraglide. Con `'dynamic'` o `'fetch'`, carga únicamente lo que requiere el idioma actual: para una aplicación en N idiomas, la carga de traducción es N veces menor que la de Paraglide.
+
+## Dónde sigue encajando Paraglide
+
+<AccordionGroup>
+<Accordion header="Svelte + Vite con pocos idiomas">
+
+Si tu stack es Svelte con Vite y manejas dos o tres idiomas, el tree shaking funciona como se anuncia y la sobrecarga de idiomas se mantiene baja.
+
+</Accordion>
+<Accordion header="Flujo de trabajo existente con inlang">
+
+Si tu equipo ya utiliza el ecosistema inlang (Fink, Sherlock, plugins de formato de mensajes), Paraglide se integra con él de forma nativa.
+
+</Accordion>
+</AccordionGroup>
+
+## Pruébalo en tu aplicación
+
+Comprueba el tamaño y las fugas de locale de tu aplicación en producción con el [i18n SEO Scanner](https://intlayer.org/i18n-seo-scanner) gratuito:
+
+<ClickToOpenIframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+Para configurar Intlayer:
+
+```bash packageManager="npm"
+npx intlayer init --interactive
+```
+
+```bash packageManager="pnpm"
+pnpm dlx intlayer init --interactive
+```
+
+```bash packageManager="yarn"
+yarn dlx intlayer init --interactive
+```
+
+```bash packageManager="bun"
+bunx intlayer init --interactive
+```
+
+## Lecturas complementarias
+
+- [Benchmark de i18n en TanStack Start](https://intlayer.org/es/doc/benchmark/tanstack)
+- [Benchmark de i18n en Next.js](https://intlayer.org/es/doc/benchmark/nextjs)
+- [Optimización de bundles e `importMode`](https://intlayer.org/es/doc/concept/bundle-optimization)
+- [Cómo elegir una biblioteca de i18n para React](https://intlayer.org/es/blog/how-to-pick-react-i18n-library)
+- [Los argumentos a favor y en contra de la i18n basada en compiladores](https://intlayer.org/es/blog/compiler-vs-declarative-i18n)