X reconstrói app web em torno de um único servidor e acelera carregamento de perfis

O X trocou três servidores por um só no seu app web. Antes, o rweb renderizava no navegador para usuários logados e deslogados, o rweb SSR entregava HTML para crawlers de busca e o Jetfuel SSR servia páginas deslogadas indexáveis, como eventos, Spaces, Communities, Trends, busca e notícias. A mesma página podia ser montada de três formas diferentes, e uma correção de SEO podia ficar em um servidor e escapar dos outros. O ganho citado pela fonte, medido em conexão lenta, é de mais de 22 segundos para 2,7 segundos até o primeiro post de um perfil aparecer. Nesse cenário os seconds são a métrica central da reescrita.

A causa da lentidão vinha da herança do Twitter Lite, de 2017: um shell de aplicação, depois o JavaScript, depois a execução, depois a chamada à API GraphQL e só então a renderização. Em rede lenta, cada etapa é um round trip a mais. O novo app usa Vite (com Rolldown), React com streaming e Suspense, Fastify, Platformatic Watt em Node.js v26 com worker threads, Relay com GraphQL e a biblioteca de componentes XDS, com Base UI e Tailwind CSS. O servidor decide o render pelo solicitante: usuários recebem HTML em streaming, crawlers de busca verificados pelo IP recebem o documento completo sem hidratação, e bots de prévia de link recebem só título, descrição e imagem. Os cartões de imagem agora saem de um serviço em Rust. A migração é gradual, país por país, e o rweb segue no ar até todos migrarem.

Em 6 de novembro de 2026, o CEVIU noticiou "X.com é reconstruído do zero por cinco engenheiros com agentes de codificação de IA", sobre o mesmo app web, destacando a equipe pequena e o carregamento mais rápido em conexões lentas. A notícia de agora detalha a arquitetura: a consolidação de três servidores em um, a lógica por tipo de solicitante e a migração gradual dos usuários logados, país por país.

Para quem opera um app com SPA e SSR separados, o caso mostra o custo de manter caminhos de renderização paralelos: correções que se espalham e visitantes deslogados na pior rota. A leitura editorial é que decidir o render pelo tipo de cliente, num servidor só, reduz esse atrito. Vale notar também o uso de IP verificado em vez de User-Agent para identificar crawlers, escolha que a própria fonte justifica.