¿Por qué va tan lento mi admin de WordPress?

Por qué va lento el escritorio de tu admin de WordPress

Si tu admin de WordPress va lento —o el escritorio de WordPress va muy lento mientras el frontend vuela—, no te lo estás imaginando. Un panel de administración lento es una de las quejas más habituales de los propietarios de sitios después de optimizar la parte pública. Los plugins de caché se saltan wp-admin. Tu CDN no toca el panel de administración. Cada clic en el backend de WordPress lanza una petición PHP nueva, carga los hooks de admin de todos los plugins activos y trae tu conjunto completo de datos en autoload desde wp_options.

Los plugins de caché no ayudan aquí: se saltan las páginas de admin a propósito. El CDN tampoco: el admin es dinámico. La lentitud viene de dentro del propio WordPress.

¿Admin de WordPress lento pero frontend rápido? Localiza tu síntoma

"El admin de WordPress va muy lento" no es un problema: son cinco o seis distintos que desde el escritorio se sienten igual. Busca abajo tu síntoma exacto: la columna de causa te dice a qué mecanismo culpar, y la del siguiente paso te dice qué hacer de verdad.

Paso 0: escanea todo el sitio antes de medir nada

Todo lo que hay bajo esta sección mide una cosa cada vez. Antes de gastar 15 minutos haciéndolo a mano, dedica un minuto a Site Doctor en WP Multitool: ejecuta todo el conjunto de comprobaciones en una sola pasada - OPcache, el drop-in de caché de objetos, la salud de Redis, una sonda de caché de página, solapes de optimizadores, exceso en la base de datos - y ordena los hallazgos empezando por el peor, cada uno enlazado al módulo que lo arregla.

¿Aún no tienes el plugin instalado? La página /scan/ gratuita mide el TTFB y la compresión desde fuera, lo que te dice si el servidor es lento antes de que el navegador reciba un byte. No ejecuta ninguna de las comprobaciones de arriba - esas necesitan correr en el servidor - así que una vez tengas el número de fuera, instala WP Multitool y ejecuta el escaneo. Site Doctor está tanto en Lite como en Pro; las fuentes de autoload y de consultas lentas capturadas que lee son solo de Pro, y un escaneo Lite nombra esas dos como fuentes saltadas en vez de dejar que una lista corta se lea como un sitio limpio.

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.

El escaneo te da la preselección. La profundidad por petición y por callback sigue viniendo de Query Monitor y del Slow Callback Finder más abajo en esta página - la lista ordenada solo te dice cuál merece abrirse. La lista completa de comprobaciones, la checklist de Redis y el uso por WP-CLI están en la documentación de Site Doctor; si prefieres hacerlo a mano, la checklist de 15 minutos de abajo hace el mismo trabajo con DevTools y SQL.

¿Por qué va lento mi escritorio de WordPress? (el escritorio frente al resto de wp-admin)

"Escritorio lento" y "wp-admin lento" se usan indistintamente. Son dos problemas distintos. La pantalla de inicio del escritorio (/wp-admin/index.php) hace trabajo que ninguna otra pantalla del admin hace, así que antes de arreglar nada averigua cuál de los dos tienes.

La prueba lleva un minuto. Carga /wp-admin/, luego Ajustes → Generales, y compara los tiempos de carga del documento en DevTools. Si el escritorio va 2 o más segundos más lento, son los widgets: quita los que no mires a diario con el fragmento de wp_dashboard_setup de la sección de victorias rápidas. Los widgets que hacen llamadas HTTP externas son los peores: la página se queda esperando al servidor de otro.

Si las dos pantallas van igual de lentas, tu problema no es el escritorio: es wp-admin entero. Eso es tamaño de autoload y callbacks de admin_init, y está en las causas de abajo. Arreglar primero los widgets del escritorio en ese caso no te aporta nada en las otras 40 pantallas que usas a diario.

4 causas reales de un admin de WordPress lento

1. El cuello de botella de admin-ajax.php

WordPress enruta todas las peticiones AJAX por un único archivo: admin-ajax.php. Cada petición arranca toda la pila de WordPress. Si 5 plugins hacen llamadas AJAX en el escritorio, son 5 arranques completos de WordPress extra por cada vista del escritorio.

# Check admin-ajax traffic in your browser:
# DevTools → Network → Filter "admin-ajax"
# Look at how many requests fire on a single page load

2. La sobrecarga de la Heartbeat API

Heartbeat de WordPress envía una petición AJAX cada 15–60 segundos para comprobar autoguardados, bloqueos de entradas y notificaciones. Cada petición carga la pila completa de WordPress. En hosting compartido, esto solo ya puede saturar tus workers de PHP.

// Slow down heartbeat to reduce load:
add_filter('heartbeat_settings', function($settings) {
    $settings['interval'] = 120; // seconds (default: 15-60)
    return $settings;
});

3. Callbacks lentos de plugins en admin_init

Los plugins se enganchan a admin_init, admin_menu y admin_enqueue_scripts. Eso se ejecuta en todas las páginas del admin, no solo en la página de ajustes del plugin. Un único callback mal escrito puede añadir más de 500 ms a cada petición del admin.

4. Autoload inflado

La misma consulta de autoload de wp_options que afecta a tu frontend se ejecuta también en cada página del admin. Pero las páginas del admin nunca se cachean, así que notas el impacto completo cada vez. Lee la guía completa del autoload.

Victorias rápidas una vez sabes qué caso tienes

Baja la frecuencia de Heartbeat

Cambiar Heartbeat de 15 s a 120 s recorta un 87% las peticiones de admin-ajax en segundo plano (pestañas del editor, de 15 s a 120 s). La mayoría de sitios no notarán ninguna diferencia funcional.

Desactiva widgets del escritorio

Cada widget del escritorio lanza sus propias consultas al cargar la página. Quita los widgets de plugins que no mires a diario:

add_action('wp_dashboard_setup', function() {
    remove_meta_box('dashboard_quick_press', 'dashboard', 'side');
    remove_meta_box('dashboard_primary', 'dashboard', 'side');
    // Remove plugin widgets that make external API calls
});

Añade caché de objetos

Redis o Memcached mejoran el rendimiento del admin porque las páginas del admin hacen muchas consultas y nunca se cachean como página. Las lecturas a la base de datos que se repiten en cada página del admin pasan a servirse desde memoria.

Datos en autoload en hosting gestionado (WP Engine, Flywheel)

Si estás en WP Engine o Flywheel y el panel de administración va lento, comprueba primero tus datos en autoload. WP Engine recomienda mantener el total de opciones en autoload por debajo de 800 KB. Por encima de eso, cada petición del admin carga en memoria un conjunto de resultados de wp_options demasiado grande, y como las páginas del admin nunca se cachean, notas el coste completo en cada clic.

Audita tu tamaño de autoload con una sola consulta:

-- Total autoloaded data (target: under 800 KB)
SELECT ROUND(SUM(LENGTH(option_value)) / 1024, 1) AS autoload_kb
FROM wp_options
WHERE autoload IN ('yes','on','auto','auto-on');

-- Top 20 biggest autoloaded options
SELECT option_name, ROUND(LENGTH(option_value) / 1024, 1) AS kb
FROM wp_options
WHERE autoload IN ('yes','on','auto','auto-on')
ORDER BY LENGTH(option_value) DESC
LIMIT 20;

Culpables habituales: transients rancios, cachés de comprobación de actualizaciones de plugins y blobs enormes de opciones o temas de maquetadores visuales. El arreglo seguro es quitar el autoload a opciones concretas —wp option set-autoload OPTION_NAME off— y no borrar filas en masa. El Autoloader Optimizer de WP Multitool ordena a los culpables y quita el autoload sin riesgos.

Si el autoload ya está por debajo de 800 KB y tu panel de administración sigue yendo muy lento, el cuello de botella se ha movido a los callbacks de los hooks, y ahí es donde entra el Slow Callback Finder.

Antes y después: qué aspecto tiene "arreglado"

No te voy a enseñar números inventados de clientes: un antes/después que no has medido tú es ficción. Lo que sí puedo darte es la hoja que anoto antes de tocar nada. Rellénala primero, cambia una cosa cada vez y vuelve a medir tras cada cambio. Sin la columna del "antes" nunca sabrás qué arreglo funcionó de verdad.

Dos reglas hacen que los números sean honestos. Mide en la misma página, el mismo navegador y a la misma hora del día: la carga del admin varía con la actividad del equipo. Y cambia una sola cosa entre mediciones, o no podrás atribuir la mejora a nada. Los valores absolutos importan menos que las diferencias: reducir a la mitad el TTFB del admin en un hosting barato vale más que un número "rápido" que no puedes reproducir.

Guías relacionadas