Preciso de React para um Site? Quase Sempre Não — Eis o Que Usar
Precisa de React para um site? Para a maioria dos sites de conteúdo e marketing, não — HTML renderizado no servidor com um pouco de JavaScript simples é mais rápido, acessível e duradouro.
Precisa de React para um site? Para a esmagadora maioria dos sites de conteúdo e marketing — blogues, sites institucionais, documentação, portefólios, landing pages — não. HTML renderizado no servidor com um pouco de JavaScript simples carrega mais depressa, é mais fácil de tornar acessível, mais barato de manter e ainda funcionará daqui a dez anos. O React justifica-se quando a sua interface é uma aplicação genuinamente com estado, não um conjunto de páginas que alguém lê.
Dizemos isto como quem faz React profissionalmente. Não é um desabafo do tipo "JavaScript é mau". É um argumento sobre compromissos, e o compromisso costuma apontar para o lado oposto no tipo de site que a maioria das pessoas realmente constrói.
Preciso de React para um site? Comece por classificar o que está a construir
A pergunta mais útil é uma só: isto é um documento ou é uma aplicação?
- Documentos — páginas cuja função é apresentar conteúdo que o utilizador lê ou percorre. Uma homepage de marketing, um caso de estudo, uma página de preços, um artigo de diário, um site de documentação. O estado é superficial: abrir um menu, um separador, um formulário. O URL é o estado.
- Aplicações — interfaces com estado profundo, persistente e do lado do cliente, que muda mais depressa do que a rede: uma folha de cálculo, uma tela de design, um painel de cotações, um construtor com arrastar e largar, um cliente de chat. O DOM tem de manter-se sincronizado com um modelo que vive no browser.
O React foi feito para a segunda categoria. O feed do Facebook é uma aplicação. Pegar na mesma ferramenta para renderizar a página de produto de um chocolateiro é como alugar um empilhador para carregar um único saco de compras. Funciona. Mas agora também tem um empilhador.
O custo escondido: a hidratação
Aqui está a parte que costuma ser ignorada. Um site em React não envia apenas HTML. Mesmo com renderização do lado do servidor (Next.js, Remix, ilhas do Astro), o browser recebe o HTML já renderizado e depois descarrega o bundle de JavaScript, re-executa a sua árvore de componentes e volta a ligar os event handlers a um DOM que já existe. Esta segunda passagem chama-se hidratação e é puro custo adicional do ponto de vista do leitor — a página já parecia pronta.
Quanto custa, na prática, a hidratação?
- Bytes. Um runtime base de React mais framework são dezenas a centenas de kilobytes de JavaScript antes de escrever uma única linha sua. Isso é enviado a cada visitante, em cada página, incluindo os que saem em dois segundos.
- Tempo de main-thread. Interpretar e executar JavaScript é muito mais caro por byte do que HTML ou imagens, e bloqueia a main-thread. Num telemóvel Android de gama média — ainda o dispositivo mediano de boa parte da web — isto é a diferença entre uma página interativa de imediato e uma que parece pronta mas ignora os seus toques por um instante.
- Uma segunda fonte de verdade. A mesma UI passa a existir em duplicado: uma vez como markup renderizado no servidor, outra como árvore de componentes. As incoerências entre as duas são toda uma categoria de bug ("erro de hidratação") que simplesmente não pode ocorrer se não houver hidratação.
Numa aplicação, paga-se este custo de bom grado porque se recebe uma UI reativa em troca. Numa página que alguém lê uma só vez, pagou um empilhador para mover um saco de compras.
O que lhe traz o HTML renderizado no servidor + um pouco de JS simples
O nosso próprio site corre em PHP 8.3 em alojamento partilhado da OVH atrás da Cloudflare, com o Cockpit CMS v2 (SQLite) como repositório de conteúdo e sem qualquer build step. As páginas que está a ler são montadas no servidor e enviadas como HTML já feito. Não há framework no cliente. Eis o que esta postura entrega na prática.
1. Desempenho, de graça
O JavaScript mais rápido é aquele que nunca se envia. Uma página renderizada no servidor é interativa no momento em que é pintada, porque estar pintada é estar interativa — os links funcionam, os formulários submetem, as âncoras saltam. Não há lacuna de hidratação, nem um "Time to Interactive" a arrastar-se atrás do "First Contentful Paint". A Cloudflare faz cache do HTML na edge e a maioria dos visitantes nem sequer chega à nossa origem.
2. SEO e crawlers de IA que veem mesmo o seu conteúdo
Os crawlers — o da Google e, cada vez mais, os crawlers de LLM que constroem motores de resposta — recebem um documento completo no primeiro pedido. Sem esperar por JS, sem apostar no orçamento de renderização. O seu conteúdo, os seus dados estruturados, as suas ligações internas estão todos na resposta inicial. Com apps renderizadas no cliente, está a apostar que cada crawler executa o seu JavaScript de forma correta e paciente. Alguns fazem-no. Muitos não, e os que mais importam para a extração de respostas por IA muitas vezes não o fazem.
3. Acessibilidade por omissão
HTML semântico renderizado no servidor — a sério, elementos <button> a sério, <form> a sério com uma ação no servidor — é acessível antes de fazer mais seja o que for. Leitores de ecrã, navegação por teclado e os botões de avançar/recuar do browser funcionam todos porque usou a plataforma em vez de a reimplementar. A maioria das falhas de acessibilidade que auditamos vem de um <div onClick> a fazer de botão, ou de um router de cliente que parte a gestão de foco e o botão recuar. Não se pode partir o que nunca se substituiu.
4. Longevidade e uma superfície de manutenção mínima
Um site sem build, feito de PHP e HTML, quase não tem rotatividade de dependências. Não há node_modules a apodrecer, nem configuração de bundler para migrar, nem versão major de framework a forçar uma reescrita de dois em dois anos. Fazemos deploy a sincronizar ficheiros. Um site construído assim correrá, sem alterações, muito mais tempo do que a meia-vida de qualquer framework JavaScript atual. O código mais barato de manter é o código que não existe.
"Mas eu preciso de interatividade"
Quase de certeza precisa de alguma, e quase de certeza de menos do que uma framework. A esmagadora maioria das necessidades "interativas" num site de conteúdo resolve-se com algumas dezenas de linhas de JavaScript simples ou com a própria plataforma:
- Menu móvel, acordeões, separadores — um pequeno event listener, ou
<details>/<dialog>com zero JS. - Validação de formulários — atributos de validação por restrições do HTML (
required,type="email",pattern) mais uma verificação no servidor. - Algum conteúdo dinâmico — pedir JSON e atualizar uma região. O
fetch()está em todos os browsers há anos. - Melhoria progressiva — renderizar no servidor e depois enriquecer com JS para quem o tem. A página funciona de qualquer forma.
É a mesma disciplina por trás da nossa analítica sem cookies e amiga do RGPD: alguns kilobytes de script que fazem uma única coisa, em vez de um gestor de tags que carrega um megabyte de vigilância de terceiros.
Quando o React (ou uma SPA) É a escolha certa
Seríamos os contrários que criticamos se fingíssemos que o React nunca está certo. Use-o — de bom grado — quando:
- A UI é o produto e tem estado profundo. Editores, painéis com dados ao vivo, ferramentas de design, qualquer coisa com arrastar e largar, sincronização entre painéis ou atualizações otimistas. Este é o terreno natural do React, e é excelente nele.
- Está atrás de um login. Um painel de aplicação autenticado normalmente não precisa de SEO, e o modelo SPA (carregar a casca uma vez e depois falar com uma API) encaixa na perfeição. Usámos exatamente esta forma nas superfícies orientadas por recomendação do produto de bem-estar Jofit.
- Tem uma equipa grande e um design system orientado a componentes. O modelo de componentes e o ecossistema do React compensam genuinamente em escala e com muitos contribuidores.
- Fluxos muito interativos, tipo aplicação — assistentes em vários passos com estado rico no cliente, colaboração em tempo real, qualquer coisa em que ir e voltar ao servidor a cada interação pareceria avariado.
E o meio-termo honesto: se quer mesmo o modelo de componentes do React mas está a construir um site de conteúdo, use uma arquitetura de ilhas (Astro) — envie HTML estático e hidrate apenas os componentes interativos, não a página inteira. É uma forma de princípios de ter as duas coisas.
A versão curta
- A construir um documento (site de conteúdo/marketing)? HTML renderizado no servidor + um pouco de JS simples. Sem React, sem build step. Mais rápido, mais acessível, mais barato, mais duradouro.
- A construir uma aplicação (com estado, atrás de login, tipo app)? O React ou uma framework SPA semelhante é uma escolha boa e muitas vezes correta.
- Quer componentes num site de conteúdo sem o imposto da hidratação? Use ilhas (Astro) e hidrate de forma seletiva.
- A hidratação é a segunda passagem em que o browser volta a correr o seu JS sobre HTML já renderizado para o tornar interativo — puro custo adicional para páginas que as pessoas apenas leem.
O padrão da web devia ser HTML. O React é uma ferramenta poderosa e específica para um trabalho específico. A maioria dos sites não é esse trabalho — e vai entregar algo mais rápido, mais acessível e mais fácil de manter vivo se começar por perguntar se precisa dele de todo. Normalmente, não precisa.