Quando um negócio me pede um site, antes ainda do design há uma escolha que pesa durante anos: site estático, renderização no servidor (SSR) ou CMS? Em vez de a explicar em abstrato, conto-a com o projeto que conheço melhor: este site.
As três opções em duas linhas
- Site estático: as páginas são ficheiros HTML já prontos, gerados uma vez e carregados num alojamento. Rapidíssimo, barato, muito difícil de atacar. Mas cada alteração exige uma nova publicação.
- SSR (server-side rendering): um servidor gera a página a cada pedido, com dados sempre atualizados. Flexível e ótimo para SEO, mas é preciso um servidor sempre ligado e alguém que o mantenha.
- CMS (WordPress ou um CMS headless): o proprietário altera textos e artigos a partir de um painel, sem programador. Prático, mas traz atualizações, plugins e uma superfície de ataque a cuidar.
O meu caso: um site Angular publicado como estático
Este site é uma aplicação Angular com SSR configurado, um backend NestJS separado com MongoDB e um blog em sete idiomas cujos artigos vivem na base de dados. No papel é o caso perfeito para SSR. Na prática, por custo e simplicidade, o frontend é compilado e publicado como ficheiros estáticos num alojamento Plesk, enquanto o backend corre num serviço separado.
Funciona, mas aprendi da pior maneira o que essa escolha implica.
1. Sem servidor, o SSR não existe
Com um deploy estático, a renderização no servidor nunca corre: se uma página não for gerada durante a build, o Google recebe apenas a "casca" vazia da aplicação. Quando dei por isso, dos 32 URLs na sitemap o Google tinha indexado 4, e nenhum artigo: contei toda a investigação neste artigo. A solução foi o prerendering: gerar na build o HTML de cada página, artigo a artigo e idioma a idioma.
2. Centenas de páginas para gerar em cada build
Cada artigo existe em sete idiomas, por isso as páginas a pré-renderizar são centenas. As primeiras builds consultavam a API de produção para cada uma: o limite de pedidos disparava e algumas páginas eram geradas com a mensagem "artigo não encontrado". Resolvi descarregando todos os artigos uma única vez antes da build, para um ficheiro de cache de onde o prerendering lê:
// Before the build: download every published post once
const posts = await fetchAllPublishedPosts();
fs.writeFileSync('.prerender-cache/blog-posts.json', JSON.stringify({ posts }));
// The prerender reads this file instead of calling the API hundreds of times3. Cada artigo novo exige uma nova publicação
É o compromisso mais evidente: quando publico um artigo no painel, o conteúdo fica logo disponível pela API, mas a página HTML que o Google lê só existe depois da build seguinte e do envio dos ficheiros. Para um blog atualizado de vez em quando é aceitável; para um site de notícias não.
4. Os detalhes do alojamento contam
Mesmo com as páginas geradas, o Apache respondia com um redirect 301 em cada uma: cada página pré-renderizada é uma pasta com um index.html lá dentro, e o servidor acrescentava a barra final ao URL. A correção foram poucas linhas no .htaccess, mas sem um teste com curl -I nunca teria reparado:
<IfModule mod_dir.c>
DirectorySlash Off
</IfModule>Precisamente por estes compromissos estou a preparar a passagem para um container Node no Plesk, com SSR verdadeiro: a complexidade já estava no projeto, por isso mais vale aproveitá-la até ao fim.
O que recomendo a um pequeno negócio
O meu site não é um caso típico: é também um laboratório. Para um negócio real, a escolha depende quase sempre de três perguntas: com que frequência mudam os conteúdos, quem os atualiza e quantas páginas são precisas.
| Situação | Escolha recomendada | Porquê |
|---|---|---|
| Restaurante, artesão ou consultório com 5–10 páginas que mudam poucas vezes por ano | Site estático | Rápido, barato, sem servidor para manter |
| Profissional que publica artigos ou novidades sozinho | CMS | Atualiza os conteúdos sem chamar um programador |
| Catálogo com centenas de produtos ou conteúdos que mudam todos os dias | SSR ou plataforma de e-commerce | Páginas sempre atualizadas e indexáveis sem reconstruir o site |
| Área reservada, reservas, dados por utilizador | Web app com páginas públicas estáticas ou SSR | As páginas públicas servem a SEO, a área reservada não |
Para muitos negócios locais, horários, avaliações e indicações contam mais do que o próprio site: um Perfil da Empresa no Google bem cuidado vale muitas vezes mais do que uma funcionalidade extra.
As perguntas a fazer antes de escolher
- Quem vai atualizar os conteúdos, e com que frequência? Se a resposta for "o proprietário, todas as semanas", é preciso um painel.
- Quanto conta o Google? Se o site vive de pesquisas orgânicas, cada página tem de chegar ao crawler como HTML completo: estático ou SSR, nunca uma single page app sem prerendering.
- Quem vai manter o servidor? Um SSR ou um CMS sem atualizações envelhece mal; um site estático pode ficar parado durante anos.
- Quanto pode crescer? Começar estático e passar para SSR é possível, desde que se escolha uma arquitetura que o permita, como me aconteceu com Angular.
Os erros que vejo com mais frequência
- Um CMS pesado para cinco páginas que nunca mudam: plugins para atualizar e riscos de segurança sem qualquer vantagem.
- Uma single page app sem prerendering para um site que tem de ser encontrado: agradável de usar, invisível para os motores de pesquisa.
- Escolher SSR sem orçamento para o manter: um servidor tem de ser monitorizado, atualizado e pago todos os meses.
Em resumo
Não existe a melhor tecnologia em absoluto: existe a que se adequa à forma como os conteúdos são atualizados e a quem os gere. Para a maioria dos pequenos negócios, um site estático bem feito é a escolha mais sólida; um CMS faz sentido quando o proprietário quer autonomia; o SSR serve quando os conteúdos são muitos e mudam com frequência. O meu site ensinou-me que cada escolha tem um custo escondido: o importante é conhecê-lo antes. Se estás a avaliar um projeto, escreve-me e partimos destas perguntas.