TanStack abandona RSC em favor de SSR mais simples

O problema original

No início de 2026, o site tanstack.com adotou React Server Components (RSC) para resolver um problema concreto: as páginas de documentação transferiam cerca de 1,1 MiB de JavaScript, dos quais 358 KiB vinham apenas do Shiki (syntax highlighting) e da stack de markdown. Com RSC, o markdown era renderizado no servidor e enviado como Flight payload, eliminando esse peso do cliente. O resultado foi real: páginas de blog perderam 153 KB gzipped, o Total Blocking Time caiu de 1.200ms para 260ms em uma rota, e o Lighthouse subiu de 52 para 74.

A pergunta que mudou tudo

Tanner Linsley percebeu que RSC estava resolvendo um problema de dependência transformando-o em uma decisão de arquitetura. A questão passou a ser: se o renderer fosse pequeno o suficiente para enviar ao cliente, RSC ainda faria sentido?

A equipe criou @tanstack/markdown e @tanstack/highlight, pacotes com contratos deliberadamente estreitos. O renderer explícito passou a custar cerca de 27 KiB transferidos - apenas 18 a 19 KiB a mais que a versão RSC.

Resultados da migração para SSR

Comparando produção atual (SSR) com a versão RSC anterior:

• /blog/react-server-components: TBT caiu de 139ms para 66ms; payload de 1.086 KiB para 889 KiB
• /router/latest/docs/overview: TBT caiu de 209ms para 115ms; payload de 1.017 KiB para 836 KiB

O App JS caiu 177 KiB em ambas as rotas. O custo adicional do renderer (18-19 KiB) é pago uma vez no primeiro carregamento.

O efeito das seis páginas

O visitante médio do tanstack.com acessa cerca de seis páginas por sessão. Na versão RSC, cada navegação enviava um novo Flight payload serializado. Na versão SSR, o renderer já está no cliente e as server functions enviam apenas os dados que mudaram. Em medições locais, cada requisição de conteúdo economiza entre 1,5 e 5,6 KB gzipped em relação ao RSC.

Complexidade removida

O commit de migração (92b1c481) removeu 9 arquivos de plumbing RSC (555 linhas) e 8 arquivos de plugins antigos (994 linhas). O caminho do conteúdo voltou a ser direto: server functions retornam dados, um componente Markdown renderiza normalmente, e abrir um arquivo não exige mais um modelo mental do bundler inteiro.

Posição sobre RSC

Linsley enfatiza que não está provando que SSR supera RSC em todos os casos. O benefício técnico concreto que RSC entregou foi manter dependências caras fora do bundle do cliente - e isso importa muito para renderers gigantes. Mas quando a dependência ficou pequena, a arquitetura parou de se justificar. TanStack Start continua suportando RSC como capacidade opcional; o site simplesmente parou de usá-lo.