React Server Components (RSC) representam a maior mudança arquitetural do React desde os hooks. Eles permitem que componentes sejam renderizados exclusivamente no servidor, enviando apenas HTML e dados para o cliente — sem JavaScript desnecessário. Isso muda fundamentalmente como pensamos sobre a divisão entre servidor e cliente em aplicações React.
O problema que RSC resolve
Em uma aplicação React tradicional, todo componente é enviado como JavaScript para o browser: código de renderização, dependências, lógica de data fetching. Uma página que mostra uma lista de artigos do blog envia React, a biblioteca de markdown parsing, componentes de UI, hooks de fetch — mesmo que todo esse processamento pudesse acontecer no servidor e enviar apenas o HTML resultante.
O resultado é bundles JavaScript inflados que prejudicam performance, especialmente em dispositivos móveis e conexões lentas. RSC resolve isso permitindo que componentes que não precisam de interatividade sejam renderizados inteiramente no servidor, com zero JavaScript no bundle do cliente.
Server Components vs Client Components
Por padrão no Next.js App Router, todo componente é um Server Component. Ele roda no servidor, tem acesso direto ao banco de dados, file system e variáveis de ambiente. Não pode usar hooks como useState ou useEffect, e não pode ter event handlers como onClick. Quando você precisa de interatividade, marca o componente com “use client” no topo do arquivo, e ele se torna um Client Component — enviado como JavaScript ao browser.
A composição é a chave: um Server Component pode renderizar Client Components dentro dele, mas não o contrário. Na prática, a maioria da página é Server Component (layout, header, sidebar, conteúdo estático, listagens), e apenas ilhas de interatividade são Client Components (formulários, modais, carousels, dropdowns).
Data fetching simplificado
Em Server Components, data fetching é direto e simples: você usa async/await diretamente no componente, sem useEffect, sem useState para loading states, sem bibliotecas de data fetching. O componente é uma função assíncrona que busca dados e retorna JSX. O Next.js faz cache inteligente dessas requisições, deduplicando chamadas idênticas automaticamente.
Isso elimina inteiras categorias de bugs comuns: race conditions de useEffect, estados de loading inconsistentes, waterfalls de data fetching onde um componente espera o outro carregar para começar sua própria requisição. Com RSC, todo o data fetching pode acontecer em paralelo no servidor antes de qualquer HTML ser enviado.
Streaming e Suspense
RSC integra nativamente com Suspense para streaming progressivo. Partes rápidas da página (header, sidebar) são enviadas imediatamente, enquanto partes lentas (dados de API externa, queries complexas) continuam processando no servidor. O browser renderiza o que já recebeu e preenche as lacunas conforme os dados chegam — sem janks, sem flash de conteúdo, com fallbacks de loading granulares.
Na prática, isso significa que o usuário vê conteúdo útil em milissegundos, mesmo que partes da página dependam de operações lentas. A experiência é vastamente superior ao spinner fullpage tradicional.
Padrões e boas práticas
Mantenha Client Components o menor possível: extraia um botão interativo para seu próprio arquivo “use client” em vez de marcar a página inteira como client. Passe dados serializáveis como props de Server para Client Components — não tente passar funções, classes ou objetos com métodos. Use Server Actions para mutações: formulários que chamam funções do servidor sem criar endpoints de API separados.
O paradigma de RSC não é apenas uma otimização de performance — é uma nova forma de pensar a arquitetura de aplicações React. Componentes que não precisam do browser simplesmente não vão para o browser. O resultado é aplicações mais rápidas, mais simples e mais fáceis de manter. Se você usa React em 2026, entender RSC não é opcional — é fundamental.
Tem um projeto em mente?
Somos especialistas em transformar ideias em produtos digitais. Apps, sites, automações e IA — vamos construir juntos.
