- Com o surgimento de recursos modernos de CSS como a View Transitions API, já não é mais necessário adotar uma arquitetura SPA para obter transições de página suaves
- A maioria dos sites SPA não entrega, na prática, o nível de desempenho ou fluidez que se esperava, e o excesso de código JavaScript tende a prejudicar a experiência do usuário
- Em navegadores baseados em Chromium, é possível implementar navegação rápida e natural sem JavaScript usando transições de página nativas e Speculation Rules
- A estrutura complexa das SPAs atrapalha as otimizações do navegador, por isso, em sites reais, uma arquitetura MPA centrada em HTML e CSS é mais rápida e mais fácil de manter
- Daqui para frente, é preciso evitar a adoção desnecessária de SPAs e usar CSS moderno e recursos nativos para desenvolver sites eficientes e fáceis de manter
Introdução: o fim das SPAs e o surgimento do CSS moderno
- Com a adoção recente de recursos modernos de CSS como a View Transitions API, as principais vantagens que as SPAs (single-page applications) ofereciam deixaram de ser necessárias
- Muitas equipes ainda escolhem frameworks SPA como React e Vue, mas o centro dessa decisão não é desempenho, e sim um equívoco sobre interações e uma experiência de navegação fluida
- A prática de acreditar que uma SPA é essencial para uma navegação suave já é uma mentalidade ultrapassada
A ilusão e a realidade das SPAs
- As SPAs já foram a única forma de implementar as transições de página mais naturais, mas isso não é mais verdade
- Muitas SPAs apresentam os seguintes problemas:
- apenas efeitos de fade em estados de carregamento, sem uma fluidez real na transição de conteúdo
- problemas de restauração de rolagem e tratamento inconsistente de foco
- atrasos de navegação causados por renderização/hidratação tardias
- layout shift e conteúdo surgindo de repente, carregamento com skeleton etc.
- complexidade desnecessária e uso excessivo de JavaScript, com pouco ganho real em relação ao custo de desempenho
- Frameworks SPA representativos (Next.js, Gatsby, Nuxt etc.) adicionam grandes quantidades de código JS para imitar o comportamento nativo básico do navegador
- Como resultado, sacrificam a naturalidade nativa, ficam mais lentos e ainda causam piora em SEO
A evolução da plataforma web e a mudança no papel do CSS
- Navegadores modernos baseados em Chromium (Chrome, Edge etc.) já suportam transições de página nativas e declarativas
- Com a View Transitions API, é possível implementar animações suaves entre documentos ou entre páginas inteiras sem JavaScript
- As principais capacidades são:
- efeitos de fade entre páginas (implementáveis com apenas 3 ou 4 linhas de CSS)
- animações de elementos compartilhados, como a transição natural de uma miniatura para a imagem detalhada
- preservação de elementos persistentes como header e navbar
- como há URL real e navegação de página real, a compatibilidade com SEO, compartilhamento de links e cache de voltar/avançar é maximizada
Como aproveitar plenamente a sinergia entre CSS e JS
- Se necessário, também é possível chamar manualmente uma View Transition via JS em transições dentro da própria página
- Ex.: troca de tema, alternância de abas, mudança para modo escuro, usando apenas o mínimo de JavaScript
Speculation Rules e navegação instantânea
- Speculation Rules permitem que o navegador pré-carregue/pré-renderize páginas prevendo o comportamento do usuário (por exemplo, ao passar o mouse), oferecendo navegação instantânea
- A configuração pode ser feita de forma declarativa via
<script type="speculationrules">
- Premissa: o efeito de máximo ganho de performance acontece quando a página é leve e otimizada; em páginas pesadas, pode haver desperdício de recursos
Respeito aos recursos nativos do navegador e ao bfcache
- O bfcache (Back/Forward Cache) restaura instantaneamente a página inteira em forma de snapshot quando o usuário navega para trás/para frente
- Pré-condição: é necessário ter uma arquitetura limpa, baseada em HTML e CSS puros; em estruturas que interceptam roteamento, como SPA, isso não se aplica
- Em resumo, os navegadores modernos estão evoluindo para recompensar sites simples e robustos
Comparação de desempenho entre SPA e MPA
- SPA média (com base em Next.js):
- tamanho do bundle JS: 1–3MB
- TTI (tempo até ficar utilizável): 3,5–5 segundos
- transição de rota: falsa/simulada
- SEO: complexo, difícil de manter
- comportamento de rolagem/âncoras: instável
- MPA moderna (com transições em CSS e Speculation Rules):
- bundle JS: 0KB (aprimoramentos opcionais apenas)
- TTI: em torno de 1 segundo
- transição de rota: comportamento nativo real
- SEO: muito fácil
- rolagem inteligente, foco e histórico: comportamento padrão do navegador com suporte completo
Distinção entre site e app, e a necessidade de repensar a adequação
- A maior parte dos sites não é, de fato, um "app" e não precisa de estado compartilhado, roteamento no cliente nem interações complexas
- Para páginas de marketing, portais de documentação, e-commerce, blogs etc., uma estrutura centrada em HTML, com carregamento rápido e arquitetura simples é mais adequada
- Adotar uma stack SPA em todo projeto pode provocar complexidade excessiva e degradação de desempenho
- exigência de "parecer um app"
- adoção de framework
- roteamento no cliente e aumento da complexidade
- queda de desempenho e necessidade de otimizações adicionais
- e, ainda assim, uma realidade mais lenta do que links nativos + animações em CSS
Conclusão e recomendação
- As SPAs eram, no passado, uma espécie de paliativo para as limitações da plataforma, mas hoje essas restrições já não existem mais
- Agora já é possível aproveitar ativamente os seguintes recursos nativos:
- transições reais entre páginas
- pré-renderização instantânea com Speculation Rules
- uma estrutura forte em degradação progressiva
- markup limpo, carregamento rápido e uso de URLs reais
- uma arquitetura que consegue aproveitar ao máximo a ajuda da plataforma
- Se você insistir em SPA apenas por causa da "fluidez", acabará pagando o preço em complexidade, desempenho e manutenibilidade
- Com renderização no servidor, páginas reais, animações baseadas em CSS, pré-carregamento intencional e o mínimo de JS, é possível criar sites rápidos e agradáveis, adequados ao momento atual
- Usando a tecnologia disponível em 2025, é hora de buscar uma experiência web mais rápida, mais simples e acolhedora para todos
10 comentários
Desde o início, se a única razão para considerar um SPA fosse a "suavidade", eu teria simplesmente aberto mão dessa suavidade e escrito como MPA, então não consigo me identificar muito com isso...
O ponto fraco deste texto
Interpreta de forma reduzida o verdadeiro propósito de uma SPA
A View Transitions API é realmente muito interessante, mas isso por si só não significa que uma SPA deixe de ser necessária.
Analisa todos os sites com o mesmo critério
Site de marketing ≠ dashboard ≠ app de comércio ≠ ferramenta de colaboração em tempo real
Cada um tem exigências estruturais diferentes.
Na prática, SPA + SSR + MPA coexistem
Frameworks híbridos como o Next.js mostram isso muito bem.
Recursos estáticos usam SSG, dashboards pós-login usam CSR/SPA, e compatibilidade com mecanismos de busca usa SSR; é necessária uma combinação flexível.
Acredito que a SPA está mais próxima de ser um produto de melhoria estrutural do que apenas de experiência do usuário.
Em páginas nas quais uma SPA é desnecessária, MPA + CSS moderno pode ser uma boa escolha, mas a SPA continua sendo essencial em termos de estrutura, estado, escalabilidade e manutenção. Acho que o CSS moderno pode "complementar" a SPA, mas não "substituí-la".
Entre os casos que você apresentou, o único que não dá para substituir por view transitions e afins é ferramenta de colaboração em tempo real, mas a grande maioria dos sites não é uma ferramenta de colaboração em tempo real. Sites de marketing, dashboards e apps de comércio podem todos ser construídos excluindo frameworks SPA e seguindo as condições de renderização no servidor, páginas reais, animações baseadas em CSS, pré-carregamento intencional e adoção mínima de JS. Há também o Hotwire, da comunidade Rails, que busca essa direção, e existem casos em produção como Basecamp e HEY. Gerenciamento de estado? A menos que seja algo como ferramenta de colaboração em tempo real, métodos do lado do servidor como parâmetros de URL e sessão de servidor, ou então localStorage, já são suficientes. Também há claramente casos em que se adota SPA por causa das transições de página (como o site oficial da AGF, que poderia muito bem usar Astro, mas adotou React), e não dá para negar que transição de página é algo muito citado como uma das principais vantagens de SPA.
Embora seja verdade que os frameworks SPA atuais e a tendência de frontend baseada neles exijam vigilância constante contra a não padronização, além de tenderem a provocar overengineering e consumo desnecessário de recursos...
Acho também que a própria ideia de SPA está sendo vista de forma estreita, mas, mais do que isso, fico em dúvida se se entende que impacto os frameworks SPA exercem sobre o desenvolvimento como um todo.
Dizer que, com apenas a View Transition API, tendo CSS, já está tudo resolvido significa, em outras palavras, que todos os recursos não relacionados a isso, bem como o paradigma necessário para alcançá-los, seriam completamente sem sentido — e isso me parece uma visão arrogante demais.
Isso é uma questão diferente do overengineering de usar React para criar um site que mal passa de um substituto de folheto institucional.
Concordo que, na maioria dos projetos pequenos, não há necessidade de um framework SPA, mas, em serviços cujos requisitos envolvem interações complexas, experiência contínua do usuário, manutenção e melhorias constantes, penso que isso não deixa de ser necessário, apesar da evolução do CSS.
Sinceramente, parece quando alguém fala de Rust ou Haskell sem nem ter encostado nelas e diz: "isso aí hoje em dia dá para fazer tudo com C++".
Hum, não sei. O objetivo de usar frameworks SPA não é mais para interações complexas com o usuário do que para transições suaves?
Há claramente casos em que se adota um framework SPA só por causa de uma única interação suave. Muitos dos sites que usam SPA nem precisam de interações complexas.
Concordo bastante
Um exemplo bem claro é que o próprio React também é o Spring do front-end
É pesado e complexo, e parece que o trabalho fica mais conveniente, mas na prática é uma conveniência estranha: você configura um processo mais complicado só para fazer coisas simples e depois ainda precisa de ferramentas para tornar esse processo complicado supostamente mais conveniente
Concordo. A menos que seja um web app complexo como o Google Docs, acho que até o Hotwire, criado pelo ecossistema Rails, já é suficiente, e para páginas estáticas o Astro também dá conta.
Comentários do Hacker News
SPA faz sentido quando o usuário passa sessões longas em um único app, ou seja, numa estrutura em que você carrega um bundle grande uma vez e depois consegue usar o app com apenas pequenas requisições de rede; efeitos de transição suaves são só um bônus, e não acho que sejam o problema essencial que SPAs resolvem; dizer que o roteamento no lado do cliente existe para transições de página é entender mal o propósito das SPAs; se você usou SPA com essa premissa equivocada, então este artigo está certo, mas SPA surgiu na era do jQuery para apps complexos; enormes blocos de código jQuery em que cada
divfuncionava como um miniapp e tudo era sincronizado com muitas pequenas requisições de rede; em navegadores antigos e internet lenta, isso permitia uso eficiente sem recarregar todo o código a cada vez; depois frameworks como React evoluíram facilitando o desenvolvimento estruturado de apps, e a principal vantagem de uma SPA é armazenar em cache um bundle grande de uma vez para usuários com sessões longas e depois minimizar o tráfego de rede(Citação do comentário acima: "...if you shared that misunderstanding of SPAs and used them to solve the wrong problem, this article is 100% correct.") Concordo totalmente; o autor é consultor de SEO e parece focar só em sites de marketing; apps de verdade (não sites de marketing) podem se beneficiar muito de SPA; por exemplo, imagine fazer o Google Maps sem SPA: mesmo adicionando só animações de transição de página, a UX pioraria seriamente
Tem a expressão “só empilharam espaguete de jQuery”, mas na prática eu aplicava padrões de design JS mais antigos, como IIFE, para estruturar o código, fazer lazy loading de módulos, ofuscação de código etc.; e, pela minha experiência, AngularJS foi a maior tentativa de estruturar o frontend, e o motivo de atrair desenvolvedores Java era modularização, DI e facilidade de teste; no começo, quando eu fazia apps com Backbone, achava que a maior parte da funcionalidade ficaria no backend e não ligava muito para testes, mas depois, ao reconstruir com AngularJS, passei a ter muito mais testes de frontend; claro, hoje em dia tenho rejeição à verbosidade, complexidade e indireção do Angular moderno e também do código Java
Acho que conexões de rede lentas e cache agressivo são um dos motivos mais fortes para precisar de SPA (mais para aplicações do que para websites); se você tem uma conexão razoável, baixa todo o frontend de uma vez e deixa em cache, depois o uso passa a exigir largura de banda mínima
Se você trabalha em um lugar que usa pipelines modernos de CI/CD, esse grande bundle JS provavelmente é reconstruído e o cache invalidado toda vez que implantam algo, várias vezes por dia; HTTP/2 já é padrão nos navegadores há 10 anos, e com multiplexação não há mais motivo para agrupar JS em bundles enormes; a abordagem SPA de criar bundles grandes não aproveita os recursos modernos de navegador e servidor
Gostaria de saber quantos casos reais existem em que as requisições de rede realmente ficam muito pequenas após o carregamento; a maioria das SPAs que vi continua fazendo chamadas grandes mesmo depois de carregar e era muito mais lenta do que simplesmente mandar HTML direto; também não procede essa ideia de que JSON magicamente comprime melhor do que HTML; HTML também comprime muito bem; na prática, o argumento de que SPA é melhor por causa de rede é quase propaganda ou superstição
Acho que o valor da SPA não está só em transições suaves, mas em poder lidar com a maior parte da jornada do usuário no cliente e quase não precisar se preocupar com o servidor; por exemplo, me incomoda que em 2025 a maioria das lojas online ainda recarregue a página inteira e busque dados de novo toda vez que você muda um filtro ou entra numa categoria; quando o usuário fica indo e voltando entre categorias e gerando várias requisições, a UX melhora muito se você puder baixar o catálogo inteiro uma vez no cliente e depois filtrar sem falar com o servidor; claro, pode haver o contra-argumento de que há muitos dados, mas na maioria das lojas uma categoria cabe em alguns KB, menor do que uma única foto de produto; construo apps assim desde 2005 e ainda não entendo por que essa UX não é mais comum
Na minha opinião, a pior parte de ter que fazer recarga completa da página não é o tamanho dos dados, e sim a eficiência do site; os dados reais têm alguns KB, mas a própria página baixa 100 MB e o navegador consome 1 GB de RAM; por exemplo, o Hacker News em geral recarrega na navegação e funciona bem até em notebook antigo; já uma SPA como DoorDash levou 30 segundos no mesmo dispositivo, e demorou mais de 3 minutos para eu realmente conseguir pedir comida; tive que esperar 2,5 minutos para a interface aparecer, e mesmo assim quase nada disso era recarga completa
Ferramentas como HTMX resolvem bastante esse problema; acho que a abordagem SPA acaba resultando em dois apps separados, frontend e backend; eu prefiro fazer quase tudo no servidor e adicionar no cliente só efeitos interativos simples (mostrar/esconder, expandir/recolher, efeitos etc.); claro que existem lugares em que SPA é útil
Tive uma experiência parecida: alguns projetos pessoais eu hospedo em servidor web estático; em vez de renderizar dezenas de milhares de páginas individuais, renderizo no cliente numa SPA a partir de um único arquivo JSON; também usei Github Pages; recentemente venho experimentando uma estrutura que usa uma build wasm de banco de dados sqlite e busca só as páginas necessárias com HTTP Range Requests; o Full Text Search do sqlite até funciona, mas em buscas curtas é ruim porque precisa baixar a tabela inteira; talvez seja melhor baixar o banco todo e criar localmente a tabela FTS
Também há exemplos contrários: por exemplo, ao dar Shift-clique na categoria “sci-fi” para abrir em nova aba, em MPA isso funciona sem esforço, mas em SPA você precisa gerenciar isso à parte, o que é incômodo; se a categoria nem tiver link e só puder ser acessada por um Select Box, a UX fica ruim
Em geral, as empresas não querem que o usuário baixe o catálogo inteiro, porque concorrentes podem analisá-lo facilmente; além disso, em casos como venda de livros, pode haver centenas de milhares de títulos, então transferir tudo de uma vez é ineficiente tanto do ponto de vista da experiência do usuário quanto de banda e memória
O propósito de SPA não é, de forma alguma, transição de página; quase não existem SPAs que implementem boas transições de página; por exemplo, no Next.js, por causa do modo como o carregamento de rotas funciona, implementar transições de página é quase impossível; eu realmente tentei adicionar transições de página adequadas ao Next.js e foi um pesadelo completo; vejo duas vantagens claras da SPA: primeiro, a maioria dos apps quer algum grau de interatividade (HTML/CSS por si só não basta), e misturar React com HTML puro é um sofrimento enorme (especialmente quando você precisa de estado global); segundo, se você pré-carrega toda a estrutura da página, o carregamento posterior de dados fica mais rápido, e reagir imediatamente ao clique com uma tela de loading oferece UX melhor do que só responder 500 ms depois (embora abaixo de 100 ms a história mude); como não é preciso redesenhar a página inteira, a performance de frontend continua acima do que só HTML consegue acompanhar; há casos como Basecamp, que fez um webapp complexo muito bem sem SPA, mas basta clicar por 30 segundos para ver que não alcança a performance de uma SPA; eu gostaria que a web funcionasse mais como web, mas a complexidade extra que Next.js e SPA trazem de fato deixou os apps mais rápidos e responsivos, embora ao mesmo tempo tenha tornado o desenvolvimento mais trabalhoso e criado o problema de bundles grandes; ainda assim, acho que só HTML ainda não alcança a performance de uma SPA
Não sei em que universo vive esse consultor de SEO que escreveu o texto; usar Next e Nuxt como exemplos de frameworks que representam o oposto de SPA está completamente errado; 1. Next praticamente dominou os EUA/Ocidente, e quando se fala de app novo em React, quase sempre estão falando de Next; no ecossistema Vue, Nuxt é praticamente o padrão, e Nuxt = o Next do mundo Vue; ou seja, as pessoas estão escolhendo, de forma quase inconsciente, Next e a estratégia MPA; o pêndulo foi tão longe para MPA que eu diria até para tentarem SPA; os últimos 8 anos foram uma febre de retorno ao MPA, e agora até o Facebook recomenda oficialmente Next na documentação em vez de Create React App; 2. Reclamações sobre a complexidade do Next são, na verdade, reclamações sobre a dificuldade da estratégia MPA moderna; o lado SPA está quase parado há 10 anos; 3. Desenvolver MPA é muito mais difícil do que SPA, porque você precisa respeitar de forma bem mais rígida a separação entre servidor e cliente; 4. Se você quiser buscar dados no estilo MPA dentro de uma SPA, isso é escolha do desenvolvedor, e ele mesmo deve arcar com os prós e contras; também é possível pré-carregar dados e fazer navegação instantânea dentro da SPA; 5. Além do frontend principal onde SEO realmente importa, existem muitos dashboards internos e apps; geralmente é aí que estão os desenvolvedores React, então é importante não carregar peso desnecessário só por causa da obsessão em entregar o frame inicial perfeito
Acho injusto esse tom de desprezo contra SPA; SPA claramente exige mais esforço, mas também traz muito mais vantagens; por muito tempo, SPA foi a única forma de criar uma UX que parecesse app; o autor fala de fadiga de apps, mas, se você realmente quer oferecer uma experiência de “aplicação”, SPA é praticamente o único caminho; comparar uma SPA pesada com um website leve (site estático) não é apropriado; se alguém consegue fazer um website leve, também consegue fazer uma SPA leve; tanto SPA quanto website, se forem mal construídos, ficam lentos e pesados do mesmo jeito; como alguém que já investiu muito em SPA, sempre me interessei por formas de entregar a mesma experiência com menos esforço, mas este artigo parece mais um enfeite visual; a API é valiosa, mas não acho que seja impactante o suficiente para decidir se algo deve ou não ser SPA
Acho exagero dizer “tente fazer linear.app sem framework SPA”; e a tese “as transições nativas de CSS mataram a maior vantagem da SPA (roteamento no cliente)” não faz sentido
Acho que Linear é um caso muito particular até entre SPAs; não se trata de proibir SPA nem de remover JS completamente do navegador; Linear é rápido por causa do design “offline-first”, mas quase nenhum serviço faz isso; para venda de ingressos, fóruns, notícias, blogs e sites informativos, acho muito melhor desenvolver com base em SSR; use SPA só onde ela for realmente necessária, e no resto desenvolva rápido com SSR e use CSS para dar aparência de SPA; isso é muito mais eficiente
Não é que SPA não tenha lugar, mas os outros 99% dos sites não precisam ser SPA
SPA não existe por causa de view transitions (transições de página); o texto original (TFA) sugere que transições chamativas entre páginas são importantes (o que está errado); em vez de culpar “CMO” ou “gerente de marca”, deveríamos destacar o valor essencial da SPA; SPA é um ótimo framework para lógica no cliente, separação de responsabilidades (lógica de frontend separada do backend), melhor experiência de desenvolvimento → maior velocidade de entrega etc.; acho que tantos textos assim aparecem porque a estrutura deles provoca debate, como este meu comentário, mas na verdade não acho que seja um tipo de texto que mereça tanta atenção
Do meu ponto de vista, a principal promessa da SPA não é a transição suave, mas a criação de uma API de dados e de um frontend completamente separados do backend; por isso não gosto de misturar SSR com renderização no cliente; para mim, ou é website ou é app
Fico na dúvida sobre “qual é o critério entre SPA e MPA?”; meu site pessoal em Next.js, na prática, renderiza quase tudo no lado do servidor; tecnicamente é uma SPA, mas, se o JS estiver ativado, RSC e navegação no lado do cliente funcionam, e, se o JS estiver desativado, componentes só de cliente (por exemplo, gerador de QR code) mostram conteúdo alternativo, enquanto o resto é totalmente renderizado via SSR e continua funcionando, só um pouco mais lento; dá mais trabalho optar por não renderizar componentes no servidor; progressive enhancement é o melhor caminho
Window loaddo app é disparadoTambém acho muito frustrante ver gente da área de SEO ou novos desenvolvedores web contratados depois da pandemia entendendo mal e depreciando SPA; como alguém que desenvolve desde os anos 2000, para mim a verdadeira origem das SPAs não tem nada a ver com a “promessa falsa” citada no texto original, mas sim com a necessidade, no fim dos anos 2000 e começo dos 2010, de separar completamente frontend e backend por causa da estratégia mobile-first; antes disso, frontend normalmente era só HTML renderizado no servidor com templates e um pouco de jQuery por cima, mas hoje apps mobile e desktop precisam compartilhar a mesma lógica de negócio e o mesmo banco de dados, então estruturas REST, a releitura do trabalho de Roy Fielding, arquitetura orientada a serviços e exposição externa de APIs viraram tendência; também havia um aspecto de otimização de custos; nesse período, frameworks web full-stack como Ruby on Rails e Django passaram por uma fase de estagnação; com a ascensão do Node.js, navegadores e celulares também ficaram mais poderosos, permitindo mover muita lógica de negócio para o “edge device” (ou seja, o cliente); esse é o ponto central das SPAs, e não vejo como CSS possa substituir essa necessidade