Un sitio WordPress sin caché se parece a un motor que se calienta desde cero en cada semáforo. Un visitante llega a una página, PHP la ensambla desde los cimientos, golpeando la base de datos entre 30 y 60 veces. Diez visitantes simultáneos significan trescientas consultas. Cincuenta visitantes crean una avalancha que hace que el servidor rechace conexiones más rápido de lo que usted tarda en escribir un comando en la consola.

El problema no es WordPress en sí. El ensamblaje dinámico de páginas es inherentemente ineficiente por defecto; casi todos los CMS funcionan así. La solución ha sido probada durante años de operación en proyectos de alta carga: caché de objetos en RAM mediante Memcached. Una capa de Memcached correctamente configurada transforma un servidor que se ahoga con cincuenta usuarios concurrentes en una máquina que maneja cientos sin un solo milisegundo de vacilación en el tiempo de respuesta.

Recorreremos el ciclo completo de configuración: desde la instalación del demonio hasta una prueba de carga que muestre la diferencia en números. Todos los comandos han sido probados en Ubuntu 22.04/24.04 y AlmaLinux 9, y son compatibles con PHP 8.2-8.5.

💡 Resumen rápido:

• Instale el demonio Memcached y vincúlelo a localhost por seguridad
• Compile la extensión PHP memcached mediante PECL para su versión de PHP
• Coloque el archivo object-cache.php de Automattic en el directorio wp-content
• Instale Batcache y configure advanced-cache.php para el caché de páginas
• Verifique las cabeceras de respuesta mediante las DevTools del navegador
• Ejecute una prueba de carga con k6 y compare los resultados antes y después

Qué es Memcached y por qué su WordPress lo necesita

Memcached es un demonio que almacena datos y objetos en la RAM del servidor. A diferencia del caché basado en archivos (WP Super Cache, W3 Total Cache, WP Rocket), que escribe HTML ya preparado en el disco, Memcached opera un nivel más abajo: los resultados de las consultas a la base de datos, los menús ensamblados, los widgets y la configuración del sitio se alojan en la RAM y pueden recuperarse en microsegundos sin necesidad de reensamblaje.

En la práctica, el panorama es el siguiente. Una página típica de WordPress sin caché realiza entre 30 y 60 consultas a MySQL. Con 50 visitantes concurrentes, la base de datos recibe entre mil quinientas y tres mil consultas, y la CPU entra en modo de fallo. Memcached intercepta la abrumadora mayoría de estas consultas a nivel de RAM: la base de datos descansa, la CPU se mantiene libre y el servidor responde al instante.

Técnicamente, Memcached opera con pares clave-valor. La clave es un hash de la consulta SQL; el valor es el resultado serializado. Cuando WordPress ensambla la misma página de nuevo, primero pregunta a Memcached: «¿Tiene esta clave?» y casi siempre recibe una respuesta lista sin un solo acceso a disco.

La tecnología surgió en 2003 dentro de LiveJournal como solución a problemas extremos de carga en la base de datos. Hoy en día, WordPress.com, Wikipedia, Twitter y miles de proyectos de alta carga funcionan con Memcached. Es maduro, estable y predecible: exactamente lo que producción necesita.

Instalación del demonio Memcached

Cubriremos dos escenarios principales: Ubuntu (22.04/24.04) con apt y AlmaLinux / Rocky Linux 9 con dnf. Adapte los comandos a su distribución.

En Ubuntu:

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

En AlmaLinux / Rocky Linux 9:

1
sudo dnf install memcached libmemcached -y

Tras la instalación, el demonio se inicia automáticamente. Verifíquelo:

1
systemctl status memcached

Por defecto, Memcached escucha en el puerto 11211 en todas las interfaces de red. Esto es un agujero de seguridad: su caché queda accesible para cualquiera que pueda alcanzar ese puerto desde el exterior. Por lo tanto, vincule primero el demonio a localhost.

Abra el archivo de configuración (/etc/memcached.conf en Ubuntu, /etc/sysconfig/memcached en AlmaLinux) y asegúrese de que la línea -l 127.0.0.1 esté presente y no comentada. Reinicie el demonio:

1
sudo systemctl restart memcached

Compilación de la extensión PHP mediante PECL

El demonio por sí solo no acelerará WordPress; necesita un cliente PHP que enseñe a PHP a comunicarse con Memcached. Instale la extensión memcached (nota: específicamente memcached con la letra d, no memcache). Esta última fue eliminada de PHP a partir de la versión 8.0 y no debe usarse.

En Ubuntu, instale primero las herramientas de compilación. Sustituya su versión de PHP: php8.4-dev, php8.3-dev o php8.2-dev:

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

Luego compile la extensión:

1
sudo pecl install memcached

En AlmaLinux / Rocky Linux 9, el conjunto es similar:

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

Después de compilar, la extensión debe registrarse en PHP. Cree un archivo INI:

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

En AlmaLinux, la ruta será diferente: /etc/php.d/memcached.ini.

Si trabaja en Plesk Obsidian, el comando para recargar los manejadores de PHP tras instalar la extensión:

1
plesk bin php_handler --reread

Verifique que la extensión se haya cargado:

1
php -m | grep memcached

La salida debe contener memcached. Si aparece vacía, revise la ruta del archivo INI y reinicie PHP-FPM: sudo systemctl restart php8.4-fpm.

Conectar WordPress a Memcached

El demonio está instalado; la extensión de PHP está cargada. Ahora necesita conectar WordPress a Memcached a nivel de aplicación.

El estándar de facto hoy es el drop-in oficial de Automattic: wp-memcached en GitHub. Está escrito por los mismos desarrolladores que mantienen Batcache y WordPress.com, y funciona correctamente con PHP 8.x (incluyendo 8.4 y 8.5).

Copie el archivo object-cache.php del repositorio a la carpeta /wp-content/ de su sitio. WordPress lo detectará automáticamente y comenzará a usar Memcached como backend de caché de objetos, sin necesidad de plugins adicionales.

Si el puerto de Memcached difiere del predeterminado (11211), añada lo siguiente a wp-config.php:

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

Caché de páginas: Batcache

La caché de objetos es la mitad de la batalla. La otra mitad es almacenar en caché páginas HTML listas para que PHP no se ejecute en absoluto para los visitantes anónimos. Aquí es donde entra Batcache, un plugin de Automattic que almacena las páginas generadas en el mismo Memcached.

El principio es simple. Un visitante llega al sitio; Batcache comprueba si existe una copia HTML lista de esa página en Memcached. Si existe y no ha expirado, la sirve al instante, evitando toda la cadena de PHP y MySQL. Si no existe, o si el visitante ha iniciado sesión, la página se genera de nuevo y simultáneamente se guarda en la caché para visitas posteriores.

Instalación:

Descargue el archivo desde wordpress.org, extráigalo y suba el archivo advanced-cache.php a la raíz de /wp-content/. Luego abra wp-config.php y añada la línea que habilita la caché:

1
define( 'WP_CACHE', true );

Envíe el archivo batcache.php a /wp-content/plugins/ y active el plugin desde el panel de administración.

Dentro de advanced-cache.php, hay alrededor de una docena de configuraciones bajo comentarios. Las más útiles: max_age (tiempo de vida de la página en segundos, por defecto 300 o 5 minutos), seconds (intervalo entre regeneraciones de la misma URL) y unique (no almacenar en caché distintos User-Agents por separado). Para la mayoría de los sitios, los valores predeterminados funcionan; ajústelos solo cuando entienda el motivo.

Un matiz importante: asegúrese de que define( 'WP_CACHE', true ) aparezca ANTES de la línea require_once ABSPATH . 'wp-settings.php' en wp-config.php. Si se coloca después, la caché no se activará y WordPress la ignorará silenciosamente.

Vídeo: instalación y configuración de principio a fin

La teoría es la base, pero los comandos de consola se entienden mejor al verlos una vez. Este vídeo cubre el ciclo completo de configuración de la caché de objetos para WordPress con Redis y Memcached, desde la instalación del demonio hasta la verificación del resultado:

Verificar que Memcached está funcionando

La mejor prueba es práctica. Agregue un encabezado personalizado en advanced-cache.php para que pueda ver visualmente si la página se sirvió desde caché o se generó de nuevo.

Busque esta línea en advanced-cache.php:

1
var $headers = array();

Reemplácela con:

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

Ahora abra DevTools en su navegador (F12), vaya a la pestaña Red y recargue la página varias veces. En los encabezados de respuesta verá un campo memcached: activated, lo que significa que Batcache funcionó y la página llegó al cliente directamente desde la RAM.

Un método adicional implica la línea de comandos del servidor. Consulte las estadísticas del demonio:

1
echo "stats" | nc 127.0.0.1 11211

En la salida, busque get_hits y get_misses. Si get_hits crece cuando actualiza páginas del sitio en el navegador, Memcached está sirviendo objetos en caché de forma confiable.

Pruebas de carga: números, no impresiones

Memcached muestra su verdadero valor bajo presión. La prueba original en un servidor con 1 núcleo y 512 MB de memoria produjo un contraste impresionante: sin Memcached, el servidor colapsó tras 15 segundos con 50 usuarios concurrentes; con Memcached, sostuvo más de 400 usuarios durante 50 segundos sin un solo error. Esto no es magia, sino física: cuando la CPU no gasta ciclos reensamblando las mismas páginas, atiende a nuevos visitantes.

Para autoevaluarse hoy se usan herramientas modernas. Una de las más convenientes es k6 de Grafana (código abierto, se ejecuta con un solo comando). Una prueba básica:

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

100 usuarios virtuales durante 30 segundos. Compare los resultados con Batcache desactivado (comente WP_CACHE) y activado; la diferencia en respuestas exitosas y latencia mediana se medirá en órdenes de magnitud.

Para una verificación rápida sin instalar software, la herramienta web Loader.io funciona bien; el plan gratuito permite hasta 10 000 clientes por prueba, más que suficiente para la mayoría de los sitios.

Redis o Memcached: cuál elegir

La pregunta que surge inevitablemente es ¿por qué no Redis? Ambos son almacenes clave-valor en memoria; ambos funcionan con WordPress mediante drop-ins. La respuesta breve: para caché pura, Memcached es más simple y rápido; para todo lo demás, Redis.

Comparemos lo esencial:

Para almacenar en caché objetos de WordPress, el modelo clave-valor de cadenas es más que suficiente. Los tipos de datos adicionales de Redis no se necesitan aquí. En operaciones get/set, ambos están limitados por el rendimiento de la red más que por la CPU; en igualdad de condiciones, están a la par. Memcached gana en multihilo: usa todos los núcleos de la CPU de fábrica, mientras que Redis mantiene una arquitectura predominantemente monohilo.

Elija Redis si además almacena sesiones, colas de tareas o necesita persistencia. Para la tarea de «acelerar WordPress y descargar la base de datos», Memcached ofrece resultados más rápido y con menos piezas móviles.

⁉️🤔 Preguntas frecuentes

¿Necesito Memcached en un hosting compartido?

En la mayoría de los planes de hosting compartido, Memcached no está disponible: los proveedores no otorgan acceso al demonio a nivel de servidor. Sin embargo, si su plan incluye un VPS o servidor dedicado, la instalación toma de 10 a 15 minutos y brinda una de las ganancias de velocidad más notables entre todas las optimizaciones de WordPress. Verifique las capacidades de su plan en el panel de control o consulte al soporte del hosting.

¿Batcache o WP Rocket: cuál es mejor?

WP Rocket es una multiherramienta que maneja caché de páginas (basada en archivos), optimización de CSS/JS y carga diferida. Batcache es una herramienta específica para caché de páginas con Memcached. No compiten; se complementan: Batcache trabaja a nivel de servidor y sirve páginas sin iniciar PHP, mientras que WP Rocket opera a nivel de aplicación. En la práctica, a menudo se usan ambos: Batcache para visitantes anónimos, WP Rocket para optimización detallada.

¿Cómo vacío la caché de Memcached?

El método más simple es reiniciar el demonio: sudo systemctl restart memcached. La caché se vaciará por completo y comenzará a calentarse de nuevo en las visitas subsiguientes. Para un vaciado selectivo, use el plugin Query Monitor: muestra el contenido de la caché de objetos y permite vaciar claves individuales. También existe una opción de consola: echo "flush_all" | nc 127.0.0.1 11211.

¿Por qué el sitio no se aceleró después de instalar object-cache.php?

La razón más común es que la extensión de PHP no se cargó. Verifique php -m | grep memcached. Si la salida está vacía, compruebe la ruta al archivo INI y reinicie PHP-FPM. La segunda razón común: object-cache.php no se copió a /wp-content/ o se copió con errores de permisos (debe ser legible por el usuario que ejecuta PHP). Tercera: el demonio de Memcached no está en ejecución; verifique systemctl status memcached.

¿Memcached entra en conflicto con OPcache?

No, son capas diferentes. OPcache almacena en caché el bytecode PHP compilado y acelera el arranque del intérprete. Memcached almacena en caché datos de la aplicación: resultados de consultas a la base de datos. Trabajan en distintas etapas del procesamiento de solicitudes y se complementan bien. En producción, se recomienda usar ambos.

¿Se puede usar Memcached en varios servidores?

Sí, este es uno de los escenarios principales. En la configuración de $memcached_servers puede listar varias direcciones IP de demonios Memcached, y el cliente distribuirá automáticamente las claves entre ellos. Para WordPress, el drop-in object-cache.php maneja esto: soporta un grupo de servidores de fábrica.

¿Debería instalar Memcached en su servidor?

Instalar Memcached no es una panacea, pero sí uno de los pasos más efectivos en la optimización de WordPress. Si su sitio corre en un VPS o servidor dedicado y quiere que soporte un crecimiento de tráfico varias veces mayor sin cambiar el hardware, instálelo. De diez a quince minutos de trabajo en consola y la base de datos deja de ser un cuello de botella.

Si el sitio está en un hosting compartido sin acceso al demonio, considere Redis (se ofrece con más frecuencia) o la caché basada en archivos mediante WP Rocket. Si ya está en un VPS, abra la terminal y siga los pasos del resumen rápido anterior. Verá el resultado en su primera prueba de carga.