Cómo medir el rendimiento de WordPress con usuarios conectados

Una prueba pública anónima puede mostrar una web rápida mientras el área de cliente, el editor o una tienda tardan. Las sesiones iniciadas suelen exigir respuestas personalizadas y no siempre se benefician de caché de página. Mide esos recorridos sin filtrar datos privados y sin confundirlos con las métricas públicas de PageSpeed.

Elige recorridos representativos

Define una cuenta de prueba con permisos mínimos y datos ficticios. Mide inicio de sesión, una página privada, búsqueda, edición o, en WooCommerce, carrito y checkout de prueba. Registra estado de caché, región, dispositivo y número de usuarios concurrentes. La guía de medición de web.dev diferencia datos reales y pruebas de laboratorio; las herramientas públicas no siempre pueden entrar en rutas autenticadas.

Compara sin poner datos en riesgo

1. En staging, reproduce el recorrido con usuarios y pedidos ficticios; aísla correos, pagos y webhooks reales.
2. Mide duración de navegación, TTFB, solicitudes AJAX, consultas lentas y uso de PHP/CPU/memoria durante la misma ventana.
3. Prueba una carga incremental acordada, no una avalancha contra producción. Observa errores y colas, no solo medias.
4. Compara anónimo y autenticado en la misma ruta cuando sea posible. Si el público es rápido y la sesión lenta, investiga consultas, plugins y caché de objetos; no cachees HTML privado para «arreglarlo».
5. Documenta resultados agregados; elimina IDs, cookies, datos de clientes y tokens de cualquier informe compartido.

Ejemplo: la portada tiene buen LCP pero el panel de alumnos tarda al listar cursos. Un CDN de imágenes no resolverá necesariamente esa consulta; Redis solo merece una prueba si hay lecturas repetidas. Para una tienda, sigue las exclusiones de caché del checkout antes de cualquier optimización.

Si los procesos PHP se agotan con usuarios conectados, revisa la concurrencia y sus causas. Solicita una revisión de capacidad con la ruta y la carga observada, sin incluir sesiones reales.