WordPress vs HTML estático: segurança, desempenho e tráfego
A comparação entre WordPress e HTML estático deve considerar três dimensões: segurança, desempenho e capacidade para suportar tráfego elevado.
Há uma vantagem estrutural do HTML estático que é frequentemente subestimada: não só elimina grande parte dos pontos de entrada explorados nos ataques a WordPress, como também permite servir muito mais pedidos com os mesmos recursos de CPU e memória.
Isto é especialmente relevante para sites institucionais, jornais, revistas e outros sites com milhares de páginas, mas em que a esmagadora maioria dos visitantes apenas consulta informação.
1. Porque é que o HTML estático é mais resistente?
Num WordPress tradicional, um pedido pode desencadear código PHP, consultas MySQL, carregamento de plugins e geração de HTML. Num site estático, o servidor pode limitar-se a entregar um ficheiro já produzido.
WordPress sem cache
HTML estático
Sem PHP nem consultas SQL por pedido.
É importante ressalvar que um WordPress com cache de página completa e CDN pode servir os visitantes quase como um site estático. A maior diferença aparece nos pedidos que não podem ser satisfeitos pela cache.
2. Os números mais recentes sobre segurança WordPress
O relatório State of WordPress Security in 2026, da Patchstack, apresenta números particularmente relevantes.
Fonte: Patchstack — State of WordPress Security in 2026.
O problema não é apenas a existência de vulnerabilidades: algumas são exploradas rapidamente e outras continuam a ser atacadas anos depois da divulgação. A Wordfence registou, em 2024, na sua rede de proteção:
| Categoria | Pedidos bloqueados |
|---|---|
| Pedidos maliciosos | 54 mil milhões |
| Ataques a passwords | 55 mil milhões |
| Tentativas de XSS | 9 mil milhões |
| Tentativas de SQL Injection | 1,1 mil milhões |
| Procura de ficheiros de configuração e diagnóstico | 5,5 mil milhões |
As categorias específicas podem sobrepor-se aos totais; não devem ser somadas novamente. Fonte: Wordfence — relatório de segurança de 2024.
3. Quantos sites são efetivamente comprometidos?
Dois indicadores adicionais ajudam a dimensionar o problema:
- A Wordfence identificou perto de um milhão de sites distintos infetados em 2024, no universo observado pelos seus serviços.
- A Sucuri identificou 1 176 701 sites infetados nas suas 70,8 milhões de análises remotas em 2024 — uma taxa de deteção de infeções de 1,66%.
A Sucuri abrange WordPress, outros CMS e sites personalizados. Estes números não permitem concluir qual é a taxa de compromisso de um site WordPress comparada com a de um site HTML estático — e são amostras de serviços de segurança, não amostras aleatórias de toda a Internet.
O que podemos afirmar com segurança é que um site HTML verdadeiramente estático não é vulnerável às falhas de execução PHP, autenticação e plugins do WordPress, porque não utiliza esses componentes. Continua, porém, vulnerável a ataques ao servidor, às credenciais de publicação e à cadeia de fornecimento.
4. Desempenho: um teste com resultados muito expressivos
Existe um benchmark público que compara ficheiros estáticos com páginas WordPress dinâmicas, usando os mesmos tipos de servidores web. Com Nginx, o ficheiro estático serviu 488× mais pedidos por segundo do que o WordPress sem cache.
Benchmark independente, 2 threads e 10 ligações concorrentes; testes com páginas diferentes, não equivalência funcional. Fonte: WordPress Web Server Benchmark Suite (GitHub).
Este é um resultado de laboratório, não uma garantia de que qualquer site HTML suporta 488 vezes mais utilizadores. A dimensão da resposta, as condições do servidor, a cache e os recursos de cada página influenciam muito o resultado.
O próprio benchmark mostra que um WordPress com cache completa pode aproximar-se bastante do desempenho de ficheiros estáticos:
| Configuração | Pedidos/s |
|---|---|
| HTML estático, OpenLiteSpeed | 8 809 |
| WordPress com LSCache, OpenLiteSpeed | 4 917 |
| HTML estático, Nginx | 4 125 |
| WordPress com FastCGI Cache, Nginx | 2 873 |
Segunda bateria de testes do mesmo projeto, com 20 clientes concorrentes.
A conclusão é importante: a grande vantagem de desempenho resulta sobretudo de evitar processamento dinâmico por pedido, e não apenas da extensão .html.
5. Os sites HTML também são habitualmente mais leves?
Sim, particularmente quando são desenvolvidos com HTML, CSS e JavaScript simples, sem bibliotecas desnecessárias. Convém separar dois conceitos:
| Característica | WordPress típico | HTML estático otimizado |
|---|---|---|
| Código executado no servidor | PHP e frequentemente SQL | Nenhum por pedido |
| Memória necessária para gerar páginas | PHP workers, cache, BD | Muito reduzida |
| JavaScript no navegador | Depende do tema/plugins | Pode ser mínimo |
| Tamanho da página | Pode ser elevado | Pode ser muito reduzido |
| Cache em CDN | Possível | Particularmente simples |
| Escalabilidade horizontal | Requer gerir componentes dinâmicos | Replicação de ficheiros |
| Consumo sob tráfego elevado | Pode aumentar muito sem cache | Geralmente mais previsível |
Um WordPress bem otimizado pode produzir páginas mais leves do que um HTML mal construído. Portanto, o ganho deve ser medido pelo peso total transferido, pelo JavaScript executado e pelo trabalho realizado no servidor.
Por exemplo, se uma página transferir 500 KB em vez de 2 MB, consome quatro vezes menos largura de banda por visualização, admitindo as mesmas condições de cache e transferência. Isso permite servir quatro vezes mais visualizações com o mesmo limite de tráfego, se a largura de banda for o fator limitante.
6. O que isto significa na prática
Para uma infraestrutura que aloja muitos sites institucionais, a publicação estática oferece vantagens cumulativas:
- Menos processos PHP e menos ligações MySQL
- Menor consumo de RAM e CPU
- Menos atualizações de segurança e incompatibilidades
- Menos pontos de entrada para malware
- Maior capacidade para absorver picos de tráfego
- Backups e migrações mais simples
- Possibilidade de servir milhares de páginas através de Nginx e CDN, sem base de dados pública
Há também uma vantagem comercial: o cliente pode ter um backoffice de edição sem que o site público dependa desse backoffice. O sistema gera ou publica os ficheiros HTML quando o conteúdo muda — é exatamente o que entregamos no nosso serviço de conversão de WordPress para HTML.
Conclusão
A evidência permite sustentar três afirmações fortes:
- Segurança: o HTML estático elimina as vulnerabilidades próprias do WordPress e dos seus plugins, que representaram milhares de falhas divulgadas em 2025. Não elimina os ataques à infraestrutura.
- Desempenho: servir HTML pré-gerado pode ser dezenas ou centenas de vezes mais eficiente do que gerar WordPress dinamicamente sem cache. Com cache completa, a diferença pode ser muito menor.
- Capacidade: sites estáticos, sobretudo quando também são mais leves, conseguem normalmente suportar várias vezes mais pedidos com os mesmos recursos. O multiplicador depende da configuração e do tipo de tráfego.
Não afirmamos que HTML sofre «99% menos ataques» — os dados não sustentam essa precisão. Em contrapartida, é defensável escrever:
Um site HTML estático elimina as vulnerabilidades associadas ao núcleo, plugins e temas PHP do WordPress, reduz substancialmente a superfície de ataque e, quando bem otimizado, permite servir muito mais visitantes com os mesmos recursos. Em testes publicados, a diferença face ao WordPress sem cache chegou a centenas de vezes mais pedidos por segundo.
O próximo passo do nosso lado é um benchmark próprio: um dos nossos sites WordPress e a respetiva versão HTML, no mesmo VPS, com Nginx e testes a 10, 50, 100 e 500 utilizadores concorrentes — números nossos, diretamente utilizáveis.
Se quer saber como ficaria o seu site convertido, veja o serviço de WordPress → HTML com backoffice ou peça uma análise gratuita.