SSR vs SPA | Qual usar?

Source: Dev.to

Introdução

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:

• 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?

• 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?

• 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?

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

• 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.
  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.
  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 de validar se o SPA poderia atender. Também vi aplicações pequenas com muito acesso necessitando de 16 servidores para atender à quantidade de requisições, embora apenas parte do conteúdo fosse público e a grande maioria fosse autenticada. Nesse caso, poderia‑se ter duas aplicações distintas 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.