Web Vitals: cómo leer datos de campo y de laboratorio
Comprende qué miden los datos reales y las pruebas controladas, compara LCP, INP y CLS y convierte la evidencia agregada en decisiones.
BotBrowser Team
Quieres la documentación estructurada de Plataforma?
Este artículo forma parte de la biblioteca editorial. Para pasos de configuración, material de referencia y actualizaciones continuas, entra en la sección de docs.
Los datos de campo y de laboratorio responden preguntas diferentes. Los primeros resumen visitas reales; los segundos repiten un recorrido controlado. Ninguno es una puntuación universal ni una señal de identidad. Usa ambos: el campo muestra si un problema afecta a una audiencia y el laboratorio ayuda a reproducir y mejorar una ruta propia.
Condiciones de campo y laboratorio
Los datos de campo se agregan bajo una política de medición y contienen variación de dispositivos, redes, caché, visibilidad y versiones. Un percentil describe una población y una ventana, no a cada visitante ni una causa única.
Los datos de laboratorio son un experimento repetible. Declara URL, entrada, viewport, navegador, clase de red, caché, política de limitación y ventana. Son comparables entre commits, pero no representan automáticamente a todas las audiencias.
const run = { route: '/checkout', viewport: 'mobile', network: 'slow-4g', release: '2026.10.06' };
const marks = ['navigation', 'paint', 'largest-contentful-paint', 'layout-shift', 'event'];
const observer = new PerformanceObserver(list => {
for (const entry of list.getEntries()) {
if (marks.includes(entry.entryType))
report({ run, type: entry.entryType, startTime: entry.startTime, value: entry.value ?? entry.duration });
}
});
observer.observe({ type: 'paint', buffered: true });
observer.disconnect();
El fixture es limitado: nombra ruta y condiciones, selecciona entradas necesarias y se desconecta. Sustituye report por un colector aprobado que agregue y elimine URL o contenido. Consulta Web Vitals y la guía de medición; no conviertas este fixture en datos de campo.
| Pregunta | Evidencia | Decisión |
|---|---|---|
| ¿Hay un problema para visitas reales? | distribución de campo y contexto | priorizar impacto |
| ¿Se reproduce una ruta? | fixture controlado | aislar cambio de código o release |
| ¿Mejoró el release? | laboratorio emparejado y tendencia de campo | publicar, detener o investigar |
| ¿Es comparable? | misma ruta, condiciones y agregación | rechazar comparación desigual |
| ¿Hay suficiente evidencia? | muestra, faltantes y ventana | calificar o recopilar más |
Conceptos de Core Web Vitals
LCP describe cuándo se muestra el mayor contenido relevante. Depende de respuesta, recursos, renderizado y elemento elegido. Un fixture debe fijar contenido y estado para no confundir una imagen distinta con una mejora de red.
INP resume la capacidad de respuesta de las interacciones elegibles. No es solo un clic: prueba validación, menús, diálogos y navegación. Los datos de campo dependen de las acciones que realmente realizan las personas.
CLS describe movimiento visual inesperado. El laboratorio puede revelar dimensiones ausentes, fuentes tardías, banners insertados o contenido que cambia. El campo incluye desplazamiento y navegación; no marques una transición intencional sin revisar la definición y el resultado visible.
Cada métrica necesita contexto. Una página puede tener LCP aceptable e INP deficiente. Conserva métrica, ruta, viewport, navegador, release, ventana y faltantes juntos.
Segmentar con responsabilidad
Segmenta para responder una pregunta de producto. Ruta, release, clase de viewport o red pueden ser útiles si ya pertenecen a la operación. Define el segmento antes de mirar el resultado, exige un tamaño razonable y declara muestras pequeñas. No crees muchas divisiones hasta encontrar una favorable.
No unas métricas a cuentas, URL completas o inferencias de hardware. Agrega en la ventana mínima, oculta consultas y caduca etiquetas temporales. Conserva categoría, contexto y agregado, no una repetición de la visita.
Los datos pueden llegar tarde, estar muestreados o excluir navegadores. Declara población, release y política. Un valor faltante no es cero; separa ausencia de rapidez y nunca inventes una duración.
En laboratorio cambia una variable significativa por comparación. Registra la revisión del fixture y conserva la línea base. Más decimales no hacen más fiable una prueba.
Convertir resultados en decisiones
Empieza por audiencia, ruta y acción. Después cambia una cosa en laboratorio. Para LCP revisa respuesta, recursos y renderizado; para INP, manejadores y trabajo del hilo principal; para CLS, dimensiones, fuentes e inserciones. Mantén corrección y accesibilidad junto a velocidad.
Registra ruta, métrica, contexto de campo, fixture, línea base, cambio, resultado y condición de rollback. Un resultado puede ser detener un release, publicar una mejora o pedir más evidencia. No lo reduzcas a aprobado o rechazado sin motivo.
La capacidad de BotBrowser es repetir recorridos de laboratorio autorizados con navegador, viewport, ruta y red declarados. La limitación de BotBrowser es que no proporciona datos de campo representativos, no elimina la variación del navegador o la red y no garantiza una evaluación para toda audiencia.
Cuando cambie un resultado, repite el fixture mínimo y compara ventanas solapadas. Revisa despliegue, ruta, recursos, caché y release. Conserva evidencia negativa, como una entrada no disponible, y evita ajustar la página solo para pasar un límite.
Lista de release
Registra definición, ruta, fixture, viewport, red, release, caché, ventana, agregación, faltantes y retención. Prueba respuesta lenta, imagen o fuente tardía, interacción con validación, inserción de contenido y navegación. Confirma que la tarea funciona sin medición.
Revisa campo y laboratorio por separado y explica su relación. Una mejora de laboratorio es una señal controlada; una mejora de campo es una tendencia de audiencia. Una diferencia es una pregunta, no prueba de que una fuente sea incorrecta.
Para ampliar el contexto, consulta la guía de optimización de rendimiento y la guía de privacidad de tiempos.
La métrica necesita una población y una ventana.
El viewport forma parte de la condición del laboratorio.
La red declarada debe quedar junto al resultado.
El estado de caché cambia la comparación.
Un valor ausente no es una duración rápida.
El recuento de muestra limita la conclusión.
Una tendencia de campo puede llegar con retraso.
Un fixture debe conservar su revisión.
El navegador probado debe quedar registrado.
La ruta debe tener un estado reproducible.
LCP depende del elemento más grande elegido.
INP requiere una interacción real del producto.
CLS debe considerar toda la navegación.
Una transición intencional no es automáticamente un defecto.
La accesibilidad acompaña a cada decisión de velocidad.
El soporte no debe recibir contenido de usuario.
Las URL se redactan antes de exportar.
Una etiqueta temporal debe caducar.
La evidencia negativa también se conserva.
El rollback se define antes de publicar.
Un gráfico necesita una explicación breve.
La muestra pequeña requiere una advertencia.
El laboratorio no representa automáticamente al campo.
El campo no reproduce por sí solo una causa.
La siguiente prueba debe cambiar una variable.
Fuentes públicas
Artículos Relacionados
Lleva BotBrowser de la investigación a producción
Usa estas guías para entender el modelo y después avanzar hacia validación multiplataforma, contextos aislados y despliegue de navegador preparado para escalar.