Nginx vs apache: qual é mais rápido no WordPress

Nginx vs apache: a comparação em uma frase

Nginx vs apache é a comparação entre os dois servidores web que respondem por mais de 60% da internet: o Nginx processa requisições de forma assíncrona com workers fixos, enquanto o Apache aloca um processo ou thread por conexão. Em WordPress sob carga, essa diferença arquitetural decide o TTFB, o consumo de RAM e o custo da infraestrutura.

Se você gerencia a stack de hospedagem de projetos WordPress em escala, já viveu isso na prática. O site trava 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 mesma proporção. Boa parte desse problema começa na escolha do servidor web, e é exatamente aqui que a comparação Nginx vs apache deixa de ser teoria e vira decisão de negócio.

Neste artigo, vamos direto ao ponto: 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. Para você antecipar o veredito, a tabela abaixo resume os critérios que mais pesam na decisão.

A leitura rápida da tabela já entrega a direção: o Nginx leva vantagem em escala, concorrência e consumo de memória. Mas o Apache não está fora do jogo, e há cenários em que ele continua sendo a escolha pragmática. Vamos destrinchar cada ponto.

Por que a arquitetura muda o comportamento sob carga?

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 quando o tráfego aperta.

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, o número de processos cresce junto, e a memória do servidor vira o gargalo. Segundo a documentação dos MPMs do Apache, o prefork escala bem em estabilidade, mas paga o preço em RAM por conexão.

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. Por isso o Nginx mantém uso de memória baixo mesmo com alta concorrência, como descreve a documentação oficial do Nginx.

O que isso significa em RAM e conexões simultâneas?

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, na faixa de 150 a 250 conexões antes de saturar, segundo a documentação do projeto. O Nginx sustenta dezenas de milhares de conexões por worker sem o mesmo crescimento de memória, conforme os números publicados em nginx.org.

Traduzindo para o dia a dia: para sustentar mil conexões ociosas, o Apache em prefork pode exigir centenas de megabytes de RAM, porque mantém um processo vivo para cada conexão. O Nginx faz o mesmo trabalho com poucos megabytes por worker. Em pico de campanha, é essa matemática que decide entre segurar o tráfego com a infra atual ou ter que escalar servidor às pressas.

Quem domina o mercado de servidores web hoje?

Essa diferença arquitetural se reflete na adoção. Segundo a pesquisa de participação de servidores web do W3Techs, o Nginx já ultrapassou o Apache em participação entre os sites ativos e mantém liderança consistente. A Netcraft Web Server Survey confirma a tendência de migração de novos projetos para o Nginx, especialmente em ambientes de alto tráfego.

Como cada servidor processa PHP no 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, e é aqui que o TTFB do seu site é decidido.

PHP-FPM e FastCGI: o caminho do Nginx

O Nginx não tem 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, quanta 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. O resultado é uma stack mais previsível, em que cada componente é dimensionado de forma isolada.

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 Apache 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 sob alto tráfego, porque o servidor precisa ler e interpretar esse arquivo em cada diretório do caminho a cada acesso.

Como o FastCGI Cache reduz o TTFB sem depender de plugin?

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. E esse ganho não fica só no servidor: o TTFB é o primeiro tijolo do carregamento da página, como explica o guia de TTFB do web.dev. Um TTFB menor abre espaço para um LCP melhor, e LCP é uma das métricas centrais dos Core Web Vitals. Em outras palavras, a escolha do servidor web tem impacto direto na nota de experiência da página e, por consequência, na conversão. No Apache, o cache de página equivalente exige o mod_cache mais configuração externa, com menos integração nativa. Se você quer entender como essa cadeia afeta o ranqueamento, vale revisar nosso conteúdo sobre Core Web Vitals no WordPress.

Quando o Apache ainda é a escolha certa para WordPress?

A comparação Nginx vs apache não é uma sentença. Existem cenários em que o Apache continua sendo a opção pragmática, e ignorar isso seria desonestidade técnica.

• 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 automaticamente. 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.
• Módulos específicos do Apache: ambientes que dependem de mod_security com regras muito customizadas ou de mod_rewrite com lógica complexa podem exigir trabalho extra de reescrita ao sair do Apache, o que nem sempre compensa.

Para projetos em escala com time técnico dedicado, no entanto, esses pontos pesam menos do que o ganho de performance e de custo de infraestrutura que o Nginx oferece.

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, desde que feito com checklist.

• 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 os redirects 301: redirecionamentos que estavam no .htaccess passam para diretivas return ou rewrite dentro do bloco server. Audite a lista completa antes de migrar para não perder autoridade de SEO no caminho.
• Reaponte os plugins de cache: plugins que gravavam regras no .htaccess precisam ser reconfigurados ou substituídos pela camada de FastCGI Cache do Nginx, para não deixar cache fantasma servindo conteúdo desatualizado.
• Cuide das regras de WooCommerce e multisite: o checkout do WooCommerce e instalações multisite têm padrões de rewrite próprios e são os pontos onde a migração mais costuma quebrar. 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.

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 de desenvolvimento, homologação e produção.

Perguntas frequentes sobre Nginx vs apache

Nginx é sempre mais rápido que o Apache para WordPress?

Não em todos os cenários. Para uma única requisição isolada em servidor ocioso, a diferença é pequena. O Nginx se destaca sob concorrência: quando muitas conexões chegam ao mesmo tempo, o modelo assíncrono dele mantém o TTFB estável enquanto o Apache em prefork consome mais RAM e degrada. Em WordPress de alto tráfego com FastCGI Cache, o Nginx costuma vencer com folga.

Posso usar Nginx e Apache juntos no mesmo servidor?

Sim, e é uma arquitetura comum. Nesse arranjo, o Nginx atua como reverse proxy na frente, servindo arquivos estáticos e cache, e repassa apenas as requisições dinâmicas para o Apache, que executa o PHP. Você combina a eficiência de rede do Nginx com a compatibilidade de .htaccess do Apache, ao custo de uma stack com mais camadas para administrar.

O .htaccess funciona no Nginx?

Não. O Nginx não lê arquivos .htaccess. Toda a configuração fica centralizada no nginx.conf e nos arquivos de virtual host. Isso significa que regras de rewrite, redirects e bloqueios que estavam no .htaccess precisam ser traduzidas para a sintaxe do Nginx durante a migração. A vantagem é que a configuração centralizada elimina a leitura de arquivo por diretório a cada requisição.

Qual servidor consome menos memória em WordPress?

O Nginx, com margem larga sob concorrência. Como ele usa workers fixos em vez de um processo por conexão, o consumo de RAM cresce de forma muito mais lenta conforme o tráfego sobe. Em mil conexões simultâneas, a diferença entre os dois pode ser de centenas de megabytes, o que se traduz diretamente em custo de servidor.

Preciso reescrever todos os plugins ao migrar para Nginx?

Não. Os plugins do WordPress rodam em PHP e independem do servidor web. O que muda são as regras que alguns plugins gravam no .htaccess, principalmente plugins de cache, segurança e redirecionamento. Esses pontos precisam ser reconfigurados na camada do Nginx, mas o código dos plugins permanece intacto.

O Nginx melhora os Core Web Vitals do WordPress?

Indiretamente, sim. O Nginx com FastCGI Cache reduz o TTFB, que é a base do carregamento da página. Um TTFB menor abre espaço para um LCP melhor, e o LCP é uma das métricas centrais dos Core Web Vitals. Não é mágica: imagens pesadas e JavaScript bloqueante continuam pesando. Mas a fundação do servidor web fica mais sólida com o Nginx.

Hospedagens gerenciadas usam Nginx ou Apache?

A maioria das hospedagens WordPress gerenciadas voltadas a performance adota Nginx, geralmente combinado com PHP-FPM e FastCGI Cache, justamente pelo ganho de TTFB e pela economia de RAM em escala. Hospedagens compartilhadas tradicionais ainda usam Apache com frequência, pela compatibilidade com .htaccess e pela autonomia que ela dá aos usuários.

Conclusão

Na comparação Nginx vs apache para WordPress, o veredito é claro em escala: o Nginx entrega TTFB mais baixo, consome menos RAM por conexão e sustenta picos de tráfego sem inflar a infraestrutura, graças ao modelo assíncrono e ao FastCGI Cache embutido. O Apache não está obsoleto e continua pragmático em hospedagem compartilhada, ambientes legados e cenários que dependem fortemente de .htaccess ou de módulos customizados.

A decisão certa depende do seu contexto, mas a direção do mercado é evidente, como mostram os dados do W3Techs e da Netcraft. Para projetos que precisam crescer com previsibilidade de custo e estabilidade em pico, a stack baseada em Nginx é a aposta mais segura.

Aqui na Apiki, nossa hospedagem WordPress gerenciada é construída sobre Nginx, PHP-FPM e FastCGI Cache, com SLA e migração assistida do Apache sem perda de SEO. Se você quer parar de pagar servidor a mais para segurar tráfego que o Nginx resolveria com a infra atual, fale com o nosso time e descubra como migrar com segurança.