Tu web pública puede cargar con normalidad y, sin embargo, entrar en WordPress convertirse en una espera constante: abrir Entradas tarda varios segundos, guardar un producto parece bloquearse, WooCommerce se queda pensando o cualquier cambio dentro de wp-admin resulta desesperadamente lento.
No es una contradicción. Que el frontend sea rápido no significa que la administración de WordPress también tenga que serlo.
El área pública y el escritorio pueden ejecutar procesos diferentes, consultar datos distintos y depender de plugins o servicios que solo intervienen cuando un usuario está identificado como administrador. Además, la caché que acelera las páginas públicas normalmente no resuelve de la misma forma las peticiones dinámicas de wp-admin.
Por eso, cuando solo va lento el panel de WordPress, instalar otro plugin de caché o cambiar de hosting sin diagnosticar primero puede no solucionar nada.
La cuestión es averiguar qué parte de la petición está consumiendo el tiempo: un plugin, una consulta de base de datos, una llamada externa, una tarea programada, WooCommerce, PHP o los propios recursos del servidor.
Si también notas lentitud en la parte pública, conviene ampliar el diagnóstico para distinguir si el problema está en el hosting o en la propia web. Si el problema se concentra en el escritorio, sigue con las comprobaciones de este artículo.
Una página pública puede beneficiarse de varias capas de optimización antes de llegar al visitante: caché de página, CDN, caché del navegador o páginas previamente generadas.
El escritorio funciona de otra manera.
Cuando entras en WordPress, muchas pantallas deben generar información específica para tu usuario y obtener datos actualizados. Dependiendo de la instalación, una petición puede implicar:
Por tanto, un frontend rápido gracias a la caché puede convivir perfectamente con un backend que tiene un problema de rendimiento real.
Esta diferencia también explica por qué una buena puntuación en PageSpeed Insights no demuestra que wp-admin esté funcionando correctamente. PageSpeed analiza una URL pública desde el punto de vista de la experiencia del visitante; no diagnostica las consultas PHP, tareas o plugins que están ralentizando una pantalla privada de administración.
El patrón del problema da muchas pistas. Antes de desactivar plugins o tocar la base de datos, cronometra varias acciones y anota dónde aparece la espera.
Si Escritorio, Entradas, Páginas, Plugins y Ajustes tardan aproximadamente lo mismo, hay que investigar causas que afectan de forma transversal a cada petición.
Entre ellas:
Aquí tiene sentido medir antes de acusar a una pantalla concreta.
Es una señal muy útil.
Si la administración en general responde bien pero Productos, Pedidos, un editor concreto o la página de un plugin tarda mucho, el problema suele estar más acotado.
Por ejemplo, esa pantalla puede:
En este escenario, cambiar de hosting puede aliviar el síntoma si proporciona más recursos, pero no demuestra que el hosting sea la causa.
El momento en que empezó la lentitud importa.
Si ayer wp-admin respondía con normalidad y hoy tarda diez segundos después de actualizar un plugin, esa relación temporal convierte el cambio en un candidato razonable para investigar.
No demuestra por sí sola que el plugin sea defectuoso. Puede haber un conflicto con otra extensión, una migración de datos pendiente, nuevas tareas programadas o un proceso que se ejecuta por primera vez después de actualizar.
Pero sí te permite reducir mucho el área de búsqueda.
Cuando unas veces el panel responde inmediatamente y otras se bloquea durante varios segundos, conviene comprobar procesos que no se ejecutan en cada petición:
La intermitencia también es información de diagnóstico.
No importa únicamente cuántos plugins tienes, sino qué hacen y cuándo lo hacen.
Un plugin sencillo puede tener un impacto mínimo. Otro puede añadir consultas, peticiones HTTP, cálculos o funciones a prácticamente todas las páginas de administración.
Por eso, afirmar que «30 plugins son demasiados» o que «10 plugins no pueden ser el problema» simplifica demasiado la cuestión. Si tu instalación lleva tiempo acumulando extensiones, también puede ser útil revisar cómo sanear un WordPress desordenado antes de añadir nuevas herramientas.
La prueba más clara consiste en comparar el comportamiento con y sin el componente sospechoso.
Pero no es buena idea empezar desactivando plugins al azar en una web empresarial en producción, especialmente si tienes WooCommerce, reservas, membresías, formularios, pagos o integraciones externas.
Una desactivación puede dejar temporalmente funciones indisponibles o provocar efectos secundarios.
Siempre que sea posible:
Lo importante es obtener una comparación: con el plugin ocurre / sin él no ocurre.
Eso vale mucho más que asumir que el plugin que más memoria utiliza tiene que ser necesariamente el culpable.
La tabla de opciones de WordPress almacena configuración del propio sistema y de muchos plugins y temas.
Algunas opciones están configuradas para cargarse automáticamente al iniciar WordPress. Son las llamadas autoloaded options.
Esto es normal. WordPress necesita tener determinados ajustes disponibles continuamente.
El problema aparece cuando el conjunto de datos cargado automáticamente crece demasiado.
La documentación oficial de WordPress advierte que demasiadas opciones autoload pueden ralentizar el sitio y Salud del sitio incorpora una comprobación específica para detectarlas. Actualmente, el umbral predeterminado para mostrar el aviso es de 800.000 bytes, aunque técnicamente puede modificarse mediante un filtro.
Puedes empezar por:
Herramientas → Salud del sitio
y comprobar si WordPress informa de un problema relacionado con las opciones cargadas automáticamente.
Hay que interpretar ese dato correctamente.
El aviso sirve como señal para investigar. No significa automáticamente:
wp-admin está lento porque tengo más de 800 KB de autoload.
Puede haber un problema importante con plugins aunque el tamaño sea inferior. Y una web que supere el umbral puede tener además otros cuellos de botella.
Tampoco conviene abrir wp_options y empezar a borrar filas por tamaño.
Una opción con un nombre desconocido puede pertenecer a un plugin activo y ser imprescindible para su funcionamiento.
Si sospechas de esta parte de la instalación, nuestra guía para limpiar la base de datos de WordPress explica qué datos suelen acumularse y, sobre todo, qué precauciones conviene tomar antes de eliminarlos.
Haz una copia de la base de datos antes de modificar opciones, tablas o datos internos.
Este error de diagnóstico es frecuente.
Una tienda con muchos pedidos puede tener una base de datos considerable y funcionar correctamente. Una web relativamente pequeña puede tener una consulta problemática y responder con lentitud.
El tamaño, por sí solo, no da el diagnóstico.
Lo que interesa averiguar es:
Eliminar revisiones y transients caducados puede formar parte del mantenimiento, pero no deberíamos presentar una limpieza general de la base de datos como solución a un wp-admin lento si antes no sabemos dónde está el cuello de botella.
WordPress utiliza WP-Cron para ejecutar tareas programadas.
Plugins y el propio WordPress pueden utilizarlo para actualizaciones, publicaciones programadas y muchos otros procesos. El núcleo dispone además de comprobaciones relacionadas con eventos programados dentro de Salud del sitio.
Que exista cron no supone un problema.
Lo que merece investigación es encontrar, por ejemplo:
Aquí de nuevo importa distinguir causa y síntoma. Ver muchas tareas programadas no significa que debamos borrarlas.
No elimines eventos cron desconocidos simplemente porque parezcan antiguos. Pueden controlar procesos necesarios para pagos, emails, sincronizaciones o actualizaciones.
En una tienda WooCommerce el diagnóstico tiene una capa adicional.
WooCommerce utiliza Action Scheduler, una cola de trabajos en segundo plano empleada para diferentes procesos, entre ellos determinadas notificaciones, webhooks y operaciones de extensiones.
WooCommerce permite consultar esas tareas desde:
WooCommerce → Estado → Acciones programadas
y distinguir acciones completadas, pendientes, en curso y fallidas.
Encontrar algunas acciones pendientes no demuestra por sí mismo que exista un problema. Lo interesante es detectar patrones anómalos:
WooCommerce documenta además la dependencia entre Action Scheduler y WP-Cron en su funcionamiento habitual.
Esto es especialmente relevante si el problema se concentra en áreas como pedidos, suscripciones, analítica o procesos administrativos de WooCommerce.
No conviene «vaciar la cola» sin saber qué contiene. Algunas acciones pueden corresponder a operaciones empresariales que todavía deben ejecutarse.
No todo el tiempo de espera se consume dentro de tu servidor.
Un plugin puede consultar:
Cuando WordPress realiza una solicitud HTTP y necesita su respuesta para continuar, el rendimiento puede depender también del servidor remoto y de la conexión entre ambos sistemas.
La propia documentación de WordPress advierte que esperar respuestas HTTP externas puede tener un impacto importante en el rendimiento si no están bien gestionadas.
Este patrón suele llamar la atención cuando una pantalla tarda, por ejemplo, varios segundos casi exactos antes de aparecer. No permite asegurar que haya un timeout externo, pero sí justifica medir las peticiones.
Sí puede existir una relación, pero HTTPS no debería asumirse como culpable simplemente porque la lentitud empezó después de activarlo.
Después de una migración pueden quedar problemas relacionados con:
La pregunta útil es: ¿qué cambió exactamente al migrar y qué petición está tardando?
Si cada acceso interno realiza una redirección innecesaria o algún proceso intenta comunicarse con una URL que ya no responde correctamente, eso sí merece corregirse.
Un cambio temporalmente relacionado con el problema es una pista, no el diagnóstico final.
A veces sí. Pero tampoco debería ser el primer botón que pulsamos.
Un límite de memoria insuficiente puede provocar errores o impedir que determinados procesos completen su trabajo. En webs con WooCommerce, constructores, importaciones o plugins exigentes, el consumo puede ser considerable.
Más memoria no arregla automáticamente un proceso ineficiente.
Si un plugin genera una consulta lenta, espera cinco segundos a una API o realiza una operación innecesaria en cada pantalla administrativa, duplicar la memoria PHP puede no cambiar prácticamente nada.
El servidor puede disponer de 512 MB de límite PHP y seguir teniendo:
Por eso conviene pedir métricas antes de aumentar recursos de forma indefinida.
Si necesitas revisar otros parámetros de configuración, nuestra guía de wp-config.php en WordPress explica qué contiene este archivo y por qué conviene modificarlo con cuidado.
Un «todo está bien en el servidor» aporta poca información.
Si necesitas involucrar al soporte del hosting, proporciona una hora aproximada y una URL administrativa concreta donde puedas reproducir el problema. Después pide datos medibles.
Por ejemplo:
La diferencia entre «el servidor va bien» y disponer de métricas concretas de la petición problemática es enorme desde el punto de vista del diagnóstico.
Si tienes dudas sobre si el cuello de botella está realmente en el proveedor, consulta nuestro análisis sobre cómo saber si un WordPress lento tiene un problema de hosting o de la propia web.
Cuando las comprobaciones básicas no explican el problema, Query Monitor es una de las herramientas más útiles para dejar de diagnosticar por intuición.
El plugin puede mostrar, entre otros datos:
Además, permite agrupar consultas por componente, lo que facilita relacionar un tiempo excesivo con un plugin determinado.
No hay que fijarse únicamente en el número total de consultas.
200 consultas rápidas pueden ser menos problemáticas que una única consulta de varios segundos.
Lo que buscamos es dónde se consume el tiempo.
Query Monitor es una herramienta de diagnóstico, no un optimizador automático. Sus resultados requieren cierta interpretación y el propio plugin reconoce que añade una pequeña sobrecarga mientras recoge información.
En una web crítica conviene utilizar herramientas de profiling de forma controlada y retirarlas cuando termine la investigación si ya no son necesarias.
WordPress incluye la Heartbeat API, utilizada para mantener comunicación periódica entre el navegador y el servidor mientras trabajas dentro de la administración.
Entre otros usos, permite funcionalidades que requieren actualizaciones periódicas mientras el usuario mantiene abierta una pantalla de WordPress.
Por eso encontrarás muchas recomendaciones que sugieren «desactivar Heartbeat para acelerar WordPress».
No debería ser una acción automática.
Reducir o modificar su funcionamiento puede afectar características que dependen de esa comunicación. Si sospechas de las peticiones AJAX periódicas, primero hay que identificar qué está ejecutándose en ellas y qué coste tienen.
La presencia de Heartbeat es normal. Una operación costosa enganchada a esas peticiones es otra cuestión.
Si el frontend funciona bien pero wp-admin está lento, seguiría este orden:
Este último paso importa mucho.
Si una pantalla tardaba 8 segundos y después del cambio tarda 1,2, tienes evidencia de mejora. Si simplemente «parece algo más rápida», todavía no tienes una comparación fiable.
Evitaría empezar por una colección de cambios simultáneos:
wp_options;Si cambias cinco cosas a la vez y el problema desaparece, tampoco sabrás qué lo solucionó.
Y si algo se rompe, será mucho más difícil averiguar qué modificación lo causó.
Hay una diferencia entre hacer comprobaciones seguras y comenzar a modificar una instalación que sostiene un negocio.
Conviene detener las pruebas directas sobre producción cuando:
En esos casos, el objetivo ya no debería ser probar más «trucos», sino medir la petición problemática y localizar el cuello de botella sin poner en riesgo la web.
La lentitud de wp-admin no suele resolverse de forma fiable preguntándose si WordPress «necesita más potencia». Hay que separar las capas: plugin, consulta, procesos en segundo plano, petición externa y servidor.
Ese diagnóstico también forma parte de un mantenimiento técnico de WordPress bien planteado: detectar el origen antes de limpiar, migrar o aumentar recursos.
Cuando solo el panel de WordPress es lento, no estamos ante el mismo problema que una web pública con malas métricas de carga.
El síntoma ya nos está dando información.
Si todas las pantallas son lentas, busca procesos transversales. Si solo falla una sección, investiga qué añade esa pantalla. Si empezó después de un cambio, compara antes y después. Si ocurre de forma intermitente, observa tareas programadas y servicios externos. Y si utilizas WooCommerce, incorpora Action Scheduler al diagnóstico.
La solución puede terminar siendo un plugin, una consulta, una cola de trabajos, el servidor o una combinación de varios factores.
Pero primero se mide y después se corrige.
Esa diferencia evita perder horas tocando partes de WordPress que nunca fueron el problema.
Si prefieres que el diagnóstico y el seguimiento técnico formen parte de una revisión periódica, consulta nuestro servicio profesional de mantenimiento WordPress.
