Site em Google App Engine ou WordPress: o que muda no custo, na manutenção e no que quebra
Não é comparação de recursos. É comparação do que vai dar trabalho depois — com medição de onze sites que rodam nessa estrutura.
A comparação entre WordPress e site estático costuma ser feita no terreno errado — o de recursos. Os dois publicam texto, os dois têm formulário, os dois aparecem no Google. A diferença aparece depois, em três lugares: no que exige manutenção, no que pode ser invadido e no que acontece quando ninguém olha por seis meses.
O que o WordPress resolve bem
- O cliente publica sozinho. Para quem escreve toda semana, isso não tem substituto.
- Existe plugin para quase tudo. Loja, agendamento, área de membros — sem escrever código.
- É fácil achar quem mexa. Se o fornecedor sumir, o próximo encontra o caminho.
O que ele cobra em troca
- Superfície de ataque. São três camadas atualizáveis — núcleo, tema e cada plugin — e a invasão quase nunca vem pelo núcleo.
- Atualização que quebra. Plugin abandonado é dívida com data de vencimento desconhecida.
- Peso. Um tema comercial genérico carrega recursos de dezenas de funcionalidades que aquele site não usa.
- Custo contínuo real. Hospedagem que aguente PHP, mais backup, mais quem atualize.
O que muda num site estático
Site estático é HTML pronto no servidor. Não há banco de dados, não há linguagem executando a cada visita, não há painel para invadir. Em compensação, o cliente não edita sozinho: toda mudança passa por um processo de publicação.
É uma troca honesta, e ela decide o caso. Se o cliente precisa publicar três textos por semana por conta própria, estático é a escolha errada — e dizemos isso antes de fechar.
A medição: onde o tempo realmente vai
Mantemos onze sites de clientes em App Engine. Em 07/09/2026 medimos oito deles a partir de Florianópolis, em conexão doméstica, três amostras cada, decompondo o tempo até o primeiro byte:
| Etapa | Mediana | O que é |
|---|---|---|
| DNS | 5–7 ms | Descobrir o endereço IP do domínio |
| Conexão TCP | ~20 ms | Abrir a conexão com o servidor |
| Handshake TLS | ~283 ms | Negociar o certificado e a criptografia |
| Resposta do servidor | 147 ms | O servidor produzir e começar a enviar o HTML |
| Total | 468 ms | Até o HTML completo chegar |
O número que importa nessa tabela é o terceiro. O handshake TLS custa quase o dobro da resposta do servidor. Numa primeira visita a um site estático, o gargalo não é o servidor — é abrir a conexão.
Isso tem uma consequência incômoda para o debate de hospedagem: acima de um certo patamar, trocar de servidor melhora a menor parte da conta. O que sobra de ganho real está em não fazer o navegador abrir conexão com mais domínios do que o necessário, e em não pedir arquivo que não precisa existir. Um site que puxa fonte externa, biblioteca de terceiros e três scripts de rastreamento paga esse pedágio de ~283 ms várias vezes.
Custo
Em App Engine, um handler de arquivo estático é servido sem acordar instância nenhuma. Na prática, um site institucional estático quase não consome hora de instância — a conta fica dominada por tráfego e armazenamento, não por processamento.
A camada gratuita do ambiente padrão cobre, no momento em que este texto foi escrito, 28 horas de instância por dia na classe F e 1 GiB de tráfego e armazenamento. Preço de nuvem muda: confira a tabela vigente antes de fazer conta.
Como decidir
| Se o seu caso é... | A escolha costuma ser |
|---|---|
| Publicar conteúdo com frequência, sem depender de ninguém | WordPress |
| Loja com estoque, variação e pagamento | WordPress ou plataforma de e-commerce |
| Site institucional que muda poucas vezes por ano | Estático |
| Área regulamentada, com exigência de dado correto na página | Estático — menos peça móvel, menos chance de sumir |
| Equipe interna de marketing que edita direto | WordPress |
| Nenhuma equipe e nenhum interesse em manter servidor | Estático |
Veja também: como desenvolvemos os sites e os demais artigos.