Cómo monitorear el rendimiento de varios sitios y detectar regresiones

Para seguir las Core Web Vitals de muchos sitios y detectar las regresiones a tiempo, una agencia necesita dos fuentes que trabajen juntas. Los datos de campo dicen si el visitante real tiene un problema: CrUX, de Google, da la visión general gratis, pero con un retraso de hasta 28 días, y una recogida propia (RUM) muestra el efecto de un despliegue en horas y señala la causa. Las pruebas de laboratorio programadas, con varias ejecuciones y comparación por la mediana, detectan la regresión antes o justo después de publicar. Encima de eso van los presupuestos de rendimiento por tipo de página, las alertas ligadas al momento del despliegue, el desglose por plantilla de página y por dispositivo, y un informe que separa los datos de campo de los resultados de prueba.

El texto corresponde a las herramientas y los límites públicos de Google en octubre de 2026. No compara servicios comerciales; habla de categorías de herramienta y de lo que permite cada fuente de datos.

Campo y laboratorio cumplen funciones distintas

Los datos de campo vienen de visitas reales. Los datos de laboratorio vienen de una carga simulada, con dispositivo, red y ubicación fijos. web.dev recomienda usar el campo para medir y priorizar y el laboratorio para diagnosticar (web.dev, herramientas de Core Web Vitals). Los dos difieren por motivos conocidos: caché vacía en la prueba, un único dispositivo y una única red, ausencia de desplazamiento y clics, contenido personalizado y el hecho de que el campo es una distribución de 28 días (web.dev, diferencias entre laboratorio y campo).

En una cartera de sitios eso se convierte en una regla de trabajo: la alerta que le importa al cliente es la de campo, y la prueba de laboratorio sirve para detectar la regresión pronto y explicar la causa. La comparación completa entre las fuentes está en Lighthouse, CrUX y RUM; los umbrales de cada métrica, en la guía de Core Web Vitals.

Datos de campo de CrUX: qué ofrece cada acceso

CrUX (Chrome User Experience Report) tiene tres formas de acceso programático. Se diferencian en frecuencia, granularidad y coste.

Fuentes: CrUX API, CrUX History API y CrUX en BigQuery. Para ver la serie semanal sin programar, CrUX Vis muestra los datos de la History API en gráficos.

Para saber si la cuota alcanza, haz la cuenta. Un ejemplo: 40 sitios, cada uno con el origen y 5 URL importantes más, consultados para móvil y escritorio, suman 480 consultas al día, lo que cabe en poco más de 3 minutos con el límite de 150 por minuto.

Hay tres limitaciones que pesan en el monitoreo:

1. La ventana de 28 días lo suaviza todo. Una regresión publicada hoy entra poco a poco en la media y solo aparece por completo semanas después. Eso sirve para un informe de tendencia, no para una alerta de despliegue (web.dev).

2. No todos los sitios ni todas las URL tienen datos. Solo entran páginas y orígenes que se pueden descubrir públicamente y tienen visitas suficientes; el mínimo no se publica. Los sitios pequeños de la cartera pueden no tener datos de URL, ni siquiera de origen (metodología de CrUX).

3. Solo entran los usuarios de Chrome en escritorio y en Android que cumplen los criterios de recogida. Las visitas desde otros navegadores no aparecen (metodología de CrUX).

RUM propio: datos del día y con la causa

RUM (real user monitoring) es la recogida que hace un script en el propio sitio, que envía las métricas de cada visita a un servidor tuyo o de un servicio. web.dev recomienda montar ese conjunto propio de datos y usar CrUX como comparación (web.dev). Una base lista para usar es la biblioteca web-vitals, del equipo de Chrome, que mide LCP, INP, CLS, FCP y TTFB igual que los mide Chrome para las herramientas de Google. Ocupa unos 3 KB comprimida con brotli; la versión con atribución añade unos 1,5 KB e indica el elemento o la interacción que causó cada valor (web-vitals).

Algunas precauciones de implementación, según la documentación de la biblioteca y web.dev:

• Envía los datos cuando la página queda oculta (evento visibilitychange), con navigator.sendBeacon(), y no en unload ni en beforeunload (web-vitals).

• Envía también la información de diagnóstico: el elemento del LCP, el objetivo y el tipo de la interacción del INP, el elemento del mayor desplazamiento del CLS. Al agregar esos objetivos entre todos los visitantes, aparecen los elementos que más pesan en el p75 (web.dev, depurar el rendimiento en campo).

• Los valores de LCP, INP, FCP y TTFB funcionan en Chrome, Firefox y Safari; el CLS, por ahora, solo en los navegadores Chromium (web-vitals). Al comparar el RUM con CrUX, filtra por Chrome para comparar la misma población.

• El script recoge datos de los visitantes. No envíes en el beacon nada que identifique a la persona, como el correo electrónico o parámetros de URL con datos personales, y confirma con quien se ocupa de la privacidad del cliente si el script tiene que figurar en la política del sitio.

Con RUM puedes comparar el p75 de antes y después de un despliegue en uno o dos días, siempre que la página tenga visitas suficientes para que la muestra tenga sentido.

Pruebas de laboratorio programadas sin dejarse engañar por la variación

Ejecutar Lighthouse una vez al día en cada sitio y alertar cuando baja la puntuación suele generar falsas alarmas. La documentación de Lighthouse enumera las fuentes de variación entre ejecuciones: contenido de la página que cambia (pruebas A/B, anuncios), la red local, el hardware de la máquina de prueba, la competencia por la CPU con otros procesos, el servidor web y el propio navegador. La recomendación es ejecutar varias veces y mirar valores agregados, como la mediana, en lugar de un resultado aislado. Según el mismo documento, la mediana de 5 ejecuciones es el doble de estable que una sola ejecución (Lighthouse, variabilidad).

Para las pruebas programadas de muchos sitios, el mismo documento recomienda:

1. Usar máquinas dedicadas, con al menos 2 núcleos (4 recomendados) y 2 GB de memoria (de 4 a 8 GB recomendados), y evitar instancias compartidas o con CPU intermitente.

2. No ejecutar varios Lighthouse a la vez en la misma máquina. En una cartera grande, eso significa cola, no paralelismo en la misma instancia.

3. Mantener la configuración igual en todas las ejecuciones: el mismo perfil de dispositivo, la misma limitación de red y CPU y la misma ubicación de prueba. La limitación simulada reduce la variación causada por la red.

4. Aislar lo que se pueda: desactivar extensiones y antivirus en la máquina de prueba y, si es posible, probar una versión de la página sin anuncios ni pruebas A/B en marcha.

El laboratorio no mide el INP, porque no hay un visitante haciendo clic. El sustituto en Lighthouse es el TBT (Total Blocking Time), el tiempo en que el hilo principal estuvo bloqueado durante la carga (web.dev). Una subida del TBT es una buena señal de que el INP de campo puede empeorar, pero no es el INP.

Presupuestos de rendimiento por tipo de página

Un presupuesto de rendimiento es un conjunto de límites para las métricas que afectan al rendimiento del sitio. web.dev describe tres tipos: límites de cantidad (peso de imágenes y scripts, número de fuentes, scripts de terceros), límites de tiempo en métricas centradas en el usuario y límites de puntuación en herramientas como Lighthouse. La recomendación es combinar la cantidad con las métricas de usuario, fijar límites por tipo de página y aplicarlos en el proceso de build; cuando se supera un límite, las salidas son optimizar, quitar o no añadir el recurso nuevo (web.dev, presupuestos de rendimiento). Lighthouse CI, un proyecto de código abierto de Google, ejecuta Lighthouse en cada commit y comprueba los presupuestos de scripts e imágenes (Lighthouse CI).

El artículo de web.dev sobre presupuestos es de 2018 y cita métricas anteriores a las Core Web Vitals. Una forma actual de aplicar la misma idea, y aquí es una recomendación, no una regla de Google:

• Para las métricas de tiempo, usa los umbrales de "bueno" de las Core Web Vitals (LCP hasta 2,5 s, CLS hasta 0,1) en el laboratorio y en el RUM, y el TBT como señal para el INP.

• Para la cantidad, parte de lo que tiene hoy cada plantilla de página y fija un tope un poco por encima, para que un script o una imagen nueva no pase sin que nadie lo note.

• Defínelos por plantilla de página. Una página de producto y un artículo de blog tienen pesos y elementos LCP distintos; un presupuesto único para todo el sitio o queda demasiado holgado o salta todo el tiempo.

El presupuesto de cantidad no encaja bien en sitios donde el cliente publica contenido pesado con frecuencia sin pasar por el equipo; en ese caso, el límite se convierte en motivo de conversación sobre el proceso editorial, y la alerta de campo pesa más.

Alertas de regresión después de un despliegue

Una alerta útil relaciona el cambio en la métrica con un evento: un despliegue, una actualización de plugin, una etiqueta de marketing nueva. Un proceso posible con las fuentes anteriores:

1. Registra cada despliegue con fecha, hora, sitio y versión. Sin eso, la investigación empieza por la pregunta "¿qué cambió?".

2. Antes de publicar, ejecuta el laboratorio (5 ejecuciones, mediana) en las URL representativas de cada plantilla de página afectada, en el entorno de pruebas si lo hay.

3. Después de publicar, ejecútalo otra vez en producción, con la misma configuración, y compara las medianas. Alerta cuando la mediana supere el presupuesto o salga de la franja de "bueno", no ante cualquier oscilación de la puntuación.

4. En el RUM, compara el p75 de la ventana posterior al despliegue con el de la ventana anterior, por plantilla de página y por dispositivo, en cuanto haya muestra suficiente.

5. Sigue CrUX en las semanas siguientes para confirmar que la mejora o el empeoramiento llegó a los datos que usa Google.

Los criterios de los pasos 3 y 4 son una recomendación. Google no define qué cuenta como regresión; la idea es evitar que una variación normal entre ejecuciones se convierta en alerta.

Segmentar por plantilla de página y por dispositivo

Las páginas de la misma plantilla comparten código: todas las páginas de producto usan el mismo componente de galería, todas las entradas cargan el mismo bloque de anuncios. Por eso un problema de rendimiento tiende a repetirse en toda la plantilla. Search Console trabaja así: el informe de Core Web Vitals agrupa las URL con una experiencia parecida, da a cada grupo un estado distinto para móvil y escritorio y usa la peor métrica como estado del grupo (ayuda de Search Console).

En la práctica, para cada sitio de la cartera:

• Haz una lista de las plantillas de página que generan tráfico o ingresos (inicio, categoría, producto, artículo, checkout) y elige una o dos URL representativas de cada una para el laboratorio.

• En el RUM, envía el nombre de la plantilla junto con cada métrica, para agregar por plantilla en lugar de por URL.

• Separa siempre móvil y escritorio. Las pantallas distintas muestran elementos distintos, así que el elemento del LCP y el origen del CLS pueden cambiar de uno a otro (web.dev).

Informe para el cliente

Una estructura posible para el informe mensual:

• El p75 de LCP, INP y CLS en móvil y escritorio, con la franja (bueno, necesita mejorar, deficiente) y la fuente de los datos.

• La tendencia de las últimas semanas, que la CrUX History API y CrUX Vis ofrecen para hasta 40 semanas.

• Lo que cambió en el periodo (despliegues, etiquetas nuevas, correcciones) y el efecto observado en el RUM.

• Lo que queda para el siguiente ciclo, con la métrica y la plantilla de página afectadas.

Dos precauciones. La primera: no uses la puntuación de Lighthouse como cifra principal. web.dev recomienda priorizar las Core Web Vitals de campo frente a las puntuaciones de Lighthouse (web.dev), y la puntuación varía entre ejecuciones. La segunda: no prometas una mejora de posición en Google. La documentación de Google dice que los sistemas de clasificación usan las Core Web Vitals, pero que los buenos resultados no garantizan el primer puesto y que la búsqueda prioriza el contenido más relevante (Google Search Central).

Cómo hacerlo con WebVyze

En los planes de pago de WebVyze, cada sitio de la cartera tiene auditorías e informes programados y alertas por correo electrónico, push, Slack, Teams, Google Chat, WhatsApp o Telegram. El script de visitantes reales (unos 10 KB, basado en la biblioteca web-vitals) registra LCP, INP y CLS de cada visita con la causa. Cada problema se convierte en una issue con la evidencia y una guía de corrección, y solo se marca como resuelta después de que WebVyze lo vuelve a verificar. Desde el plan Growth, el portal del cliente da acceso a los resultados a quien contrató a la agencia. Para una consulta rápida sin registro, el test de Core Web Vitals muestra los datos de CrUX de hasta 10 URL, en móvil y escritorio. WebVyze solo lee páginas públicas y no modifica los sitios.