Volver al blog

Core Web Vitals: por qué el monitoring de uptime no es suficiente

· 6 min de lectura

En resumen: El servidor devuelve HTTP 200, el monitoring dice "UP" - y aun así pierdes tráfico de Google. Core Web Vitals (LCP, INP, CLS) miden la experiencia real del usuario. Un web lento es desde la perspectiva de Google "down" igual que uno no disponible.

En resumen: El servidor devuelve HTTP 200, el monitoring dice "UP" - y aun así pierdes tráfico de Google. Core Web Vitals (LCP, INP, CLS) miden la experiencia real del usuario. Un web lento es desde la perspectiva de Google "down" igual que uno no disponible.

Tres métricas CWV

Google introdujo en 2020 los Core Web Vitals como factor de ranking. Desde marzo 2024 los componen:

  • LCP (Largest Contentful Paint) - cuándo aparece el elemento más grande de la página. Bien: ≤ 2,5 s. A mejorar: 2,5-4 s. Mal: > 4 s.
  • INP (Interaction to Next Paint) - con qué rapidez la página reacciona a interacciones del usuario (clic, tap). Reemplazó al FID en marzo 2024. Bien: ≤ 200 ms. A mejorar: 200-500 ms. Mal: > 500 ms.
  • CLS (Cumulative Layout Shift) - cuánto se mueven visualmente los elementos de la página durante la carga. Bien: ≤ 0,1. A mejorar: 0,1-0,25. Mal: > 0,25.

Por qué el monitoring no lo captura

Un monitor uptime clásico envía una solicitud HTTP GET y mide:

  • Código de estado (200 = OK)
  • Time to first byte (TTFB)
  • Opcionalmente keyword match en HTML

Pero no renderiza la página en el navegador. No ve que:

  • El bundle JavaScript tiene 3 MB y el parsing dura 4 segundos
  • La imagen hero se carga sincrónicamente y bloquea el paint
  • La tercera parte (analytics, publicidad) bloquea el main thread
  • El layout salta a medida que se cargan los elementos

Desde la perspectiva del visitante el web es lento e inutilizable - desde la perspectiva del monitoring todo está "UP".

Lab vs field data

CWV se miden de dos formas:

Lab data (Lighthouse, PageSpeed Insights, WebPageTest) - navegador controlado, red definida (típicamente 4G), dispositivo concreto. Reproducible, apropiado para testing de regresión tras deploys.

Field data / RUM (Chrome User Experience Report, JS propio) - recolección de datos de visitantes reales en sus condiciones reales. Lo que Google usa para ranking. Refleja la variabilidad real (cliente móvil 3G desde un tren, desktop fibra, etc.).

Lab data son una buena referencia, field data son la verdad.

Nota: ePulz.io actualmente no rastrea las métricas CWV. Para medirlas, use herramientas especializadas (PageSpeed Insights, WebPageTest, Lighthouse CI o su propio snippet RUM JS). Para regresiones visuales, ePulz.io ofrece un monitor de tipo visual que compara screenshots - esto cubre parcialmente escenarios de "la página se renderiza completamente diferente", pero no mide LCP/INP/CLS.

Estrategia práctica de monitoring

  1. Synthetic uptime check - monitor HTTP clásico cada 1-5 min. Detecta hard downtime, 5xx, certificados caducados.
  2. Medición CWV (fuera de ePulz) - Lighthouse CI en pipeline de despliegue o cron nocturno o Chrome headless una vez al día. Detecta regresión tras despliegue (LCP subió de 1,8 s a 4,2 s tras desplegar un nuevo JS bundle).
  3. Visual regression check - screenshot diff. Detecta cuando la página se renderiza completamente distinta que antes (CSS broken, font fail, JS error).
  4. Real User Monitoring - snippet JS en la página recopila CWV de visitantes reales. Sigues el percentil 75 de las métricas.

Top causas de malos CWV

LCP demasiado alto:

  • Imágenes hero grandes sin priority hint (fetchpriority="high")
  • Servidor lento / TTFB (CDN cache miss, query DB lenta)
  • Blocking resources en <head> (analytics, fonts sin display=swap)
  • Web fonts cargadas desde CDN de terceros sin preconnect

INP demasiado alto:

  • Bundle JS grande bloqueando main thread
  • Event listeners síncronos que hacen trabajo pesado
  • Scripts de terceros lentos (chat widgets, A/B testing)

CLS demasiado alto:

  • Imágenes sin atributos width y height explícitos
  • Anuncios sin espacio reservado
  • Contenidos inyectados dinámicamente sobre el fold
  • Web fonts con FOUT (Flash of Unstyled Text) sin fallback correcto

Impacto SEO

Google usa CWV como tie-breaker. Con contenido igualmente relevante prefiere la página más rápida. En nichos competitivos es decisivo.

Impacto práctico:

  • Un sitio con CWV en el rango "good" tiene en promedio ~20% menor bounce rate
  • El conversion rate sube con cada -100 ms LCP
  • Mobile-first indexing significa que Google evalúa la versión móvil - testea allí

Conclusión

El monitoring de uptime responde a "¿Es el servidor alcanzable?". Core Web Vitals responde a "¿Es el web usable?". Ambas métricas son independientes y ambas necesitas seguir. El servidor puede tener 100% uptime y el web aun así perder tráfico por LCP por encima de 4 segundos.

Monitoring más allá del uptime

Visual regression detecta cambios visuales incluso cuando el servidor devuelve 200. El monitoring del response time captura endpoints lentos.

Probar ePulz.io →

Prueba ePulz.io gratis - 7 días sin tarjeta de crédito.

Crear cuenta