O que é
O que faz um site aguentar muitos visitantes ao mesmo tempo não é a nota de PageSpeed: é o cache do servidor. Esta página explica o raciocínio; a comprovação com números está em Teste de carga real.
O que realmente importa
Ferramentas como o PageSpeed são úteis para achar defeitos de construção do site (imagens grandes, scripts pesados, recursos externos). Mas elas não medem quantos acessos simultâneos o servidor suporta, que é o que decide se o site cai ou não sob tráfego.
O fator decisivo é o cache. Sem cache, cada visitante força uma requisição PHP e ao banco de dados para montar a página. Com cache de servidor, o nginx entrega a página pronta, sem PHP nem banco na maioria dos acessos, e a diferença é brutal.
Estimativa de tráfego simultâneo
Em uma VPS pequena (1 vCPU, 1 GB de RAM), numa página pesada feita com page builder:
| Configuração | Visitantes simultâneos | Tempo de resposta |
|---|---|---|
| Sem cache | ~3 a 4 | 5 a 10 segundos |
| Plugin de cache do WordPress | ~15 (varia muito) | 3 a 5 segundos |
| FastCGI (servidor) | ~30 a 50 | menos de 1 segundo |
Num artigo leve (texto e poucas imagens), o FastCGI chega a ~100 visitantes simultâneos na mesma VPS pequena.
O número exato depende do peso da página: uma home com page builder e muitas imagens aguenta menos que um artigo simples. Por isso o teste de carga tem que usar a página real que você quer avaliar. Ver Teste de carga real.
Quantos processos PHP cada site recebe
Cada site tem um limite de processos PHP: é quanto ele consegue atender ao mesmo tempo quando a página não vem do cache. O painel calcula esse limite na criação do site, pela memória do servidor e pelo número de núcleos.
O teto por núcleo existe por um motivo medido: quando a CPU já está no talo, aumentar os processos não entrega mais páginas por segundo. O mesmo site entrega o mesmo número de páginas com 8, 16 ou 37 processos, e o excesso só gasta memória e deixa os outros sites mais lentos.
Isso vale para sites criados a partir da versão 2.35.22. Sites que já existiam continuam com o limite que tinham, porque mudar sozinho o comportamento de um site em produção seria pior do que o ganho.
Se um site específico incomoda os vizinhos, o caminho é o teto de CPU: ele prende o consumo naquele site e mantém os outros rápidos.
