Monitoreo de rendimiento para WordPress empresarial en 2026

El monitoreo de rendimiento para WordPress empresarial responde a tres preguntas: qué experimentan los visitantes reales, si el siguiente despliegue empeoró algo y qué capa del stack es la responsable. Cada pregunta necesita un instrumento distinto. Los datos de campo de usuarios reales (RUM) responden a la primera, las pruebas sintéticas en el pipeline de despliegue a la segunda, y las herramientas del lado del servidor (Query Monitor, un agente APM, trazas de OpenTelemetry, el slow query log de MySQL, las estadísticas de Redis) a la tercera.

Un checkout lento o un Interaction to Next Paint (INP) que sube en el sitio de un mercado concreto cuesta ingresos y visibilidad en buscadores mucho antes de que alguien abra un ticket. Las instalaciones modernas de WordPress se reparten entre una CDN, workers de PHP, una base de datos, una caché de objetos y a veces un frontend separado, así que “¿está el servidor activo?” dejó de ser una pregunta útil hace años. Esta guía describe un stack de monitoreo para ese tipo de instalación, con cada umbral y cada ajuste tomados de la documentación del proveedor o del estándar enlazada en el texto.

#RUM vs monitoreo sintético en WordPress

Para tener una visión completa de tu ecosistema, debes monitorear desde dos perspectivas. No compiten entre sí: cada una ve algo que la otra no puede ver.

#Real User Monitoring (RUM)

RUM captura la experiencia de cada visitante, en su dispositivo y en su red.

• Fragmentación de dispositivos: cómo rinde tu sitio en un iPhone nuevo frente a un Android de gama media con una conexión móvil saturada.
• Rastreo de interactividad: cada interacción que alimenta el INP, para encontrar los elementos concretos de la interfaz que los usuarios perciben como lentos.
• Rendimiento Edge: la latencia real entre un visitante y la ubicación de CDN más cercana, por país.

Una media de todo el sitio oculta casi todo lo importante. Divide los datos RUM por clase de dispositivo, tipo de conexión, país, plantilla (entrada, archivo, producto, carrito) y primera visita frente a visita recurrente. Informa del percentil 75, porque es el valor con el que Google evalúa los Core Web Vitals. El artículo de web.dev sobre Web Vitals formula la regla de medición así:

“el percentil 75 de las cargas de página, segmentado entre dispositivos móviles y de escritorio”

Fuente: Web Vitals, web.dev (traducción propia)

#Monitoreo sintético y pruebas de uptime

Las pruebas sintéticas usan navegadores guionizados que cargan tus páginas en condiciones controladas.

• Integración CI/CD: una ejecución de Lighthouse cada vez que un desarrollador envía un cambio al código del tema o de los plugins de WordPress.
• Pruebas de uptime y de recorridos: ejecuciones guionizadas de las rutas que generan ingresos (“añadir al carrito”, “enviar formulario de contacto”) desde las regiones donde vendes, con una frecuencia fija.

Las pruebas sintéticas no ven a los usuarios reales, así que nunca sustituyen a RUM. Su ventaja es que las condiciones de la prueba no cambian. Cuando un resultado sintético empeora, la causa está en el código o en la infraestructura, no en quién visitó el sitio ese día.

#Cómo recoger Core Web Vitals con la librería web-vitals

No necesitas un script pesado de terceros para empezar. La librería web-vitals de Google se describe como una librería diminuta (unos 3K con brotli) y modular y mide cada métrica de la misma forma en que la reportan las herramientas de Google. Lee las APIs de rendimiento del navegador en la página y entrega cada resultado a un callback; después navigator.sendBeacon envía el valor a tu colector, y el README de la librería indica que este método funciona incluso mientras la página se está descargando.

import { onCLS, onINP, onLCP } from 'web-vitals';

function sendToTelemetry(metric) {
  const body = JSON.stringify({
    name: metric.name,
    value: metric.value,
    rating: metric.rating,
    delta: metric.delta,
    id: metric.id,
    page: window.location.pathname
  });

  if (navigator.sendBeacon) {
    navigator.sendBeacon('/api/telemetry/vitals', body);
  } else {
    fetch('/api/telemetry/vitals', { body, method: 'POST', keepalive: true });
  }
}

onCLS(sendToTelemetry);
onINP(sendToTelemetry);
onLCP(sendToTelemetry);

El fragmento envía solo pathname, sin la query string. Esa decisión importa para la privacidad, como se explica más abajo.

La build de atribución de la misma librería convierte un mal número en un ticket que alguien puede resolver. Para LCP informa del selector del elemento LCP (target), la URL de la imagen cuando la hay, el tiempo hasta el primer byte, el retraso y la duración de carga del recurso y el retraso de renderizado del elemento. Para INP informa del elemento con el que interactuó el usuario, el retraso de entrada, la duración del procesamiento y el retraso de presentación, además de longAnimationFrameEntries, las entradas Long Animation Frame que coincidieron con la interacción en los navegadores que admiten esa API. “El INP es malo en las fichas de producto” se convierte en “el selector de variantes pasa la mayor parte del tiempo en un script concreto”.

#Por qué Search Console y PageSpeed Insights no bastan

Search Console y PageSpeed Insights muestran datos de campo del Chrome UX Report (CrUX). La documentación de la API de CrUX describe esos datos como una media móvil de 28 días de métricas agregadas, actualizada a diario hacia las 04:00 UTC. Una regresión desplegada esta mañana mueve esa media despacio, así que te enteras días o semanas después de que empiece.

La cobertura es el segundo límite. Según la metodología de CrUX, una página u origen debe ser públicamente descubrible y suficientemente popular para aparecer en el conjunto de datos, y solo aportan datos los usuarios de Chrome que lo han activado, en escritorio y Android. Chrome en iOS, las apps con Android WebView y otros navegadores Chromium como Edge no aportan datos. Un portal B2B tras un login, el sitio de un mercado con poco tráfico o una audiencia mayoritariamente en iPhone pueden mostrar pocos datos de CrUX o ninguno.

CrUX sigue siendo la referencia correcta para SEO, porque es el conjunto de datos con el que Google informa de los Core Web Vitals. Para reaccionar el mismo día del despliegue necesitas tu propio flujo RUM, sin ventana de promedio.

#Cómo hacer un monitoreo RUM conforme al RGPD

Cada beacon de RUM es una petición desde el navegador del visitante hacia tu colector. Si incluye una dirección IP, un ID de sesión o una URL completa con parámetros (piensa en una dirección de email en un enlace de newsletter), estás tratando datos personales sujetos al RGPD, y la autoridad de control en España es la AEPD. Almacenar o leer información en el dispositivo del visitante (cookies, localStorage) exige consentimiento según el artículo 22.2 de la LSSI, salvo el almacenamiento estrictamente necesario para transmitir una comunicación o para prestar un servicio que el usuario ha solicitado expresamente.

Mantén el beacon ligero:

• Recoge la métrica, no a la persona: nombre de la métrica, valor, tipo de plantilla, país, clase de dispositivo. No necesitas una dirección IP para calcular el percentil 75 del LCP.
• Elimina la query string antes del envío y conserva solo la ruta.
• No crees una cookie solo para enlazar visitas. Pierdes la división entre sesiones nuevas y recurrentes, y la telemetría deja de depender del consentimiento para el almacenamiento en el dispositivo.
• Configura el colector para que no guarde las direcciones IP o las trunque al recibirlas.
• Si tu proveedor almacena datos en EE. UU., comprueba si ofrece una región de datos en la UE y que exista un contrato de encargo del tratamiento firmado.

Esto no es asesoramiento jurídico; el delegado de protección de datos marca el límite para tu instalación.

#Cómo bloquear despliegues lentos con Lighthouse CI

Lighthouse CI ejecuta Lighthouse contra URLs de preview o staging en tu pipeline y compara los resultados con las aserciones que tú defines. Por defecto lhci collect ejecuta Lighthouse tres veces por URL (numberOfRuns), lo que suaviza ejecuciones aisladas con ruido. Cada aserción tiene un nivel: warn muestra el resultado sin fallar, mientras que error hace que el comando termine con un código distinto de cero, que es lo que hace fallar el build.

El preset lighthouse:recommended es un punto de partida razonable. Según la documentación de Lighthouse CI, comprueba que cada auditoría fuera de rendimiento obtuvo la puntuación máxima y avisa cuando los valores de las métricas bajan de una puntuación de 90. Las auditorías que no encajan con el proyecto se desactivan una a una. Añade límites explícitos para lo que tu equipo controla directamente, como el peso total de JavaScript y CSS en las plantillas que generan ingresos.

Lighthouse se ejecuta en laboratorio, así que sus números no coincidirán con CrUX. Úsalo para comparar un build con el anterior en las mismas condiciones, no para predecir los valores de campo.

#Pruebas de regresión visual con Playwright

El rendimiento también es estabilidad. Una actualización de plugin que de repente desplaza el layout en móvil perjudica a la vez al CLS y a las conversiones.

Playwright incluye esta comprobación como la aserción toHaveScreenshot. En la primera ejecución genera capturas de referencia; las ejecuciones posteriores se comparan con ellas. Tras un cambio de diseño intencionado se regenera la referencia con npx playwright test --update-snapshots. La opción maxDiffPixels fija cuántos píxeles pueden diferir antes de que la prueba falle. La documentación de Playwright advierte además de que el renderizado varía según el sistema operativo, la versión del navegador, la configuración y el hardware, así que genera las referencias en el mismo entorno donde se ejecutan las pruebas, normalmente el contenedor de CI, y no en el portátil de un desarrollador.

La configuración práctica es modesta: capturas de las plantillas que generan ingresos (inicio, categoría, producto, carrito, checkout) en tres anchos de viewport. Las diferencias pequeñas dentro de la tolerancia pasan; las mayores esperan una decisión humana en el pull request.

#Cómo usar Query Monitor y Salud del sitio para diagnosticar WordPress

Query Monitor, de John Blackbourn, es el plugin de diagnóstico de referencia para una sola petición. En cada carga de página lista las consultas a la base de datos y marca las lentas, duplicadas o erróneas, muestra los errores de PHP con el componente responsable y la pila de llamadas, y lista las peticiones de la HTTP API con el código de respuesta, el componente responsable y el tiempo empleado. También cubre hooks y acciones, la jerarquía de plantillas, los scripts y estilos encolados y las actualizaciones de transients. Por defecto su salida solo es visible para Administradores en sitios individuales y para Superadministradores en Multisite; una cookie de autenticación puede ampliar el acceso a otros usuarios.

Usamos Query Monitor en staging para diagnosticar, no como monitoreo continuo de producción: explica una petición en profundidad, mientras que un agente APM agrega todas.

Salud del sitio (Herramientas, Salud del sitio) añade una capa gratuita de alerta temprana. Su pestaña Estado agrupa los hallazgos en problemas críticos, mejoras recomendadas y pruebas superadas. Desde WordPress 6.6, Salud del sitio informa de un problema crítico cuando el tamaño total de las opciones con autoload supera 800 KB, como describe la nota de desarrollo de WordPress 6.6 sobre opciones con autoload. La misma versión deja de cargar automáticamente por defecto las opciones individuales de más de 150.000 bytes, un límite distinto que controla el filtro wp_max_autoloaded_option_size. Los datos de autoload inflados se cargan en cada petición, así que conviene leer esta comprobación tras cada auditoría de plugins.

#APM para WordPress con el agente PHP de New Relic

Un agente APM registra cada petición en producción y muestra dónde se fue el tiempo. El soporte de WordPress del agente PHP de New Relic es un buen ejemplo de instrumentación que entiende WordPress:

• newrelic.framework.wordpress.hooks está activado por defecto desde la versión 5.3 del agente; ponerlo en false desactiva las métricas específicas de WordPress.
• Las métricas de hooks muestran el tiempo empleado dentro de cada hook de WordPress, medido desde apply_filters, apply_filters_ref_array, do_action y do_action_ref_array.
• Las métricas de plugins y temas muestran el tiempo empleado dentro de cada plugin y tema, lo que responde a “qué plugin ha ralentizado esta página” sin adivinar.
• Desde la versión 10.16 del agente, newrelic.framework.wordpress.hooks.options controla cuánto se registra. En modo threshold el agente registra solo los hooks más lentos que newrelic.framework.wordpress.hooks.threshold, cuyo valor por defecto es 1 ms. Así se reducen la sobrecarga y el volumen de datos en sitios con mucho tráfico.

Datadog, Tideways y Blackfire cubren un terreno parecido con sus propios agentes. La elección suele depender de lo que ya usa el resto de la organización, porque una sola herramienta para todos los servicios es mejor que una herramienta superior que nadie más consulta.

#Cómo trazar WordPress con OpenTelemetry PHP

OpenTelemetry es la opción neutral respecto al proveedor: las mismas trazas pueden ir a Grafana Tempo, Jaeger o un backend comercial. La documentación de autoinstrumentación PHP exige PHP 8.0 o superior y la extensión instalada con pecl install opentelemetry. La configuración se hace con variables de entorno:

OTEL_PHP_AUTOLOAD_ENABLED=true
OTEL_SERVICE_NAME=wordpress-shop
OTEL_TRACES_EXPORTER=otlp
OTEL_EXPORTER_OTLP_ENDPOINT=http://collector:4318

Para WordPress existe un paquete dedicado, open-telemetry/opentelemetry-auto-wordpress, que se instala con composer require open-telemetry/opentelemetry-auto-wordpress. El núcleo de WordPress no usa Composer, así que el README del paquete muestra cómo cargar el autoloader de Composer antes de que arranque WordPress, por ejemplo con php_value auto_prepend_file /var/www/vendor/autoload.php en Apache. La instrumentación se puede volver a desactivar con OTEL_PHP_DISABLED_INSTRUMENTATIONS=wordpress.

Para perfilados puntuales desde la terminal, el comando wp profile de WP-CLI no necesita ningún plugin. Se instala con wp package install wp-cli/profile-command; después wp profile stage mide las fases de bootstrap, consulta principal y plantilla, wp profile hook las acciones y filtros, y wp profile queries las consultas a la base de datos. Funciona en servidores donde no se te permite instalar plugins. Xdebug ofrece el perfil más detallado de todos, y su sobrecarga lo deja en las máquinas locales.

#Qué métricas de base de datos y caché de objetos monitorear

El slow query log de MySQL está desactivado por defecto. Registra las sentencias que tardan más de long_query_time segundos y examinan al menos min_examined_row_limit filas. El valor por defecto de long_query_time es 10 segundos, demasiado permisivo para una petición web; el mínimo es 0 y admite resolución de microsegundos. Cada entrada incluye Query_time, Lock_time, Rows_sent y Rows_examined, y una gran diferencia entre filas examinadas y filas enviadas es la señal clásica de un índice ausente, típicamente en wp_postmeta detrás de los filtros de productos. log_queries_not_using_indexes añade al log las consultas sin índice, y log_throttle_queries_not_using_indexes limita la velocidad a la que se escriben. mysqldumpslow resume el archivo de log. Cómo corregir lo que encuentra el log se explica en nuestra guía de optimización de la base de datos de WordPress.

Para una caché de objetos Redis, el comando INFO proporciona los contadores en bruto:

• keyspace_hits y keyspace_misses: búsquedas de claves con éxito y fallidas. La tasa de aciertos es los aciertos divididos entre aciertos más fallos.
• evicted_keys: claves eliminadas por el límite maxmemory. Si el número sube, la caché es demasiado pequeña para el conjunto de trabajo.
• mem_fragmentation_ratio: la relación entre used_memory_rss y used_memory.

No existe una tasa de aciertos “buena” universal, porque depende de qué parte del sitio se puede cachear. Registra tu propia línea base tras un despliegue limpio y alerta ante una caída sostenida: suele significar que un plugin nuevo se salta la caché, que cambió una configuración o que el tráfico se desplazó a páginas sin caché.

#Cómo monitorear WordPress headless

Cuando WordPress es solo la API de contenido y el frontend corre en Astro o Next.js, hay dos sistemas que vigilar. En el backend: el tiempo de respuesta y la tasa de errores 5xx de los endpoints de la REST API o de WPGraphQL. En el frontend: el tiempo de build, el tiempo de regeneración de páginas y el coste de hidratación en el cliente.

Una traza distribuida une ambos. La recomendación W3C Trace Context define las cabeceras traceparent y tracestate, que llevan un ID de traza desde el frontend hasta la API de WordPress, y OpenTelemetry las admite para propagar el contexto. Una misma petición se ve entonces a través de la CDN, el frontend, la API de WordPress, MySQL y Redis. Sin ella, cada equipo ve solo su tramo y cada petición lenta parece culpa de la capa vecina.

#Detección de anomalías en el rendimiento web

Los umbrales fijos como “avísame si el LCP supera 2,5 s” saltan demasiado tarde o generan falsas alarmas en los picos de tráfico. Las líneas base dinámicas aprenden qué es normal para cada hora y día de la semana y avisan de las desviaciones antes de llegar a un límite duro. La mayoría de las plataformas de APM y observabilidad lo ofrecen; el ajuste importa menos que el contexto que lo rodea.

Una anomalía solo sirve cuando se ve qué cambió junto a ella. Marca despliegues, actualizaciones de plugins y lanzamientos de campañas en la misma línea temporal que las métricas: Grafana lo hace con anotaciones, New Relic con marcadores de despliegue. Un pico de TTFB justo al lado de una actualización de plugin cierra la investigación antes de empezarla.

#Cómo definir un presupuesto de rendimiento para Core Web Vitals

Un presupuesto es un conjunto de límites superiores en el que superar uno tiene una consecuencia acordada. Los umbrales “buenos” de Google en el percentil 75 son el mínimo: LCP en 2,5 s o menos, INP en 200 ms o menos, CLS en 0,1 o menos, según web.dev. Los equipos empresariales suelen fijar objetivos más estrictos por proyecto, además de límites al JavaScript y CSS enviados, comprobados en la puerta de Lighthouse CI.

Un presupuesto sin responsable se diluye. Nombra a una persona que revise la tendencia cada semana, decida si un umbral sigue teniendo sentido y pueda decir no a un despliegue. Enruta también las alertas por severidad: un checkout roto avisa al ingeniero de guardia, un TTFB que sube despacio va a un canal del equipo y las pequeñas desviaciones esperan al informe semanal. Si cada alerta despierta a alguien, al cabo de un mes nadie las lee.

#Cómo afecta la velocidad web a la conversión

La pregunta útil para la dirección no es “cuántos milisegundos” sino “cuánto nos cuesta una página más lenta”. Respóndela con tus propios datos y no con un porcentaje tomado del caso de estudio de otra empresa. Envía los valores RUM al mismo almacén de analítica que tus eventos de conversión, agrupa las sesiones por banda de LCP o INP y compara la conversión de cada grupo. El resultado es específico de tu audiencia y de tu checkout, y es la versión que aceptará un director financiero cuando pida un sprint de rendimiento.

#Qué incluye un servicio de monitoreo WordPress

En WPPoland, el trabajo de monitoreo cubre tres cosas.

1. Diseño de monitoreo full-stack: RUM, pruebas sintéticas y APM o trazas de OpenTelemetry conectados en una sola vista, para que un incidente se vea desde el navegador hasta la consulta SQL.
2. Prevención de regresiones: las puertas de Lighthouse CI y Playwright que detienen plantillas lentas o rotas antes de que lleguen a producción.
3. Informes sobre los que se puede actuar: métricas traducidas a las decisiones que debe tomar la dirección, con un responsable para cada presupuesto.

Las herramientas y la implementación se presupuestan de forma individual, porque el coste depende del número de sitios, del volumen de tráfico y del proveedor elegido.

#Por dónde empezar con el monitoreo de rendimiento WordPress

Empieza poco a poco y en orden. Primero, datos de campo de usuarios reales con la librería web-vitals, porque muestran lo que los visitantes experimentan de verdad, y Query Monitor en staging. Después, Lighthouse CI y las comprobaciones de Playwright en el pipeline, más pruebas sintéticas de recorridos desde las regiones donde vendes. Luego, APM o trazas de OpenTelemetry y el slow query log en los endpoints que señalan las dos primeras capas. Cada capa responde a una pregunta que plantea la anterior, y una alerta sin responsable es ruido.

Cuando el monitoreo muestra dónde se va el tiempo, las correcciones vienen después. Nuestra guía de optimización de velocidad de WordPress cubre el trabajo de servidor, caché y frontend, y la guía de optimización de INP profundiza en la métrica de interactividad. Para una revisión práctica de tu sitio, consulta la optimización de velocidad WordPress en WPPoland, o escríbenos desde la página de contacto.