Escalar WordPress: 10 mil utilizadores por hora 2026

Todo dono de site sonha em tornar-se “viral”. Mas para um administrador de servidor, este momento muitas vezes torna-se um pesadelo. O site começa a carregar em 30 segundos, e os utilizadores veem apenas “Error 500” ou “503 Service Unavailable”.

Neste artigo, vou mostrar como preparar o WordPress para Alto Tráfego (High Traffic).

#1. A matemática do desastre: Limite de PHP workers

A maioria das falhas do WordPress não se deve à falta de RAM ou CPU, mas ao esgotamento do limite de PHP Workers.

#O que é um PHP worker?

Imaginé um PHP Worker como um caixa de supermercado.

• Se tem 10 caixas (10 workers).
• Cada cliente precisa de 1 segundo para ser atendido.
• Pode atender no máximo 10 clientes por segundo.

Se o 11º cliente chegar, tem de esperar na fila. Se a fila encher -> Erro 503.

#2. Nível 1: Full page cache (fpc) – Evitar o PHP

O PHP mais rápido é aquele que não é executado.

Se a sua página é estática (ex: um artigo de blog), não faz sentido o PHP gera-la do zero. Deve servir um ficheiro HTML pronto.

#Soluções:

1. Plugins: WP Rocket, W3 Total Cache.
2. Server-Side Cache (Pro):
   • Varnish: Um servidor proxy que mantém a página inteira na RAM.
   • Nginx FastCGI Cache: Embutido no Nginx.
   • Cloudflare: Servir a página antes de o tráfego chegar ao seu alojamento.

#3. Nível 2: Object cache (Redis) – Aliviar a base de dados

E lojas WooCommerce? Aí o PHP tem de trabalhar.

Redis (Object Cache) armazena os resultados de consultas à base de dados na RAM. Em vez de perguntar ao MySQL (disco lento), o PHP pergunta ao Redis (RAM rápida).

• Sem Redis: 150 consultas SQL por visualização.
• Com Redis: 5 consultas SQL por visualização.

#4. Estudo de caso: Análise de falha

Projeto: Portal de notícias na Black Friday. Servidor morreu em 3 minutos.

#O que correu mal?

1. Ajax Assassino: Um plugin de “Contador de Visitas” enviava um pedido AJAX (admin-ajax.php) a cada visita.
2. Sem Índices na DB: ORDER BY RAND() matou o MySQL.

#A solução

1. Ajax desativado (usado Google Analytics).
2. Redis implementado.
3. Varnish configurado.

#5. Como monitorizar?

1. Query Monitor: Plugin para análise SQL.
2. New Relic: Monitorização APM avançada.
3. Logs: tail -f no SSH.

#Resumo

1. Alojamento: Cloud VPS com PHP Workers configuráveis.
2. Cache: Varnish ou Nginx FastCGI.
3. Base de Dados: Redis.
4. Limpeza: Sem admin-ajax no frontend.