Um site WordPress sem caching assemelha-se a um motor que aquece de raiz em cada semáforo. Um visitante acede a uma página, o PHP monta-a do zero, consultando a base de dados 30 a 60 vezes. Dez visitantes em simultâneo significam trezentas consultas. Cinquenta visitantes criam uma avalanche que faz o servidor largar ligações mais depressa do que consegue terminar de escrever um comando na consola.

O problema não é o WordPress em si. A montagem dinâmica de páginas é inerentemente ineficiente por defeito; quase todos os CMS funcionam assim. A solução está comprovada por anos de operação em projetos de alta carga: caching de objetos em RAM via Memcached. Uma camada Memcached devidamente configurada transforma um servidor que engasga com cinquenta utilizadores simultâneos numa máquina que lida com centenas sem um único milissegundo de hesitação no tempo de resposta.

Vamos percorrer o ciclo completo de configuração: da instalação do daemon a um teste de carga que mostra a diferença em números. Todos os comandos foram testados no Ubuntu 22.04/24.04 e AlmaLinux 9, e são compatíveis com PHP 8.2-8.5.

💡 Visão geral rápida:

• Instalar o daemon Memcached e vinculá-lo ao localhost por segurança
• Compilar a extensão PHP memcached via PECL para a sua versão do PHP
• Colocar o drop-in object-cache.php da Automattic no diretório wp-content
• Instalar o Batcache e configurar o advanced-cache.php para caching de páginas
• Verificar os cabeçalhos de resposta através das DevTools do navegador
• Executar um teste de carga com k6 e comparar os resultados antes e depois

O que é o Memcached e porque é que o seu WordPress precisa dele

O Memcached é um daemon que armazena dados e objetos na RAM do servidor. Ao contrário do caching baseado em ficheiros (WP Super Cache, W3 Total Cache, WP Rocket), que escreve HTML pronto em disco, o Memcached opera um nível abaixo: resultados de consultas à base de dados, menus montados, widgets e definições do site residem na RAM e podem ser recuperados em microssegundos sem remontagem.

Na prática, o cenário é este. Uma página típica do WordPress sem caching faz 30 a 60 consultas ao MySQL. Com 50 visitantes simultâneos, a base de dados recebe entre mil e quinhentas a três mil consultas, e o CPU entra em modo de falha. O Memcached interceta a esmagadora maioria destas consultas ao nível da RAM: a base de dados descansa, o CPU fica livre e o servidor responde instantaneamente.

Tecnicamente, o Memcached opera com pares chave-valor. A chave é um hash da consulta SQL; o valor é o resultado serializado. Quando o WordPress monta a mesma página novamente, pergunta primeiro ao Memcached: «Tens esta chave?» e quase sempre recebe uma resposta pronta sem um único acesso a disco.

A tecnologia surgiu em 2003 no LiveJournal como solução para problemas extremos de carga na base de dados. Hoje, o WordPress.com, a Wikipedia, o Twitter e milhares de projetos de alta carga funcionam com Memcached. É maduro, estável e previsível: exatamente o que a produção precisa.

Instalar o daemon Memcached

Vamos cobrir dois cenários principais: Ubuntu (22.04/24.04) com apt e AlmaLinux / Rocky Linux 9 com dnf. Adapte os comandos à sua distribuição.

No Ubuntu:

1
sudo apt update && sudo apt install memcached libmemcached-tools -y

No AlmaLinux / Rocky Linux 9:

1
sudo dnf install memcached libmemcached -y

Após a instalação, o daemon inicia automaticamente. Verifique:

1
systemctl status memcached

Por defeito, o Memcached escuta na porta 11211 em todas as interfaces de rede. Isto é uma falha de segurança: a sua cache fica acessível a qualquer pessoa que consiga alcançar essa porta do exterior. Portanto, vincule primeiro o daemon ao localhost.

Abra o ficheiro de configuração (/etc/memcached.conf no Ubuntu, /etc/sysconfig/memcached no AlmaLinux) e assegure-se de que a linha -l 127.0.0.1 está presente e não comentada. Reinicie o daemon:

1
sudo systemctl restart memcached

Compilar a extensão PHP via PECL

O daemon por si só não acelera o WordPress; precisa de um cliente PHP que ensine o PHP a comunicar com o Memcached. Instale a extensão memcached (nota: especificamente memcached com a letra d, não memcache). Esta última foi removida do PHP a partir da versão 8.0 e não deve ser usada.

No Ubuntu, instale primeiro as ferramentas de compilação. Substitua pela sua versão do PHP: php8.4-dev, php8.3-dev ou php8.2-dev:

1
sudo apt install php8.4-dev php-pear libmemcached-dev pkg-config make gcc -y

Em seguida, compile a extensão:

1
sudo pecl install memcached

No AlmaLinux / Rocky Linux 9, o conjunto é semelhante:

1
sudo dnf install php-devel php-pear libmemcached-devel make gcc -y
2
sudo pecl install memcached

Após a compilação, a extensão tem de ser registada no PHP. Crie um ficheiro INI:

1
echo "extension=memcached.so" | sudo tee /etc/php/8.4/mods-available/memcached.ini
2
sudo phpenmod memcached

No AlmaLinux, o caminho será diferente: /etc/php.d/memcached.ini.

Se estiver a trabalhar no Plesk Obsidian, o comando para recarregar os handlers do PHP após instalar a extensão:

1
plesk bin php_handler --reread

Verifique se a extensão foi carregada:

1
php -m | grep memcached

A saída deve conter memcached. Se estiver vazia, verifique o caminho do ficheiro INI e reinicie o PHP-FPM: sudo systemctl restart php8.4-fpm.

Ligar o WordPress ao Memcached

O daemon está instalado; a extensão PHP está carregada. Agora precisa de ligar o WordPress ao Memcached ao nível da aplicação.

O padrão de facto atualmente é o drop-in oficial da Automattic: wp-memcached no GitHub. Foi escrito pelos mesmos programadores que mantêm o Batcache e o WordPress.com, e funciona corretamente com PHP 8.x (incluindo 8.4 e 8.5).

Copie o ficheiro object-cache.php do repositório para a pasta /wp-content/ do seu site. O WordPress irá detetá-lo automaticamente e começar a usar o Memcached como backend da cache de objetos, sem plugins adicionais.

Se a porta do Memcached for diferente da predefinida (11211), adicione o seguinte ao wp-config.php:

1
$memcached_servers = array(
2
    array( '127.0.0.1', 11211 )
3
);

Cache de páginas: Batcache

A cache de objetos é metade do trabalho. A outra metade é fazer cache das páginas HTML prontas, para que o PHP nem sequer seja executado para visitantes anónimos. É aqui que entra o Batcache, um plugin da Automattic que armazena as páginas geradas no mesmo Memcached.

O princípio é simples. Um visitante chega ao site; o Batcache verifica se existe uma cópia HTML pronta desta página no Memcached. Se existir e não tiver expirado, serve-a instantaneamente, ignorando toda a cadeia PHP e MySQL. Se não existir, ou se o visitante tiver sessão iniciada, a página é gerada de novo e simultaneamente guardada na cache para visitas subsequentes.

Instalação:

Faça o download do arquivo em wordpress.org, extraia-o e envie o ficheiro advanced-cache.php para a raiz de /wp-content/. Em seguida, abra o wp-config.php e adicione a linha que ativa a cache:

1
define( 'WP_CACHE', true );

Envie o ficheiro batcache.php para /wp-content/plugins/ e ative o plugin no painel de administração.

Dentro do advanced-cache.php, existem cerca de uma dúzia de configurações sob comentários. As mais úteis: max_age (tempo de vida da página em segundos, predefinição 300 ou 5 minutos), seconds (intervalo entre regenerações do mesmo URL) e unique (não fazer cache de diferentes User-Agents separadamente). Para a maioria dos sites, os valores predefinidos funcionam; ajuste-os apenas quando compreender o motivo.

Uma nuance importante: certifique-se de que define( 'WP_CACHE', true ) aparece ANTES da linha require_once ABSPATH . 'wp-settings.php' no wp-config.php. Se for colocado depois, a cache não será ativada e o WordPress irá ignorá-lo silenciosamente.

Vídeo: instalação e configuração do início ao fim

A teoria é a base, mas os comandos de consola veem-se melhor uma vez. Este vídeo cobre o ciclo completo de configuração de cache de objetos para WordPress com Redis e Memcached, desde a instalação do daemon até à verificação do resultado:

Verificar se o Memcached está a funcionar

O melhor teste é prático. Adicione um cabeçalho personalizado no advanced-cache.php para ver visualmente se a página foi servida da cache ou gerada de novo.

Encontre esta linha no advanced-cache.php:

1
var $headers = array();

Substitua por:

1
var $headers = array( 'memcached' => 'activated' );

Agora abra as DevTools no seu navegador (F12), vá ao separador Network e recarregue a página várias vezes. Nos Response Headers, verá um campo memcached: activated, o que significa que o Batcache funcionou e a página foi enviada ao cliente diretamente da RAM.

Um método adicional envolve a linha de comandos do servidor. Consulte as estatísticas do daemon:

1
echo "stats" | nc 127.0.0.1 11211

Na saída, procure por get_hits e get_misses. Se get_hits aumentar quando atualiza páginas do site no navegador, o Memcached está a servir objetos em cache de forma fiável.

Testes de carga: números, não impressões

O Memcached mostra o seu verdadeiro valor sob pressão. O teste original num servidor com 1 núcleo e 512 MB de memória produziu um contraste impressionante: sem Memcached, o servidor caiu após 15 segundos com 50 utilizadores simultâneos; com Memcached, aguentou mais de 400 utilizadores durante 50 segundos sem um único erro. Isto não é magia, é física: quando o CPU não gasta ciclos a remontar as mesmas páginas, serve novos visitantes.

Para autoteste hoje em dia, usam-se ferramentas modernas. Uma das mais convenientes é o k6 da Grafana (open source, executa com um único comando). Um teste básico:

1
k6 run --vus 100 --duration 30s http://your-site.com/

100 utilizadores virtuais durante 30 segundos. Compare os resultados com o Batcache desativado (comente WP_CACHE) e ativado; a diferença em respostas bem-sucedidas e latência mediana será medida em ordens de grandeza.

Para uma verificação rápida sem instalar software, a ferramenta web Loader.io funciona bem; o plano gratuito permite até 10.000 clientes por teste, o que é mais do que suficiente para a maioria dos sites.

Redis ou Memcached: qual escolher

A pergunta que surge inevitavelmente é: porquê não Redis? Ambos são armazenamentos chave-valor em memória; ambos funcionam com WordPress através de drop-ins. A resposta curta: para caching puro, o Memcached é mais simples e rápido; para tudo o resto, Redis.

Comparemos os aspetos essenciais:

Para caching de objetos WordPress, o modelo chave-valor de strings é mais do que suficiente. Os tipos de dados extra do Redis não são necessários aqui. Em operações get/set, ambos são limitados pelo débito da rede e não pelo CPU; em igualdade de circunstâncias, estão equiparados. O Memcached ganha no multi-threading: usa todos os núcleos do CPU de raiz, enquanto o Redis mantém uma arquitetura predominantemente single-threaded.

Escolha Redis se também armazenar sessões, filas de tarefas ou precisar de persistência. Para a tarefa de "acelerar o WordPress e aliviar a base de dados", o Memcached produz resultados mais rapidamente e com menos componentes móveis.

⁉️🤔 Perguntas frequentes

Preciso de Memcached em alojamento partilhado?

Na maioria dos planos de alojamento partilhado, o Memcached não está disponível: os fornecedores não concedem acesso ao daemon ao nível do servidor. No entanto, se o seu plano incluir um VPS ou servidor dedicado, a instalação demora 10 a 15 minutos e proporciona um dos ganhos de velocidade mais notáveis entre todas as otimizações WordPress. Verifique as capacidades do seu plano no painel de controlo ou pergunte ao suporte de alojamento.

Batcache ou WP Rocket: qual é melhor?

O WP Rocket é uma multiferramenta que trata do caching de páginas (baseado em ficheiros), otimização de CSS/JS e lazy loading. O Batcache é uma ferramenta restrita especificamente para caching de páginas com Memcached. Não competem; complementam-se: o Batcache trabalha ao nível do servidor e serve páginas sem iniciar o PHP, enquanto o WP Rocket opera ao nível da aplicação. Na prática, usam-se frequentemente ambos: Batcache para visitantes anónimos, WP Rocket para otimização afinada.

Como limpo a cache do Memcached?

O método mais simples é reiniciar o daemon: sudo systemctl restart memcached. A cache será completamente limpa e começará a aquecer novamente nas visitas seguintes. Para limpeza direcionada, use o plugin Query Monitor: mostra o conteúdo da cache de objetos e permite limpar chaves individuais. Também existe uma opção de consola: echo "flush_all" | nc 127.0.0.1 11211.

Porque é que o site não acelerou depois de instalar o object-cache.php?

A razão mais comum é que a extensão PHP não carregou. Verifique php -m | grep memcached. Se a saída estiver vazia, verifique o caminho para o ficheiro INI e reinicie o PHP-FPM. A segunda razão comum: o object-cache.php não foi copiado para /wp-content/ ou foi copiado com erros de permissão (tem de ser legível pelo utilizador que executa o PHP). Terceira: o daemon Memcached não está em execução; verifique systemctl status memcached.

O Memcached entra em conflito com o OPcache?

Não, são camadas diferentes. O OPcache armazena em cache o bytecode PHP compilado e acelera o arranque do interpretador. O Memcached armazena em cache dados da aplicação: resultados de consultas à base de dados. Trabalham em fases diferentes do processamento de pedidos e complementam-se bem. Em produção, recomenda-se o uso de ambos.

O Memcached pode ser usado em vários servidores?

Sim, este é um dos cenários principais. Na configuração $memcached_servers, pode listar vários endereços IP de daemons Memcached, e o cliente distribuirá automaticamente as chaves entre eles. Para WordPress, o drop-in object-cache.php trata disto: suporta um pool de servidores de raiz.

Deve instalar o Memcached no seu servidor

Instalar o Memcached não é uma panaceia, mas é um dos passos mais eficazes na otimização do WordPress. Se o seu site corre num VPS ou servidor dedicado e quer que ele lide com um crescimento de tráfego múltiplo sem substituir hardware, instale-o. Dez a quinze minutos de trabalho em consola, e a base de dados deixa de ser um estrangulamento.

Se o site estiver em alojamento partilhado sem acesso ao daemon, considere o Redis (fornecido com mais frequência) ou caching baseado em ficheiros via WP Rocket. Se já estiver num VPS, abra o terminal e siga os passos do resumo rápido acima. Verá o resultado no seu primeiro teste de carga.