Nginx vs Apache: a diferença que importa em WordPress

Nginx vs Apache é a comparação entre dois servidores web que dominam mais de 60% da internet, sendo o Nginx baseado em arquitetura orientada a eventos (não-bloqueante) e o Apache em modelo processo-por-conexão. Em WordPress sob carga, essa diferença arquitetural impacta diretamente o TTFB, o consumo de memória e a capacidade de lidar com requisições simultâneas.
Se você gerencia a stack de hospedagem de projetos WordPress em escala, já sentiu essa dor na prática. O site fica lento no pico de uma campanha. A TI interna sugere subir mais um servidor. O custo cresce, mas o tempo de resposta não melhora na proporção esperada. Boa parte desse problema começa na escolha do servidor web, e é exatamente aí que a comparação Nginx vs Apache deixa de ser teoria e vira decisão de negócio.
Neste artigo, vamos direto ao que interessa: como cada servidor se comporta servindo WordPress, quando o Apache ainda faz sentido, e como migrar para o Nginx sem quebrar permalinks, redirects e regras de plugins.
Por que a arquitetura de cada servidor muda o jogo?
A diferença entre Nginx e Apache não está em recursos isolados, mas no modelo de processamento de cada um. Esse é o ponto que define como eles reagem sob carga.
Modelo orientado a eventos vs processo por conexão
O Apache, no modo prefork (o mais comum em hospedagem PHP), cria um processo dedicado para cada conexão. Cada processo consome memória, mesmo quando está ocioso aguardando dados. Quando o tráfego cresce, a quantidade de processos cresce junto, e a memória do servidor vira o gargalo.
O Nginx funciona de forma diferente. Ele usa um número fixo de workers que processam milhares de conexões de forma assíncrona, sem bloquear. Um worker não fica parado esperando uma resposta lenta: ele segue atendendo outras requisições enquanto a primeira é processada. Esse é o motivo pelo qual o Nginx mantém uso de memória baixo mesmo com alta concorrência.
O que isso significa em concorrência real?
Em um cenário de tráfego alto, a diferença aparece no consumo de RAM e na estabilidade. Um servidor Apache em prefork começa a degradar quando passa de algumas centenas de conexões simultâneas por instância. O Nginx sustenta dezenas de milhares de conexões por worker sem o mesmo crescimento de memória.
Essa diferença arquitetural se reflete na adoção. Segundo os dados do W3Techs sobre uso de servidores web, o Nginx já ultrapassou o Apache em participação entre os sites ativos, mantendo liderança consistente nos últimos anos. A Netcraft Web Server Survey confirma a tendência de migração de novos projetos para o Nginx.
Como Nginx e Apache se comportam servindo WordPress?
Em WordPress, o servidor web não executa o PHP sozinho. Ele precisa repassar as requisições dinâmicas para um interpretador. É nesse ponto que as duas abordagens divergem.
PHP-FPM e FastCGI: o caminho do Nginx
O Nginx não tem um módulo PHP embutido. Ele encaminha as requisições dinâmicas para o PHP-FPM via protocolo FastCGI. O PHP-FPM gerencia um pool de processos PHP de forma independente, o que dá controle fino sobre quantos processos rodam, quanto de memória cada um usa e como eles escalam.
Esse desacoplamento é uma vantagem prática. Você ajusta o pool do PHP-FPM sem mexer no servidor web, e o Nginx continua servindo arquivos estáticos (imagens, CSS, JS) sem nem tocar no PHP. Para entender melhor a integração, vale consultar a documentação oficial do Nginx.
mod_php e .htaccess: o caminho histórico do Apache
Por anos, o Apache serviu WordPress via mod_php, com o PHP carregado dentro do próprio processo do servidor. Era simples de configurar, mas tinha custo: cada processo Apache carregava o PHP inteiro na memória, inclusive para servir um arquivo estático.
Hoje o projeto Apache HTTP Server também suporta PHP-FPM via proxy, o que reduz essa ineficiência. Mas a marca registrada do Apache continua sendo o .htaccess, o arquivo de configuração descentralizado lido a cada requisição. É flexível e familiar para quem trabalha com hospedagem compartilhada, porém adiciona overhead em alto tráfego.
Cache de página: por que o Nginx ganha em alto tráfego?
Em sites de alto volume, o segredo da performance é não chamar o PHP quando não é necessário. O Nginx tem o FastCGI Cache embutido, capaz de armazenar a resposta HTML gerada pelo WordPress e servi-la diretamente, sem acionar o PHP-FPM nem o banco de dados.
O resultado é um TTFB baixo e previsível mesmo sob pico de audiência. No Apache, o cache de página equivalente exige o mod_cache mais configuração externa, com menos integração nativa. Essa diferença é determinante para quem precisa segurar campanhas de tráfego sem inflar a infraestrutura.
Quando o Apache ainda faz sentido em WordPress?
A comparação Nginx vs Apache não é uma sentença. Existem cenários em que o Apache continua sendo a escolha pragmática:
- Hospedagem compartilhada: a maioria dos planos compartilhados é construída sobre Apache, justamente porque o .htaccess permite que cada usuário configure regras sem acesso ao servidor inteiro.
- Ambientes legados: projetos antigos com dezenas de regras .htaccess acumuladas e plugins que escrevem nesse arquivo automaticamente podem migrar com risco maior do que benefício imediato.
- Plugins que dependem de .htaccess: alguns plugins de cache, segurança e redirecionamento geram regras .htaccess. Em Apache, isso funciona sem intervenção manual.
- Equipes sem acesso a SysAdmin: quando não há quem cuide de configuração centralizada, a autonomia do .htaccess reduz a dependência de um administrador de sistemas.
Para projetos em escala com time técnico dedicado, no entanto, esses pontos pesam menos do que o ganho de performance e custo do Nginx.
Nginx vs Apache: comparação direta
A tabela abaixo resume os critérios que mais influenciam a decisão de stack para WordPress.
| Critério | Nginx | Apache |
|---|---|---|
| Arquitetura de processamento | Orientada a eventos (assíncrona) | Processo/thread por conexão (prefork, worker, event MPM) |
| Conexões simultâneas (típico) | 10.000+ por worker com baixo uso de RAM | ~150-250 por instância em prefork antes de degradar |
| Configuração | Centralizada (nginx.conf + sites-available) | Descentralizada (.htaccess por diretório) |
| Integração com PHP | PHP-FPM via FastCGI (padrão) | mod_php (legado) ou PHP-FPM via proxy |
| Cache de página nativo | FastCGI Cache embutido | Requer mod_cache + configuração externa |
| Reverse proxy | Função de origem do projeto, altamente otimizada | Suportado via mod_proxy, menos performático |
| Carregamento de módulos | Estáticos ou dinâmicos (a partir do 1.9.11) | Dinâmico em tempo de execução |
| Participação de mercado (W3Techs) | ~33% dos sites ativos | ~28% dos sites ativos |
Como migrar de Apache para Nginx sem quebrar o WordPress?
A migração assusta porque o Nginx não interpreta .htaccess. Tudo que estava nesse arquivo precisa ser traduzido para blocos de configuração do Nginx. Na prática, o roteiro é menos complicado do que parece.
- Converta as regras de rewrite: o bloco de permalinks do WordPress vira uma diretiva location simples no Nginx, com try_files apontando para o index.php. É uma regra padrão, documentada e estável.
- Traduza redirects 301: redirecionamentos que estavam no .htaccess passam para diretivas return ou rewrite dentro do bloco server. Vale auditar a lista antes de migrar para não perder autoridade de SEO.
- Cuide das regras de WooCommerce e multisite: lojas WooCommerce e instalações multisite têm padrões de rewrite próprios. Use as configurações de referência para esses casos em vez de reescrever do zero.
- Valide o resultado: depois da migração, teste permalinks, checkout, painel admin e meça o TTFB e o LCP. Esses números devem melhorar, não piorar. Para entender o impacto em performance percebida, vale revisar nosso conteúdo sobre Core Web Vitals no WordPress.
Outra tendência que reforça o uso do Nginx é a padronização de ambientes com containers. O Docker tornou comum a stack Linux, Nginx, MySQL ou MariaDB e PHP-FPM, com configuração versionada e replicável entre ambientes.
Perguntas frequentes sobre Nginx vs Apache
Nginx é mais rápido que Apache em todos os cenários?
Não. Para servir arquivos estáticos e sustentar muitas conexões simultâneas com baixo uso de memória, o Nginx leva vantagem clara. Em cenários de baixo tráfego com aplicações que dependem de .htaccess, a diferença prática pode ser pequena. O ganho do Nginx aparece principalmente sob concorrência e com cache de página ativo.
É possível usar Nginx e Apache juntos no mesmo servidor?
Sim, e é uma arquitetura comum. O Nginx atua como reverse proxy na frente, servindo estáticos e cache, e repassa as requisições dinâmicas para o Apache rodando atrás. Assim você aproveita a performance do Nginx e mantém a compatibilidade com .htaccess do Apache, embora isso aumente a complexidade da stack.
O Nginx suporta .htaccess?
Não. O Nginx não lê nem interpreta arquivos .htaccess. Toda a configuração fica centralizada nos blocos server e location do arquivo nginx.conf. Essa centralização é uma das razões da performance: o Nginx não verifica o sistema de arquivos em busca de regras a cada requisição.
Qual servidor consome menos memória em WordPress?
O Nginx, na maioria dos casos. Por não criar um processo por conexão e não carregar o PHP dentro do próprio servidor, ele mantém o consumo de RAM mais baixo e previsível sob carga. Isso permite atender mais tráfego no mesmo hardware, reduzindo custo de infraestrutura.
O Nginx é melhor para WooCommerce?
Para lojas WooCommerce com tráfego relevante, sim. WooCommerce gera muitas requisições dinâmicas e páginas que não podem ser totalmente cacheadas, como carrinho e checkout. O modelo do Nginx com PHP-FPM e cache seletivo de páginas estáticas oferece melhor estabilidade nesses picos do que o Apache em prefork.
Preciso recompilar o Nginx para adicionar módulos?
Não necessariamente. Versões a partir do Nginx 1.9.11 suportam módulos dinâmicos, que podem ser carregados sem recompilar o core. Módulos mais antigos ainda exigiam compilação estática, o que gerava a percepção de que o Nginx era menos flexível que o Apache nesse aspecto.
Hospedagens WordPress gerenciadas usam Nginx ou Apache?
A maioria das hospedagens WordPress gerenciadas modernas usa Nginx, frequentemente com FastCGI Cache e PHP-FPM já configurados. O objetivo é entregar performance previsível sem que o cliente precise ajustar servidor. Aqui na Apiki, migramos toda a base do WP Host para Nginx justamente por esse ganho de desempenho e custo.
Conclusão
A decisão Nginx vs Apache em WordPress não é sobre qual servidor é melhor no papel, e sim sobre qual se comporta melhor no seu cenário real de carga, cache e concorrência. Para projetos pequenos e legados em hospedagem compartilhada, o Apache e seu .htaccess continuam práticos. Para WordPress em escala, com campanhas, picos de tráfego e WooCommerce, o Nginx entrega TTFB mais baixo, menor consumo de memória e custo de infraestrutura mais previsível.
O ponto que separa uma migração tranquila de uma cheia de problemas é ter a stack já pensada para WordPress: PHP-FPM ajustado, FastCGI Cache configurado e regras de rewrite testadas. Aqui na Apiki, padronizamos o Nginx em todo o WP Host, nossa hospedagem WordPress gerenciada, com ambiente pré-otimizado para que seu time não precise reinventar configuração de servidor a cada projeto. Se a sua dor é site lento sob carga e dependência da TI interna, vale conversar com o nosso time sobre a stack ideal para a sua operação.