Cómo monitorizar Core Web Vitals en tiempo real
Medir Core Web Vitals una vez está bien. El problema es que una web no se queda quieta. Cambias imágenes, scripts, plantillas, plugins o despliegues y, de repente, algo que iba bien deja de irlo.
Por eso llega un momento en el que medir no basta. Necesitas monitorizar en el tiempo.
Qué significa de verdad “en tiempo real”
No significa ver una gráfica segundo a segundo como si fueras una sala de operaciones.
Significa:
- detectar degradaciones cuando aparecen,
- no enterarte tarde,
- y trabajar con datos suficientemente cercanos a la realidad como para actuar.
Para la mayoría de equipos no se trata de ver un dashboard cada minuto. Se trata de no descubrir el problema cuando ya ha afectado tráfico, leads o conversión.
El problema de depender solo de tests puntuales
Los tests puntuales te dan una foto. Muy útil, sí. Pero sigue siendo una foto.
Y una foto no te responde:
- si el problema empezó ayer o hace dos semanas,
- si afecta a usuarios reales,
- o si solo fue un mal test aislado.
Ahí está la diferencia entre revisión puntual y seguimiento.
Qué deberías vigilar exactamente
LCP
Para saber si el contenido principal sigue cargando con agilidad.
INP
Para detectar si la web se está volviendo lenta al interactuar.
CLS
Para comprobar si el layout empieza a moverse de forma molesta.
Qué datos conviene cruzar además
Los Core Web Vitals rara vez deberían mirarse solos.
Yo los cruzaría con:
- tipo de página,
- móvil vs escritorio,
- cambios recientes,
- tráfico orgánico,
- y conversiones o páginas clave.
Eso evita que conviertas una métrica técnica en una obsesión aislada sin conexión con negocio.
La diferencia entre revisar y monitorizar
Revisar es abrir una herramienta cuando te acuerdas o cuando algo ya va mal.
Monitorizar es tener una lectura continua que te permita ver:
- tendencia,
- contexto,
- y momento del cambio.
Esa diferencia parece semántica, pero cambia completamente cómo gestionas el rendimiento.
Cómo lo haría sin complicarme
Paso 1. Haz una foto inicial
Empieza por el performance checker para ver si ya hay señales claras de problema.
Paso 2. Define qué páginas importan
No todas tienen el mismo peso. Prioriza:
- home,
- landings comerciales,
- categorías,
- o páginas donde se juega conversión.
Paso 3. Vigila evolución, no solo puntuación
Lo importante no es una nota bonita. Lo importante es si el rendimiento empeora o mejora con el tiempo.
Paso 4. Añade alertas
Si el sitio ya importa al negocio, no tiene sentido descubrir una degradación dos semanas tarde.
Paso 5. Revisa tendencias, no solo incidentes
No todo cambio es una crisis. Lo útil es distinguir entre:
- ruido puntual,
- degradación progresiva,
- y problema grave que exige reacción rápida.
Qué umbrales usaría para no volverme loco
No hace falta construir un sistema hiper complejo desde el principio.
Yo separaría:
Señal leve
Pequeña oscilación sin impacto claro.
Señal relevante
Empeoramiento repetido o visible en páginas importantes.
Señal crítica
Degradación clara en páginas de negocio, móvil o bloques que antes iban bien.
Esa clasificación ya te ayuda a evitar sobrerreacción.
Qué páginas vigilaría primero
No empezaría por toda la web si el proyecto es grande.
Priorizaría:
- home,
- landings de captación,
- categorías importantes,
- y plantillas que reciben más tráfico o conversiones.
Ese enfoque da mucho más valor que intentar mirar cien URLs sin jerarquía.
Dónde encaja Weaking
Aquí es donde Weaking tiene un ángulo bastante claro:
- monitoring continuo,
- alertas,
- y RUM real en los planes donde aplica.
La diferencia importante es que no dependes solo de un test simulado. Tienes una capa de seguimiento que te ayuda a entender si el deterioro es real y persistente.
Qué haría con una alerta real
Si una métrica empeora, no tocaría diez cosas a la vez.
Haría esto:
- identificar qué páginas están afectadas,
- comprobar si hubo cambios recientes,
- revisar si el problema es móvil, general o de una plantilla,
- y aplicar un arreglo con validación posterior.
Qué no haría
- no tocaría tres scripts, dos plantillas y un plugin a la vez,
- no borraría módulos útiles por miedo,
- y no asumiría que una mala medición aislada significa crisis técnica.
Qué síntomas suelen acompañar una degradación real
Cuando el problema es serio, muchas veces no viene solo:
- suben tiempos de carga,
- baja respuesta en interacción,
- ciertas páginas convierten peor,
- o Search Console empieza a marcar grupos afectados.
Esa suma de señales da mucha más confianza para actuar que una cifra suelta.
Qué haría yo en una PyME
Montaría un sistema sencillo:
- revisar estado inicial,
- decidir qué URLs importan,
- vigilar cambios,
- y actuar solo cuando la señal tenga sentido.
Eso es importante porque el rendimiento técnico mal gestionado genera dos errores típicos:
- no hacer nada nunca,
- o reaccionar en exceso a cualquier oscilación.
No hace falta convertir esto en un proyecto gigante para empezar a proteger la experiencia real de la web.
Señales de que ya deberías monitorizarlo
- la web genera leads o ventas,
- se hacen cambios frecuentes,
- dependes mucho de móvil,
- o ya has sufrido degradaciones que nadie detectó a tiempo.
También lo valoraría si trabajas con una agencia o varios proveedores y sabes que la web se toca con frecuencia.
Cuándo una foto puntual sí puede bastar
Si la web es pequeña, cambia poco y todavía no depende tanto del orgánico o de la conversión online, una revisión puntual puede ser suficiente al principio.
El problema aparece cuando el proyecto crece y sigues usando la misma lógica de “ya lo miraremos”.
Resumen
- Medir una vez no basta cuando la web cambia con frecuencia.
- Monitorizar Core Web Vitals sirve para detectar degradaciones a tiempo.
- Lo útil es cruzar métricas con URLs críticas y contexto de negocio.
- El valor no está en la nota, sino en la evolución real.
- Si la web ya importa comercialmente, el seguimiento continuo tiene bastante sentido.
Preguntas frecuentes
¿PageSpeed no me basta?
Sirve para una foto inicial. Para seguimiento continuo y detección temprana, se queda corto.
¿Hace falta RUM?
No siempre desde el día uno, pero cuando buscas datos reales de usuario y no solo simulación, aporta mucho valor.
¿Qué página vigilo primero?
La home y las páginas comerciales más importantes.
¿Cuándo pasaría de una foto puntual a monitoring?
En cuanto el rendimiento de la web empiece a tener impacto real en captación, SEO o conversión.
¿Qué hago si solo empeora una página?
Empieza por esa plantilla o URL concreta. Muchas degradaciones importantes nacen en una sola parte del sitio antes de extenderse.