Core Web Vitals: qué monitorear y cómo corregir regresiones
Las regresiones de rendimiento casi nunca se envían intencionalmente. Llegan con un cambio aparentemente inocente: un nuevo carrusel de imágenes, una etiqueta de terceros, un cambio de fuente. Para cuando alguien nota la caída en conversiones, la regresión tiene dos semanas. El monitoreo continuo de CWV invierte el ciclo.
Google posiciona sitios según el rendimiento real de los usuarios. LCP, FCP, CLS, TTFB — no son números abstractos, son asesinos de conversiones cuando se desvían. Así se monitorean continuamente y se atrapan regresiones antes de que lleguen a los usuarios.
Qué miden realmente los Core Web Vitals
Las seis métricas que importan, en términos simples:
• LCP (Largest Contentful Paint) — tiempo hasta que el elemento visible más grande termina de renderizar. Bueno < 2,5s. • FCP (First Contentful Paint) — tiempo hasta que cualquier píxel renderiza. Bueno < 1,8s. • CLS (Cumulative Layout Shift) — cuánto salta la página al cargar. Bueno < 0,1. • TTFB (Time to First Byte) — latencia pura de servidor/CDN. Bueno < 0,8s. • TBT (Total Blocking Time) — tiempo que el hilo principal estuvo bloqueado. Bueno < 200ms. • Speed Index — puntuación sintetizada de sensación de velocidad. Bueno < 3,4s.
Por qué mienten los puntajes sintéticos de laboratorio
Lighthouse-CI ejecuta tu página en un dispositivo de gama media simulado con 3G simulada. Es bueno para comparaciones relativas, pero pierde muchos modos de fallo reales. Scripts de terceros que hacen lazy-load según el consentimiento de cookies, ramas A/B que solo se muestran a la mitad de usuarios — Lighthouse nunca los ve.
Una verificación Playwright en navegador completo atrapa los fallos que Lighthouse pierde. SpeedTest ejecuta ambos.
Leer las gráficas: regresiones graduales vs. escalonadas
Dos formas de regresión cuentan historias diferentes.
Una subida gradual de LCP a lo largo de dos semanas suele significar que un solo recurso está creciendo — un feed de imágenes de producto sin paginación, un bundle de analytics que gana features.
Un cambio escalonado en un solo deploy — TTFB salta de 400ms a 1200ms de la noche a la mañana — es una causa directa a nivel de código. Correlaciona la marca de tiempo con tus entradas DeployLog.
Umbrales de alerta por métrica que sí funcionan
Un umbral por métrica, alertando al cruzar el límite 'poor' en vez de un llamativo 'regresó un 10%':
• LCP > 4,0s — alerta • FCP > 3,0s — alerta • CLS > 0,25 — alerta • TTFB > 1,8s — alerta • TBT > 600ms — alerta
Empareja con un umbral de advertencia en la línea 'needs improvement' de Google.
Qué hacer cuando CWV regresa tras un deploy
El playbook cuando una métrica roja se dispara justo después de un release:
1. Abre la traza Playwright de la ejecución fallida. 2. Encuentra el recurso nuevo o modificado. 3. Si es de terceros, revisa su página de estado y considera `async` o `defer`. 4. Si es tu código, correlaciona con DeployLog y revierte o hotfixea. 5. Añade el patrón de fallo a tu checklist pre-deploy.
Guía de producto
Uptime Monitoring
AlertsDock gives teams uptime monitoring for websites, APIs, TCP checks, DNS checks, SSL expiry, and fast alert routing without enterprise overhead.
Leer guíaPágina alternativa
Better Stack Alternative
Compare AlertsDock with Better Stack for teams that want a more focused monitoring product covering uptime, cron jobs, status pages, and webhooks.
Ver comparaciónMore articles
Changelogs generados por IA: convierte commits de Git en notas de versión automáticamente
Escribir notas de versión es la tarea que nadie quiere. DeployLog lee tus commits en cada push y genera changelogs limpios y legibles agrupados por tipo — no se requiere Anthropic, funciona con Groq, Gemini, Cloudflare, OpenRouter u Ollama autohospedado.
Deja de enviar archivos .env por correo: una guía práctica de bóvedas cifradas
El DATABASE_URL de tu equipo está en los DMs de Slack de alguien. Tu STRIPE_SECRET_KEY vive en una página de Notion. Así se filtran los secretos. Aquí está la higiene que deberías haber tenido desde el día uno — y cómo las bóvedas cifradas la hacen indolora.
Playbooks de incidente que se auto-ejecutan: de runbook a runtime
Escribir un runbook que nadie lee a las 3am es desperdicio. Escribir uno que se auto-arranca el instante en que un monitor cae y registra cada paso es un multiplicador de fuerza.