Guía de rendimiento

Rendimiento del backend
de WordPress

Has optimizado tu frontend. Has puesto caché, comprimido imágenes, configurado un CDN. ¿Por qué tu sitio sigue yendo lento?

Por qué optimizar el frontend no basta para la velocidad de WordPress

La mayoría de guías de rendimiento de WordPress se centran en la optimización del frontend: caché, compresión de imágenes, minificación, CDN. Todo eso vale—y deberías hacerlo.

Pero esto es de lo que nadie habla: el rendimiento del backend.

El patrón

El sitio tiene 95 y pico en PageSpeed. Las imágenes están optimizadas. La caché está activada. Y los usuarios siguen diciendo que va lento.

El culpable suele ser el Time to First Byte (TTFB)—el tiempo que tarda tu servidor en empezar a responder. Si tu servidor necesita 2 segundos para construir cada página, ninguna optimización de frontend te va a salvar.

¿Qué problema de backend tienes?

Cuatro síntomas, cuatro causas distintas. Empieza por el que coincida con lo que estás viendo de verdad y sáltate el resto de la página.

  1. El admin va lento pero el frontend va bien. Eso no es un problema de caché, ni lo será nunca. Es admin-ajax, Heartbeat, callbacks de plugins en admin_init, o el autoload. Diagnostica un wp-admin lento.
  2. El TTFB es alto en páginas que debería servir la caché. Algo se está ejecutando antes de que la caché pueda responder. Normalmente una consulta lenta, o un conjunto de autoload demasiado grande para caber en la caché de objetos. Primero Encuentra las consultas lentas, y luego comprueba el tamaño del autoload.
  3. Tu hosting ha marcado "autoloaded data". Mídelo tú antes de actuar: algunos paneles se quedan cortos en WordPress 6.6+. Audita y arregla el autoload inflado.
  4. Sabes cuál es la causa y quieres arreglarla automáticamente. El Autoloader Optimizer clasifica cada opción en autoload y desactiva las seguras, con una restauración de un clic por detrás.

Rendimiento de WordPress: frontend frente a backend

Frontend (resuelto)
  • Optimización de imágenes
  • Minificación de CSS/JS
  • Caché de navegador
  • Entrega por CDN
  • Carga diferida
Backend (casi siempre ignorado)

Los plugins de caché se ocupan de la entrega en el frontend. No tocan el procesado de PHP ni las consultas a la base de datos que ocurren antes de que se mande nada a la caché.

Referencias de TTFB en WordPress: conoce tus números

Comprueba tu TTFB: Chrome DevTools → Red → Primera petición → "Waiting (TTFB)"

<200ms
Excelente
200-500ms
Aceptable
>500ms
Mejorable

Si tu TTFB pasa de 500 ms, céntrate en optimizar el backend antes de tocar nada más. Estás arreglando el problema equivocado.

Problemas habituales de rendimiento del backend de WordPress

1. Autoload inflado

Cada petición de WordPress ejecuta esta consulta: 

SELECT option_name, option_value FROM wp_options WHERE autoload IN ('yes', 'on')

Si tienes 2 MB de datos en autoload, eso son 2 MB transferidos de la base de datos a PHP en absolutamente cada vista de página. Comprueba tu total: 

SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload IN ('yes', 'on');

¿Más de 1 MB? Tienes un problema. A menudo son restos de plugins desactivados. Lee nuestra guía completa para arreglar el autoload inflado en WordPress.

2. Consultas lentas a la base de datos

Una sola consulta de 500 ms retrasa la página entera. Orígenes habituales:

  1. Consultas de metadatos sin índices (sobre todo en productos de WooCommerce)
  2. Consultas LIKE sobre post_content
  3. Varios JOIN sobre wp_postmeta
  4. Consultas COUNT con cláusulas WHERE complejas

Aprende a encontrar y arreglar consultas lentas en la base de datos de WordPress.

3. Falta de caché de objetos

Sin Redis ni Memcached, WordPress reconstruye todo desde la base de datos en cada petición. La caché de objetos puede recortar el TTFB más de un 50% en sitios con mucha base de datos.

4. Problemas de consultas N+1

Cargar 20 entradas y luego lanzar una consulta aparte para los metadatos de cada una = 21 consultas en vez de 2. Los plugins y los temas hacen esto sin querer a menudo.

Cómo diagnosticar problemas de rendimiento del backend de WordPress

Los pasos 02 a 06 miden cada uno una cosa a mano. El paso 01 las mide todas en una sola pasada, así que empieza ahí y deja que la lista ordenada decida cuáles de los otros aún necesitas ejecutar.

¿Aún no tienes el plugin instalado? La página /scan/ gratuita mide el TTFB y la compresión desde fuera — si el servidor es lento antes de que el navegador reciba un byte. No ejecuta las comprobaciones de Site Doctor; esas necesitan el servidor. Una vez tengas el número de fuera, instala WP Multitool y ejecuta el escaneo.

  1. Escanea toda la instalación con Site Doctor — Una pasada sobre el sitio dentro de WP Multitool: OPcache, el drop-in de caché de objetos, la salud de Redis, una sonda de caché de página, solapes de optimizadores y exceso en la base de datos, ordenado empezando por el peor con cada hallazgo enlazado al módulo que lo arregla. Está tanto en Lite como en Pro; las fuentes de autoload y de consultas lentas capturadas son solo de Pro, y un escaneo Lite las nombra como saltadas en vez de informar de un sitio limpio. La checklist de Redis, el uso por WP-CLI y la lista completa de comprobaciones están en la documentación de Site Doctor.
  2. Mide el TTFB — Chrome DevTools o WebPageTest. Si es rápido, céntrate en el frontend. Si es lento, sigue leyendo.
  3. Comprueba el tamaño del autoload — Ejecuta la consulta SQL de arriba. Más de 1 MB = hay que actuar ya.
  4. Activa SAVEQUERIES — Añade define('SAVEQUERIES', true); a wp-config.php temporalmente. Revisa $wpdb->queries en busca de las lentas.
  5. Instala Query Monitor — Plugin gratuito que muestra qué funciones disparan qué consultas. Imprescindible para depurar.
  6. Búsqueda binaria de plugins — Desactívalos todos, mide el TTFB y reactívalos por lotes para dar con el lento.

Cuándo Multitool no es la primera respuesta acertada: si estás depurando una petición concreta y ya sabes cuál, ábrela con Query Monitor; si el trabajo es hacer rápido el front end público y desconectado, eso es un plugin de caché de página, no un escaneo de diagnóstico.

Victorias rápidas de rendimiento en el backend de WordPress

Añade caché de objetos

Si tu hosting ofrece Redis o Memcached, actívalo. Este único cambio puede reducir muchísimo el TTFB en sitios con mucha base de datos.

Añade el índice que falta

La tabla postmeta por defecto de WordPress no tiene un índice útil. Esto ayuda: 

ALTER TABLE wp_postmeta ADD INDEX meta_value_index (meta_value(191));

Limpia los transients

DELETE FROM wp_options WHERE option_name LIKE '%_transient_timeout_%'
AND option_value < UNIX_TIMESTAMP();

Quita el autoload que no se usa

Busca datos de plugins desactivados que sigan en autoload y cámbialos: 

UPDATE wp_options SET autoload='no' WHERE option_name = 'old_plugin_data';

Por qué los problemas del backend de WordPress vuelven una y otra vez

Los problemas del backend son invisibles. WordPress no muestra las consultas lentas por defecto. Tu sitio podría tener consultas de 2 segundos que ni conoces porque no hay ningún registro.

Y no es un arreglo de una vez. El rendimiento se degrada con el tiempo a medida que:

  1. Añades plugins que se enganchan a cada petición
  2. Acumulas contenido y metadatos
  3. Recibes más tráfico (lo que destapa problemas latentes)
  4. Las actualizaciones de plugins introducen regresiones

Necesitas monitorización continua, no solo revisiones manuales de vez en cuando. Si tu admin de WordPress ya va lento, el daño se acumula con cada carga de página.

Vigila tu backend

WP Multitool registra las consultas lentas automáticamente con trazas completas que muestran qué función de qué plugin las provocó. Detecta los problemas antes de que se quejen los usuarios.

Consigue WP Multitool A fondo con el Autoloader Optimizer