La web pública responde rápido, pero después de iniciar sesión las mismas páginas tardan y el administrador resulta pesado. Es una distinción frecuente: las peticiones autenticadas suelen evitar la caché de página completa, cargar recursos adicionales y ejecutar consultas específicas del usuario.
La solución debe mejorar ese recorrido sin cachear contenido privado ni debilitar los controles de acceso.
Determinar qué perfiles están afectados
Prueba la misma página y acción con administrador, editor o gestor de tienda, cliente o suscriptor y visitante desconectado. Si solo falla el administrador, revisa barra de herramientas, widgets, avisos y comprobaciones de permisos. Si todos los usuarios autenticados son lentos, estudia la exclusión de caché y el trabajo de sesión.
No uses una cuenta real de cliente sin permiso. Crea un usuario controlado con el rol mínimo necesario.
Confirmar la exclusión de caché
La mayoría de sistemas no sirven HTML compartido cuando detectan una cookie de acceso. Compara cabeceras y primer byte en Network con y sin sesión. Un HIT público rápido frente a un BYPASS o MISS autenticado lento apunta a la generación de origen.
No fuerces esas páginas a la caché pública. Mostrar la barra, carrito o datos de otra persona sería una brecha, aunque la respuesta fuera instantánea.
Separar portada, administración y cuenta
«WordPress va lento al conectarme» puede referirse a ver el frontal con barra, abrir /wp-admin/, editar, gestionar pedidos o consultar Mi cuenta. Son plantillas y peticiones distintas.
El frontal puede sufrir por no usar caché; el escritorio por consultas o avisos remotos; la cuenta WooCommerce por pedidos y descargas. Mide cada recorrido por separado.
En Network, selecciona el documento principal y compara “Waiting for server response”. Si el primer byte autenticado crece, investiga tiempo PHP, consultas MySQL, llamadas HTTP, aciertos de caché de objetos, errores y *hooks*, no el peso de la imagen pública.
Revisar barra y plugins administrativos
La barra añade HTML, CSS y JavaScript, y algunos plugins incorporan contadores o estados costosos. En staging o mediante un plugin temporal controlado puedes ocultarla a un usuario de prueba:
add_action( 'after_setup_theme', function () {
if ( current_user_can( 'manage_options' ) ) {
show_admin_bar( false );
}
} );No lo publiques como arreglo permanente. Si mejora, identifica el elemento concreto; si no, retira el código y continúa.
Plugins de seguridad, copias, SEO, analítica y licencias pueden trabajar más para usuarios privilegiados. Una aparición en una traza no demuestra culpabilidad: relaciona una consulta, llamada o *hook* con tiempo medido y confirma el cambio mediante una prueba reversible.
Comprobar caché de objetos y datos del usuario
Sin caché de página, Redis o Memcached pueden reutilizar consultas de forma segura. Confirma que el *drop-in* está conectado, aciertos y fallos, memoria, expulsiones y si el hosting ya ofrece el servicio. No instales una segunda implementación sobre la gestionada por el proveedor.
La caché de objetos reduce repetición, pero no corrige automáticamente una consulta mal diseñada.
WordPress y WooCommerce almacenan permisos, preferencias, sesiones y datos de plugins por usuario. Una sola cuenta puede ser lenta por una sesión enorme, historial de pedidos, metadatos sobredimensionados o widgets propios del rol.
Compara dos cuentas del mismo rol. No borres metadatos por su tamaño: identifica el componente propietario, haz copia y comprueba cómo se recrean.
Analizar WooCommerce y el escritorio
Un cliente conectado puede restaurar carrito, aplicar precios personales, recuperar direcciones, consultar pedidos, suscripciones o membresías. Prueba una cuenta nueva y otra con historial. Optimiza consultas, paginación y procesos en segundo plano; nunca compartas HTML de cuenta o checkout entre clientes.
El escritorio puede solicitar actualizaciones, seguridad, copias, analítica, informes y licencias. Si el HTML llega pronto pero los widgets siguen cargando, repara o retira el widget innecesario. Si el documento tarda, perfila PHP y MySQL en esa pantalla.
Observa también admin-ajax.php y Heartbeat: frecuencia, duración, acción y respuesta. Heartbeat permite autoguardado, bloqueo de entradas y sesiones; no lo desactives globalmente por considerarlo ruido.
Si empezó después de una actualización
Conserva versiones y reproduce la pantalla antes de revertir. Busca nuevos avisos, comprobaciones de capacidades, migraciones, recursos administrativos, acciones programadas y errores. Vaciar la caché pública puede no cambiar nada porque la ruta autenticada la evita.
Secuencia segura
Compara roles y visitante, registra caché y primer byte, separa frontal, escritorio y cuenta, y enfrenta una cuenta nueva con otra antigua. Después identifica consultas, *hooks*, llamadas externas y Ajax; cambia una sola causa y vuelve a probar privacidad, permisos y acción original.
Para una evaluación, indica rol afectado, pantalla, retraso, si sucede en una o todas las cuentas, cambios recientes y si existe Redis. Comparte registros protegidos sin secretos, pero no credenciales.
El éxito no es conservar verde una prueba pública: es acelerar el perfil y la acción afectados sin exponer información privada.