Core Web Vitals: cómo combinar datos de campo y laboratorio

Lectura ejecutiva

Conclusiones principales

• Core Web Vitals son métricas de campo evaluadas en el percentil 75.
• Lighthouse no mide INP real sin interacciones de usuarios.
• Campo confirma el problema; laboratorio ayuda a explicar la causa.
• Prioriza por página, recorrido, alcance y confianza.

Core Web Vitals mide carga, respuesta y estabilidad visual. Según web.dev, una buena experiencia requiere LCP de hasta 2,5 segundos, INP de hasta 200 milisegundos y CLS de hasta 0,1, evaluados en el percentil 75 y separados entre mobile y desktop.

Son métricas de campo. Los datos reales muestran el síntoma agregado, pero rara vez apuntan por sí solos a la línea de código, imagen o tercero responsable. Las pruebas de laboratorio hacen lo inverso: ayudan a depurar una ejecución, pero no representan toda la población.

Combinar ambas fuentes transforma una nota en diagnóstico.

Qué son datos de campo

Provienen de visitas reales. Chrome User Experience Report (CrUX) agrega experiencias elegibles de Chrome durante una ventana. Search Console y PageSpeed Insights usan estos datos en distintas vistas.

Campo captura diversidad de dispositivos, redes, ubicación, caché, páginas de entrada, interacciones, scripts condicionales y personalización. Esa diversidad acerca la señal a la experiencia y reduce la atribución causal directa.

Qué son datos de laboratorio

Laboratorio ejecuta la página bajo condiciones controladas. Lighthouse, DevTools y WebPageTest pueden simular red, CPU, viewport y caché, y mostrar waterfall, tareas largas, dependencias y elementos responsables.

Sirve para reproducir problemas, comparar antes y después, encontrar recursos bloqueantes, inspeccionar descubrimiento de LCP, localizar tareas largas, observar cambios de layout y crear pruebas de regresión.

Como la condición es artificial, el resultado varía y no debe presentarse como “la velocidad del sitio” para todos.

Cómo aparece cada métrica

LCP

Puede medirse en campo y laboratorio. El elemento cambia con viewport, contenido, cookies, experimentos y dispositivo. Compara el candidato del laboratorio con atribución propia de campo cuando sea posible.

INP

Depende de interacciones reales durante la visita. Una carga automatizada sin clics no produce INP representativo. Lighthouse usa Total Blocking Time como señal relacionada con la thread principal, pero TBT no es INP.

CLS

Puede observarse en ambos. En campo, cambios ocurren tras interacciones o en visitas largas. El laboratorio puede terminar antes de un banner, anuncio o contenido tardío.

Lee PageSpeed Insights en dos partes

Primero suele mostrar experiencia de CrUX y después diagnóstico de Lighthouse.

Pregunta:

1. ¿Los datos son de la URL o solo del origen?
2. ¿Qué dispositivo está seleccionado?
3. ¿Es una ventana agregada o una ejecución?
4. ¿Qué métrica falla en campo?
5. ¿Qué elemento o cadena aparece en laboratorio?
6. ¿La oportunidad sugerida se conecta con el fallo?
7. ¿La URL representa el template afectado?

Este orden evita corregir cualquier elemento rojo sin probar su relación con el problema.

Por qué URL y origen no coinciden

Una URL puede tener datos propios si existe volumen. De lo contrario, la herramienta muestra el origen, que mezcla templates y recorridos.

Una home rápida puede esconder productos lentos. Una campaña pesada puede empeorar el agregado. Agrupa por home, categoría, producto, artículo, búsqueda, checkout y landing. El diagnóstico suele pertenecer al template.

Un flujo en seis pasos

1. Confirma la señal de campo. Identifica métrica, dispositivo, grupo y período. Si no hay datos, marca desconocido y considera web-vitals.
2. Selecciona URLs representativas. Incluye casos buenos y malos del mismo template.
3. Reproduce en laboratorio. Mantén condiciones, repite y observa mediana o distribución.
4. Encuentra la causa. Para LCP, elemento y descubrimiento; para INP, interacción y tareas; para CLS, víctima y causante.
5. Implementa un cambio delimitado. No mezcles CDN, refactor y rediseño si quieres saber qué funcionó.
6. Verifica en los plazos correctos. Laboratorio reacciona tras deploy; campo necesita nuevas visitas y actualización.

Prioriza páginas y correcciones

Combina alcance, importancia del recorrido, gravedad y confianza. Una corrección simple de imagen en todos los productos puede superar una refactorización compleja en una sección menor. La nota más baja no siempre es la mayor oportunidad.

Errores comunes

• “La nota bajó, entonces el sitio empeoró”: una ejecución varía. Confirma tendencia.
• “Pasamos en laboratorio, entonces pasamos en campo”: laboratorio es una condición.
• “La mayor economía estimada es la causa”: conecta la sugerencia con el elemento crítico.
• “Rendimiento prueba conversión”: elimina una fricción, pero el impacto depende de página, intención y oferta.

Convierte métricas en backlog

Observación: productos fallan LCP móvil en campo; en laboratorio la imagen se descubre después del JavaScript del carrusel. Acción: renderizar la primera imagen en HTML, aplicar srcset y priorizar solo el candidato. Aceptación: sigue responsiva, LCP mejora en pruebas repetidas y campo se acompaña después del deploy.

La visión general de Core Web Vitals explica las métricas. Los diagnósticos profundizan LCP, INP y CLS.

Campo y laboratorio no compiten. Uno muestra lo que vivió una población; el otro ayuda a explicar una ejecución. Una decisión confiable usa ambos.

Respuestas directas

Preguntas frecuentes

¿Por qué PageSpeed Insights muestra datos distintos de Lighthouse?

La parte de campo puede mostrar datos agregados de CrUX, mientras Lighthouse ejecuta una prueba con dispositivo y red simulados. Fuentes, períodos y condiciones son distintos.

¿Una página sin datos de campo falló?

No. Puede no existir volumen elegible suficiente. El estado correcto es desconocido; usa medición propia y laboratorio como complemento.

¿Necesito llegar a 100 en Lighthouse?

No. La puntuación ayuda a depurar, pero debe subordinarse a experiencia real, estabilidad entre pruebas y objetivos de la página.