SSR vs SPA | Qual usar?

O objetivo deste artigo é guiá-los na escolha da melhor tecnologia para sua aplicação.

Quando iniciei minha carreira, comecei com JSF (JavaServer Faces), um MPA (Multi-Page Application) no qual o servidor entregava o HTML completamente renderizado para o navegador apenas exibir. Cada interação do usuário resultava em uma nova requisição e, consequentemente, em um novo carregamento de página.

Pouco tempo depois, o Ajax explodiu em popularidade — junto com o jQuery — e passou a permitir a atualização de apenas partes da página. Isso trouxe mais dinamismo às aplicações e reduziu significativamente a quantidade de reloads completos, melhorando a experiência do usuário sem abandonar o modelo server-side.

Em seguida, houve uma ruptura. Os dispositivos pessoais se tornaram mais potentes, os navegadores evoluíram e isso abriu espaço para utilizar o cliente como principal responsável pela renderização da interface. Nesse contexto, o modelo SPA (Single-Page Application) ganhou popularidade e passou a dominar o desenvolvimento frontend.

O SPA consolidou o backend como um provedor de APIs, separando de forma mais clara frontend e backend. Essa mudança ajudou a reduzir custos de infraestrutura e aumentou a flexibilidade arquitetural, mas também trouxe novos problemas: o primeiro carregamento das aplicações ficou mais lento e o SEO das páginas públicas piorou significativamente.

É nesse cenário que o SSR surge como uma tentativa de corrigir os problemas das SPAs sem simplesmente retornar ao modelo do passado. A página volta a ser renderizada no servidor, garantindo um carregamento inicial mais rápido e melhor indexação, mas após a entrega inicial ela passa a se comportar como uma SPA no navegador.

O que mudou ao longo do tempo não foi apenas a tecnologia, mas a forma como equilibramos responsabilidades entre servidor, cliente, performance e experiência do usuário.

Qual devo usar?
Antes de decidir entre SPA ou SSR, é fundamental responder a algumas perguntas básicas sobre o projeto:

1. Para quem é esta aplicação?
   É um sistema interno, um painel administrativo, uma ferramenta autenticada ou uma aplicação pública voltada para usuários finais?

2. Qual é o meu orçamento?
   Tenho recursos para manter uma infraestrutura mais complexa, com renderização no servidor, cache e possíveis custos adicionais de escalabilidade?

3. Preciso que a primeira renderização seja rápida?
   O tempo até o primeiro conteúdo visível é crítico para a experiência do usuário?

4. SEO é importante para a página?
   O conteúdo precisa ser indexado por mecanismos de busca ou compartilhado em redes sociais com preview adequado?

5. Qual é o tamanho da aplicação?
   Mesmo que a primeira renderização precise ser rápida, nem sempre o tamanho e a complexidade da aplicação justificam o uso de SSR.

Para quem é o SPA
Use SPA quando a aplicação se comporta mais como um software do que como um site. Nesses cenários, o tempo da primeira renderização e o SEO não são fatores críticos.

Exemplos:
Ferramentas internas ou aplicações que exigem autenticação para acesso. Nesse tipo de sistema, as funcionalidades e informações não estão disponíveis ao público em geral, mas restritas a usuários específicos, como equipes internas, parceiros ou clientes autenticados.

Para quem é o SSR
Use SSR quando a aplicação se comporta mais como um site do que como um software. Nesses cenários, o tempo da primeira renderização e o SEO são fatores críticos para o sucesso do projeto.

Exemplos:
Sites institucionais, blogs, portais de conteúdo, e-commerces e landing pages. Em aplicações desse tipo, o conteúdo precisa estar disponível rapidamente, ser facilmente indexado por mecanismos de busca e gerar previews corretos ao ser compartilhado em redes sociais.

Conclusão
Durante minha carreira vi pequenas aplicações serem criadas com SSR antes validar se o SPA poderia atender. Vi aplicações pequenas com muito acesso necessitando de 16 servidores para atender a quantidade de requisições. Porém somente parte do conteúdo era púplico e a grande maioria era autenticado. Neste caso você poderia ter duas aplicações e reduzir a quantidade de servidores.

No fim, a melhor tecnologia é aquela que atende aos requisitos do negócio, equilibrando corretamente custo e benefícios.