Lingui VS Intlayer: Benchmark de Internacionalização (i18n) para React e Next.js

Lingui e Intlayer são as duas bibliotecas deste benchmark que utilizam um compilador em vez de operarem estritamente como um runtime. O Lingui extrai mensagens a partir de macros durante o build e compila catálogos por idioma. O Intlayer compila dicionários por componente e aplica tree-shaking por idioma. Na teoria, deveriam ser muito parecidos. Os números revelam onde eles se distanciam.

Os dados são provenientes do Benchmark Bloom, uma suíte de código aberto que constrói a mesma aplicação com cada biblioteca e afere o que o navegador efetivamente baixa e executa.

tl;dr: O Lingui é a biblioteca mais próxima do Intlayer em volume bruto de JavaScript por página: 115-120 KB contra 118,6 KB no TanStack Start após a configuração de lazy loading, e 148,6 KB contra 141,3 KB no Next.js. A diferença real surge nos demais indicadores: um componente do Lingui compilado isoladamente pesa 58-153 KB contra 6-8 KB no Intlayer, a hidratação leva 28-34 ms contra 11-14 ms, o fallback do idioma original vaza entre 3% e 15% de textos em inglês nas páginas em francês em qualquer configuração otimizada, e atingir essa otimização requer extrair, compilar e selecionar catálogos manualmente por rota. O Intlayer alcança esses números sem qualquer configuração complexa.

Em resumo

• Lingui - Baseado em macros ( t`...` , <Trans>, msg), formato ICU MessageFormat, catálogos em .po / JSON, fluxo de trabalho lingui extract + lingui compile. Compila IDs de mensagem em hashes compactos, suporta carregamento dinâmico de catálogos por idioma. Consolidado, agnóstico de framework e com excelente ecossistema de ferramentas de tradução em torno do formato .po.
• Intlayer - Modelo de conteúdo orientado a componentes. Dicionários .content.ts residem ao lado do componente ao qual atendem; um compilador de build realiza tree-shaking e carregamento sob demanda por componente e por idioma; tipos TypeScript rigorosos são gerados automaticamente a partir do conteúdo, e traduções ausentes geram erro de compilação. Inclui middleware, utilitários de SEO, um Editor Visual / CMS e tradução assistida por IA.

Mostrar todo o conteúdo da tabela

Mostrar todo o conteúdo da tabela

Abrir a tabela em um modal para ver todo o conteúdo claramente

Biblioteca	Estrelas no GitHub	Commits Totais	Último Commit	Primeira Versão	Versão NPM	Downloads no NPM
aymericzip/intlayer				Abril 2024
lingui/js-lingui				Dezembro 2016

Os badges são atualizados de forma automática. Instantâneos podem mudar ao longo do tempo.

Comparação funcional lado a lado

O benchmark

O que foi medido

A suíte Benchmark Bloom compila a mesma aplicação com cada biblioteca: 10 páginas (home, about, blog, careers, contact, FAQ, pricing, products, settings, team), 10 idiomas (en, fr, es, de, it, pt, zh, ja, ko, ru), componentes idênticos e conteúdo idêntico. As páginas são avaliadas em en e fr. Cada biblioteca foi avaliada em até quatro estratégias de carregamento:

O Intlayer não tem variante "scoped" isolada: o compilador delimita o escopo de conteúdo por componente automaticamente, logo suas linhas static e dynamic já nascem perfeitamente segmentadas.

Para cada compilação, registram-se:

• Lib size: tamanho gzip de um componente vazio que importa unicamente a biblioteca de i18n (o custo fixo do runtime).
• Page JS: média de JavaScript gzip baixado por página, calculada sobre todas as páginas e idiomas.
• Locale leak %: proporção de strings traduzidas no JS baixado pertencentes a idiomas que o usuário não está visualizando.
• Page leak %: proporção de strings traduzidas no JS baixado pertencentes a páginas onde o usuário não está navegando.
• Component avg: tamanho gzip médio de cada componente compilado de forma isolada.
• E2E reactivity: intervalo de tempo real entre selecionar um novo idioma e o DOM atualizar a tag html[lang] (Playwright, 5 iterações).
• Hydration: duração da fase de hidratação do React.

Os dados abaixo referem-se ao teste de 2026-09-12 com @lingui/react 6.6.0 e intlayer 9.5.1. A aplicação de testes é enxuta por design (poucas dezenas de strings por idioma), portanto os índices de vazamento expressam um padrão estrutural que se amplifica com o volume de dados.

Resultados no Next.js

Escolha as métricas e bibliotecas do seu interesse:

Análise dos números

• Custo do runtime. Um componente vazio pesa 11,9 KB gzip no Lingui contra 5,5 KB no Intlayer. Na página completa, o melhor arranjo do Lingui fica em +7,3 KB em relação ao Intlayer (148,6 contra 141,3 KB); o Intlayer situa-se em modestos +0,3 KB acima da aplicação base sem i18n.
• A abordagem ingênua tem custo elevado. Carregar todos os catálogos compilados no início resulta em 207,4 KB por página, +66 KB sobre o app base. Metade das strings pertence ao idioma errado e 90% a páginas não visualizadas.
• Carregamento dinâmico ajusta o idioma, mas não a página. Com um catálogo por idioma, o vazamento de página permanece em ~90%: o catálogo completo de francês é entregue em cada página em francês. Para alcançar 0% de vazamento de página no Lingui é necessário recorrer a scoped-dynamic: um catálogo por rota, extraído e compilado individualmente, importado manualmente em cada página.
• O fallback do idioma de origem vaza por construção. Mesmo nas configurações mais bem planejadas, entre 3% e 15% das strings em inglês são enviadas nas páginas em francês. As macros do Lingui guardam o texto fonte como salvaguarda, de modo que ele aterrissa no bundle. O Intlayer resolve fallbacks no build e entrega exclusivamente o idioma ativo.
• O tamanho dos componentes isolados dispara em scoped-dynamic. Cada componente compilado isoladamente projeta uma média de 152,6 KB, pois os catálogos das rotas permanecem alcançáveis pelos imports. O mesmo componente usando useIntlayer() registra uma média de 6,9 KB.

Tabela completa, cada biblioteca e cada estratégia, no relatório de benchmark do Next.js.

Resultados no TanStack Start

Análise dos números

• No volume de JavaScript por página, o Lingui vence por margem mínima. O Lingui em modo dynamic atinge 115,2 KB, apenas 3,4 KB abaixo dos 118,6 KB do Intlayer. Seus catálogos compilados com hashes são extremamente densos, e o roteador do TanStack Start particiona as rotas tão bem que o vazamento de página é nulo logo na linha dynamic.
• Todos os outros índices favorecem o Intlayer. A hidratação toma 28-34 ms no Lingui contra 11-14 ms no Intlayer: i18n.load() + i18n.activate() rodam no cliente antes que o React possa hidratar. Os componentes isolados pesam 58-148 KB em vez de 6-8 KB. O vazamento de idioma nunca zera (fica entre 4% e 9%) por causa do fallback inglês.
• A troca de idioma fica sensivelmente lenta no modo otimizado. O Lingui em scoped-dynamic demanda 42 ms para refletir a nova língua no html[lang], já que o novo catálogo precisa ser baixado, inserido e ativado antes da renderização visual. O Intlayer alterna em 3-4 ms em qualquer modo.
• A linha static do Intlayer já apresenta 0% de vazamento de página, pois inclui unicamente os dicionários consumidos pelos componentes daquela tela. Uma única linha de configuração (importMode: 'dynamic') extingue igualmente o vazamento de idioma.
• @intlayer/lingui mantém a sintaxe das macros do Lingui consumindo dicionários do Intlayer. Ele cede um pouco no tamanho final da página (137 KB, devido à presença do runtime de macros) em troca de componentes muito mais leves (12,8 KB) e hidratação mais ágil. Uma excelente rota de transição.

Tabela completa no relatório de benchmark do TanStack Start.

Qual é a origem desse contraste? Dois compiladores, duas unidades de trabalho

Ambas as soluções utilizam um compilador. O divisor de águas é o que elas compilam.

O Lingui compila catálogos. As macros espalhadas pelo seu código são recolhidas em um arquivo .po por idioma e compiladas em um módulo JS por idioma. A unidade central é o idioma. Dividir além disso, por rota ou por componente, pressupõe criar catálogos adicionais, configurar o lingui.config.ts para extrair cada pedaço separadamente e administrar o carregamento manualmente. A instância I18n é global; cada useLingui() subscreve o componente a ela.

.
├── lingui.config.ts
└── src
    ├── i18n.ts                          # setupI18n(), load(), activate()
    ├── locales
    │   ├── en
    │   │   ├── messages.po
    │   │   └── messages.mjs             # saída de lingui compile
    │   └── fr
    │       ├── messages.po
    │       └── messages.mjs
    ├── components
    │   └── Counter.tsx                  # const { t } = useLingui(); t`Increment`
    └── routes
        └── $locale
            └── about.tsx                # await import(`../locales/${locale}/messages.mjs`)

O Intlayer compila dicionários. Cada arquivo .content.ts é um dicionário atrelado a uma chave; o compilador identifica qual componente requisita qual chave e gera, por dicionário e por idioma, rigorosamente o JSON que aquele componente precisa. A unidade central é o componente. O escopo por rotas é uma consequência natural: uma tela apenas baixa os dicionários dos componentes que efetivamente renderiza.

.
├── intlayer.config.ts
└── src
    ├── components
    │   └── Counter
    │       ├── index.tsx                # useIntlayer("counter")
    │       └── index.content.ts
    └── routes
        └── $locale
            ├── about.tsx
            └── about.content.ts

É por essa razão que o padrão scoped-dynamic é uma entrega nativa e automática do Intlayer, enquanto no Lingui constitui um projeto próprio de engenharia de configuração. O abismo aumenta em dois eixos ao mesmo tempo, páginas e idiomas:

Para reproduzir as marcas da linha dynamic, defina dictionary.importMode: 'dynamic' no seu intlayer.config.ts. Acesse a documentação sobre otimização de bundle.

Experiência do desenvolvedor

Configuração

import { defineConfig } from "@lingui/cli";

export default defineConfig({
  sourceLocale: "en",
  locales: ["en", "fr"],
  catalogs: [
    {
      path: "<rootDir>/src/locales/{locale}/messages",
      include: ["src"],
    },
  ],
});

import { setupI18n } from "@lingui/core";

export const loadCatalog = async (locale: string) => {
  const { messages } = await import(`./locales/${locale}/messages.mjs`);
  const i18n = setupI18n();
  i18n.load(locale, messages);
  i18n.activate(locale);
  return i18n;
};

import { type IntlayerConfig, Locales } from "intlayer";

const config: IntlayerConfig = {
  internationalization: {
    locales: [Locales.ENGLISH, Locales.FRENCH],
    defaultLocale: Locales.ENGLISH,
  },
};

export default config;

Componente

import { useState } from "react";
import { useLingui } from "@lingui/react/macro";
import { Trans } from "@lingui/react/macro";

export const Counter = () => {
  const { t, i18n } = useLingui();
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>{i18n.number(count)}</p>
      <button aria-label={t`Counter`} onClick={() => setCount((c) => c + 1)}>
        <Trans>Increment</Trans>
      </button>
    </div>
  );
};

import { t, type Dictionary } from "intlayer";

const counterContent = {
  key: "counter",
  content: {
    label: t({ en: "Counter", fr: "Compteur" }),
    increment: t({ en: "Increment", fr: "Incrémenter" }),
  },
} satisfies Dictionary;

export default counterContent;

import { useState } from "react";
import { useIntlayer } from "react-intlayer";
import { useNumber } from "react-intlayer/format";

export const Counter = () => {
  const { label, increment } = useIntlayer("counter");
  const number = useNumber();
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>{number(count)}</p>
      <button aria-label={label} onClick={() => setCount((c) => c + 1)}>
        {increment}
      </button>
    </div>
  );
};

Fora dos componentes

Metadados, funções de carregamento (loaders), funções de servidor: em qualquer ponto fora da árvore do React.

import { setupI18n } from "@lingui/core";
import { msg } from "@lingui/core/macro";

const title = msg`About us`;

export const loader = async ({ params }: { params: { locale: string } }) => {
  const { messages } = await import(
    `../../locales/${params.locale}/messages.mjs`
  );
  const i18n = setupI18n({
    locale: params.locale,
    messages: { [params.locale]: messages },
  });

  return { title: i18n._(title) };
};

import { getIntlayer } from "intlayer";

export const loader = async ({ params }: { params: { locale: string } }) => {
  const { title } = getIntlayer("about-metadata", params.locale);

  return { title };
};

Mantenha as macros do Lingui, adote dicionários do Intlayer

O @intlayer/lingui atua como um adaptador compatível para @lingui/core e @lingui/react. As macros continuam compilando normalmente; as chamadas resultantes para i18n._() passam a ser atendidas pelos dicionários do Intlayer, enquanto os plugins de sincronização .po sustentam seus catálogos originais como fonte da verdade. Plurais e condicionais ICU comportam-se com paridade absoluta.

import { defineConfig } from "vite";
import { lingui } from "@intlayer/lingui/plugin";

export default defineConfig({
  plugins: [lingui()],
});

Mantenha @lingui/babel-plugin-lingui-macro ou @lingui/swc-plugin no processo de build, executando antes do compilador do Intlayer. Verifique a documentação de compatibilidade com Lingui.

Qual ferramenta escolher?

FAQ

Comparações correlatas

Mesmo benchmark, outras bibliotecas:

Indo além:

Documentação de referência:

Para entender de onde vêm essas bibliotecas, leia a história do i18n em JavaScript.

Estrelas no GitHub

As estrelas no GitHub expressam a aprovação do público, a confiança técnica da comunidade e a sustentabilidade de uma iniciativa a longo prazo. Embora não sejam um aferidor estrito de qualidade de código, revelam o volume de desenvolvedores que confiam na solução.

Atividade de commits

As estrelas mostram popularidade. Os commits mostram quanto trabalho é investido num projeto. No momento em que este texto foi escrito, o Intlayer soma cerca de 7.500 commits, mais do que a maioria das bibliotecas comparadas aqui e cerca de 5 vezes mais do que next-intl ou next-i18next.

O Intlayer é um monorepo, então o total inclui cada pacote de framework, a CLI e a documentação. Leia os commits como um sinal de atividade, não de qualidade.

Downloads no npm

Os downloads recompensam as soluções mais antigas, não as melhores. Uma biblioteca lançada há anos continua sendo instalada por cada projeto que a escolheu na época, por cada execução de CI e por cada pacote que depende dela. O número mede a inércia mais do que uma escolha atual.

Os assistentes de IA amplificam o efeito. next-intl, i18next e vue-i18n estão por toda parte no código com que foram treinados, então eles os sugerem por padrão, sem comparar as alternativas. Cada sugestão gera downloads, que alimentam a próxima sugestão. Compare pelo benchmark, não pelo número de downloads.

Conclusão

O Lingui desponta como a biblioteca híbrida de runtime e compilador mais robusta deste teste comparativo. Seus catálogos compactados com chaves hasheadas proporcionam uma contagem de JavaScript por página a escassos kilobytes do Intlayer, chegando a superá-lo por fração mínima no TanStack Start. Se o peso total por página fosse a única meta, teríamos um empate prático.

Contudo, não é. O compilador do Lingui encerra sua atuação no limite do idioma; qualquer subdivisão abaixo disso (catálogos por rota, carregamento sob demanda, supressão de textos de fallback) é responsabilidade manual do desenvolvedor. O benchmark explicita o custo dessa barreira: componentes 10 a 20 vezes maiores, hidratação 2 a 3 vezes mais lenta, 3-15% de vazamento perpétuo de textos de fallback e um atraso de 42 ms ao alternar idiomas no modo otimizado. O compilador do Intlayer atua no nível atômico do componente: essas marcas caem por padrão para 6-8 KB, 11-14 ms, 0% e 3-4 ms, sem qualquer esforço de configuração.

A totalidade dos dados brutos, dos projetos de teste e dos scripts analíticos está aberta no repositório Benchmark Bloom. Fique à vontade para executar as medições em sua máquina.

Consulte a documentação 'Por que o Intlayer?' para aprofundar seu conhecimento.