Los datos de campo describen visitas que ya ocurrieron; los datos de laboratorio describen una prueba controlada. PageSpeed Insights los reúne, pero abarcan dispositivos, comportamientos y periodos diferentes. Usa los primeros para entender experiencias reales y las grabaciones de laboratorio para investigar causas y comprobar cambios.
Una puntuación verde de Lighthouse no demuestra que los visitantes superen Core Web Vitals. Una prueba sintética lenta tampoco invalida buenos resultados reales. Identifica primero qué representa cada número. La introducción a Core Web Vitals explica los indicadores; aquí explicamos sus diferencias de medición.
Empieza por la población y la pregunta
CrUX, Chrome User Experience Report, agrega experiencias de usuarios de Chrome que cumplen sus requisitos. No es un censo de todas las visitas. La participación depende de ajustes del navegador y entornos compatibles; cada página necesita suficientes observaciones aptas para aparecer. Google no publica una cifra universal de tráfico que garantice la inclusión.
También cuenta la elegibilidad de la página. Los requisitos incluyen que sea públicamente descubrible e indexable: tener visitas no implica que una cuenta privada deba aparecer. Tampoco puedes enviar manualmente una URL para forzar su inclusión. La ausencia de datos significa que esa fuente no responde a la pregunta, no que la página sea rápida o lenta.
Lighthouse carga una URL en un navegador configurado y ofrece diagnósticos sin esperar visitas, incluso antes de publicar. Sirve para desarrollo, pero representa un escenario, no la distribución de tu audiencia.
Esta comparación distingue las preguntas que responde cada fuente.
| Aspecto | Datos de campo de CrUX en PSI | Navegación de laboratorio con Lighthouse |
|---|---|---|
| Población | Visitas reales aptas de Chrome | Una carga controlada |
| Periodo | Los 28 días anteriores | La prueba actual |
| Dispositivos | Equipos reales agrupados por tipo | Perfil configurado y limitaciones simuladas |
| Comportamiento | Experiencias durante visitas reales | Navegación y periodo observado |
| Utilidad | Localizar problemas persistentes | Diagnosticar y comparar cambios |
| Límite | Agregación y requisitos de inclusión | Un escenario no representa todos los recorridos |
No conviertas el percentil en un promedio
El valor de campo mostrado suele ser el percentil 75, o p75. Un LCP de 2,4 segundos en p75 significa que al menos el 75% de las experiencias registradas alcanzó ese punto en 2,4 segundos o menos. No significa que todos esperaran eso ni que fuera la media aritmética. Es un ejemplo explicativo, no una medición real.
Los umbrales buenos son LCP de hasta 2,5 segundos, INP de hasta 200 milisegundos y CLS de hasta 0,1. Evalúa móvil y escritorio por separado. Un buen escritorio no compensa un móvil deficiente; los umbrales son iguales para ambos.
Revisa también la distribución. Un p75 apenas dentro de la zona buena puede coexistir con una cola lenta considerable. Investiga si se concentra en una región, plantilla o interacción antes de dar por terminado el trabajo.
La comparación de mediciones de Google aporta el contexto. Al compartir un valor, conserva el percentil y la población a la que corresponde.
Confirma que el resultado de campo pertenece a esa URL
PSI intenta mostrar datos por URL y puede recurrir al origen si no hay suficientes observaciones. El origen combina protocolo, nombre de host y puerto. No es la ruta completa ni todos los subdominios de una organización.
El origen puede reunir plantillas distintas: productos lentos y artículos rápidos, por ejemplo. Si el campo describe ese conjunto y el laboratorio un artículo, la discrepancia no demuestra un error.
Antes de abrir una incidencia, guarda URL solicitada y final, dispositivo, alcance y fechas. “LCP móvil malo” no permite saber qué población tiene el problema. No renombres un resultado de origen como dato de página en un panel.
Si falta evidencia para la URL exacta, indícalo y conserva el contexto del origen aparte. La guía del informe de PageSpeed Insights explica dónde comprobarlo.
Entiende qué reproduce la limitación de recursos
Lighthouse puede usar simulación para estimar el rendimiento con determinadas restricciones de CPU y red. Otras configuraciones emplean métodos diferentes. Lee los ajustes: compartir el nombre Lighthouse no garantiza condiciones idénticas.
El ordenador de desarrollo, extensiones, carga en segundo plano y ubicación influyen. Hay variaciones entre ejecuciones sin cambios de código. Guarda versiones de navegador y Lighthouse, estrategia, entorno y valores individuales, y compara varias ejecuciones equivalentes.
La prueba también tiene un estado. Una navegación nueva puede encontrar vacía la caché del navegador mientras un visitante habitual reutiliza recursos. O el laboratorio recibe una respuesta CDN caliente que otro visitante no recibe. Define qué caché está “fría”; borrar almacenamiento local no vacía el CDN.
La simulación permite localizar trabajo costoso, pero no promete reproducir un teléfono concreto. Selecciona escenarios adicionales basándote en la audiencia, en lugar de repetir el perfil predeterminado hasta conseguir verde.
Investiga el indicador que explica la discrepancia
Para LCP, compara el elemento mayor y su ruta de entrega. La anchura puede seleccionar otra imagen o convertir otro bloque en el mayor. Distancia, respuesta del servidor, descubrimiento y renderizado cambian el cuello de botella. Un recurso pequeño de escritorio quizá no represente el móvil.
Para CLS, prolonga el recorrido: desplázate hasta inserciones tardías, espera anuncios, cambia el consentimiento y vuelve con Atrás. Una auditoría de carga puede omitir movimientos posteriores. El título desplazado puede ser víctima del contenedor superior, no el culpable.
Para INP, prueba interacciones. Una navegación normal de Lighthouse no produce la distribución real de INP de CrUX. TBT puede mostrar presión sobre el hilo principal durante la carga, pero no sustituye INP. Las herramientas interactivas controladas sí pueden medir latencia; sus límites son el escenario y la cobertura.
Reproduce con DevTools abrir un menú, escribir en el buscador o cambiar una opción de producto. Una carga limpia puede preceder a un primer clic costoso. Guarda acción, objetivo y traza para que otra persona pueda repetirlo.
Ten presente la ventana móvil después de publicar
CrUX en PSI representa los 28 días anteriores y se actualiza diariamente. Inmediatamente después de corregir algo, buena parte de la ventana sigue describiendo la versión antigua. Laboratorio nuevo y campo histórico responden a preguntas temporales distintas.
Marca la publicación en el seguimiento. Busca evidencia reciente en tus propias mediciones y pruebas comparables mientras se incorporan visitas. No prometas un cambio tras un número exacto de horas ni deduzcas fracaso solo por una etiqueta todavía mala.
La audiencia también cambia. Una campaña que atrae redes más lentas puede alterar la distribución pese a mejorar el código. Compara segmentos cuando puedas y reconoce la incertidumbre si el agregado no permite separar causas.
Añade RUM cuando la agregación no localice la causa
El seguimiento de usuarios reales, RUM, puede recoger métricas propias con contexto como plantilla y versión. Diseña recogida, consentimiento, conservación y acceso antes de instalarlo. No envíes datos de cuentas, formularios ni URLs completas con parámetros sensibles.
La biblioteca oficial web-vitals maneja detalles del ciclo de vida. En un proyecto que instala y empaqueta esa dependencia, este módulo registra métricas compatibles localmente, sin enviarlas a un servidor.
import {onCLS, onINP, onLCP} from 'web-vitals';
function reportMetric(metric) {
console.log({
name: metric.name,
value: metric.value,
id: metric.id,
rating: metric.rating,
navigationType: metric.navigationType
});
}
onCLS(reportMetric);
onINP(reportMetric);
onLCP(reportMetric);Sustituye el registro por un endpoint aprobado solo después de diseñar el backend. Una métrica puede notificarse varias veces al cambiar; define cómo actualizar registros sin duplicarlos. Cada callback no es una visita nueva. INP ausente puede indicar que no hubo interacción apta: no lo conviertas en cero.
RUM no tiene por qué coincidir con CrUX. Navegadores, muestreo, consentimiento, definiciones de navegación e iframes pueden diferir. Usa la variante de atribución cuando necesites más diagnóstico y revisa qué información contiene antes de transmitirla.
Usa cada resultado para la decisión que permite
Para un cambio técnico, reproduce el recorrido y demuestra la mejora con condiciones comparables. Para evaluar visitantes, sigue datos de campo con alcance y periodo explícitos. Para Search, distingue Core Web Vitals de la puntuación Lighthouse: esta no es una nota de posicionamiento.
Elige un indicador, una plantilla y un recorrido repetible. Guarda la referencia, modifica la causa sospechada y comprueba funcionamiento y tiempos. Usa el analizador PageSpeed cuando esté habilitado y las guías de Core Web Vitals para continuar. El resultado útil es una discrepancia explicada que conduce a una corrección comprobada.
