Single Page Application (SPA): o que é, quando usar e quando não

Uma Single Page Application carrega uma vez e não recarrega mais. Você clica, a tela muda, e o navegador não pisca: em vez de pedir uma página nova ao servidor, a aplicação troca só o pedaço que mudou.

O ganho é real e a conta também. A SPA não elimina trabalho, ela desloca: tira carga do servidor a cada clique e concentra tudo no primeiro carregamento, no navegador de quem chega. Este texto mostra os dois lados, e termina no que importa na hora de decidir.

O que é uma SPA, na prática

No modelo tradicional, cada clique é um pedido de documento. O navegador descarta o que tinha, pede uma página nova ao servidor, recebe HTML pronto e desenha tudo de novo, incluindo o cabeçalho e o menu que não mudaram.

Numa SPA acontece outra coisa. O primeiro acesso baixa um HTML mínimo e um pacote de JavaScript que contém a aplicação inteira. A partir daí, o navegador assume o controle: quando você clica, o JavaScript busca apenas os dados que faltam, normalmente em JSON, e redesenha só a parte da tela que mudou. A URL muda, o botão voltar funciona, mas nenhum documento novo foi carregado.

Isso muda o papel do servidor. Ele deixa de entregar telas e passa a entregar dados, o que significa que toda SPA depende de uma interface bem definida entre sistemas para funcionar. A qualidade dessa camada costuma determinar a qualidade da aplicação inteira: SPA sobre API mal desenhada vira uma sucessão de telas esperando resposta.

SPA e MPA: o que muda no ciclo

O modelo tradicional tem nome próprio, Multiple Page Application, e continua sendo a escolha certa em muitos casos. Grandes portais de notícia e boa parte do comércio eletrônico funcionam assim, e não por atraso tecnológico: é o modelo que serve melhor a quem chega de uma busca e talvez veja uma página só.

Repare no que os dois diagramas mostram. No primeiro, a expressão que se repete é page reload. No segundo, ela aparece uma vez só, no começo. É a diferença inteira, resumida em um desenho.

O que a SPA entrega

Os ganhos aparecem depois do primeiro carregamento, e para quem fica são grandes:

• Resposta imediata. Sem recarregar documento, a troca de tela acontece em milissegundos. É o que dá a aplicações web a sensação de aplicativo instalado.
• Menos tráfego por interação. Trafegam dados, não marcação. Um JSON de alguns kilobytes no lugar de uma página inteira com cabeçalho, menu e rodapé repetidos.
• Estado que sobrevive à navegação. Filtros aplicados, rascunho digitado e posição de rolagem continuam onde estavam, porque a aplicação nunca foi descartada.
• Menos trabalho no servidor por clique. Ele responde com dados, e não monta HTML a cada requisição.
• Interface mais elaborada. Transições contínuas e componentes que reagem sem esperar o servidor ficam viáveis, o que se apoia bem em um design system consistente.

O que a SPA cobra

Esta é a parte que costuma faltar nos textos sobre o assunto, e é onde as decisões erradas acontecem.

O primeiro carregamento fica caro. Antes de a primeira tela útil aparecer, o navegador precisa baixar o pacote de JavaScript, interpretá-lo e executá-lo. Em conexão móvel e aparelho modesto, isso é a diferença entre abrir e desistir, e é exatamente o que as métricas de experiência do Google medem: LCP, INP e CLS. O ponto se agrava porque a maioria do tráfego chega de celular, e vale reler o que isso implica em projetar primeiro para o celular.

A busca enxerga menos. O Google executa JavaScript, mas em uma segunda passada, depois da primeira leitura do HTML, e essa passada compete por recursos com o resto do site. Conteúdo que só existe depois da execução pode demorar a ser indexado, ou não ser. Fora do Google a situação é pior: vários rastreadores, incluindo os que geram a prévia de links em redes sociais e aplicativos de mensagem, leem apenas o HTML inicial.

Acessibilidade precisa ser feita à mão. Trocar conteúdo sem recarregar a página significa que o leitor de tela não é avisado de que algo mudou, e que o foco do teclado fica onde estava. Nada disso é automático: exige anúncio de mudança de rota e gestão explícita de foco, um dos pontos práticos da acessibilidade em projetos digitais.

O navegador para de resolver de graça. Histórico, botão voltar, restauração de rolagem e tratamento de erro passam a ser responsabilidade da aplicação. Cada um deles é um comportamento que o modelo tradicional entregava sem uma linha de código.

CSR, SSR e SSG: onde a página é montada

Boa parte dos problemas acima vem de uma escolha específica, e não da SPA em si: montar tudo no navegador. Isso se chama renderização no cliente, ou CSR, e é apenas uma das opções.

Com SSR ou SSG, o visitante e o buscador recebem HTML pronto na primeira resposta, e a aplicação assume o controle depois, mantendo a navegação fluida. É a combinação que resolve o falso dilema entre performance e indexação, e é por isso que ela virou o padrão da indústria. Não existe obrigação de escolher um modelo para o site inteiro: é comum servir as páginas públicas como conteúdo estático e deixar a área logada como SPA pura.

Com o que se constrói hoje

A camada de componentes é ocupada por quatro nomes principais: React, o mais difundido, Vue, Angular e Svelte. Escolher entre eles é menos decisivo do que parece, e o critério que mais pesa é quem vai manter o código depois.

A decisão que importa está na camada de cima, a dos chamados meta-frameworks, que é onde se define o modelo de renderização: Next.js e Remix para React, Nuxt para Vue, SvelteKit para Svelte, e Astro quando o site é majoritariamente conteúdo e a interatividade fica em ilhas isoladas. É essa escolha que determina se as páginas chegam prontas ou montadas no navegador.

Vale um aviso sobre material antigo, porque este texto já foi um exemplo do problema. Muito conteúdo em português sobre SPA cita como referência um artigo da MSDN Magazine de 2013, uma publicação encerrada, hospedado num domínio que hoje só redireciona. Recomenda Ember, que perdeu relevância. E aponta para a documentação do Angular em um endereço que passou a servir uma versão arquivada. Ao pesquisar sobre o assunto, olhe a data antes do conteúdo.

Quando usar, e quando não

A pergunta útil não é se SPA é bom, é quanto tempo o visitante passa dentro da aplicação. Todo o modelo se justifica pela diluição do custo inicial ao longo de muitas interações. Poucas interações, e o custo não se dilui.

Repare que a coluna da direita não é uma lista de casos simples: é a lista de casos em que a pessoa chega, resolve e sai. Para eles, o modelo tradicional continua sendo a resposta certa, e a alternativa moderna é conteúdo pré-renderizado, não uma SPA com remendos.

Na maioria dos projetos reais a resposta é mista, e a decisão pertence à fase de definição de escopo, junto com as outras escolhas estruturais. Tratá-la como detalhe de implementação é o caminho mais curto para descobrir tarde demais que o site não indexa. É o tipo de decisão que separa um site montado às pressas de um software aplicativo pensado para durar.

Perguntas frequentes