Guías

Ejecutas Lighthouse, obtienes 100, publicas. Un mes después Search Console te dice que esa misma URL suspende su evaluación de Core Web Vitals. Nada se rompió entretanto, y ninguna de las dos herramientas miente. Responden a preguntas distintas.

La documentación de Google traza la línea con claridad. Los datos de laboratorio son **«datos recogidos en un entorno controlado, con ajustes de dispositivo y de red predefinidos»**. Los datos de campo son **«datos recogidos de los usuarios reales que visitan tu sitio»**, lo que también se llama Real User Monitoring; para los Core Web Vitals proceden del Chrome User Experience Report.

Los datos de campo son una distribución, no un número

La consecuencia más importante es estructural, y es la que más se pasa por alto: los datos de campo **no son un número único**. Son una distribución. Las herramientas que publican una puntuación de campo de Core Web Vitals toman el **percentil 75** de las cargas reales en una ventana móvil de **28 días**. Tu prueba de laboratorio es una carga, en un dispositivo, en una conexión. Tu puntuación de campo es lo que tres cuartas partes de tus visitantes vivieron o mejor, a lo largo de un mes.

Eso ya explica la mayor parte de la diferencia. Pero las causas varían según la métrica, y saber cuál estás mirando indica dónde buscar.

Por qué divergen, métrica a métrica

En el [Largest Contentful Paint](/es/articles/que-es-el-largest-contentful-paint-lcp), el propio elemento LCP puede no ser el mismo. El tamaño de la ventana gráfica, el contenido personalizado, las pruebas A/B, las fuentes instaladas y los fragmentos de URL pueden cambiar qué elemento cuenta como el mayor. El estado de la caché también difiere: una prueba de laboratorio arranca en frío, mientras que quien vuelve puede tener recursos en caché. Y la restauración desde la caché de avance/retroceso es casi instantánea para un usuario real, algo que ninguna prueba de laboratorio reproduce.

• Laboratorio: entorno controlado, dispositivo y red predefinidos, una ejecución, reproducible
• Campo: usuarios reales, dispositivos reales, conexiones reales, publicado en el percentil 75 sobre 28 días móviles
• Métricas solo de laboratorio: Speed Index, Total Blocking Time (diagnósticos, no Core Web Vitals)
• El estado de la caché, la caché de avance/retroceso, la ventana gráfica y la personalización difieren entre ambos
• Google: cuando se dispone de ambos, priorizar sobre los datos de campo

En el [Interaction to Next Paint](/es/articles/que-es-inp-interaction-to-next-paint), la razón es más de fondo: una prueba de laboratorio **no puede saber cuándo un usuario decidirá interactuar**, ni con qué. Por eso existe el [Total Blocking Time](/es/articles/que-es-el-total-blocking-time) como aproximación del lado del laboratorio, y por eso mismo esa aproximación es imperfecta. El TBT no captura el retardo de 300 ms al tocar que todavía afecta a las páginas sin una ventana gráfica optimizada para móvil.

En el [Cumulative Layout Shift](/es/articles/que-es-el-cls), el laboratorio suele observar solo los desplazamientos por encima del pliegue y durante la carga. Los usuarios reales se desplazan. Las imágenes e iframes de carga diferida sin dimensiones reservadas mueven la página mucho después de que la prueba de laboratorio haya dejado de mirar, y los anuncios y los bloques personalizados aterrizan de forma distinta para cada uno.

Cuál publica realmente Google

¿Sobre cuál actuar entonces? Google responde con claridad: **si dispones de ambos, son los datos de campo los que deben guiar tus prioridades.** Son los que recoge la evaluación de Core Web Vitals, y los Core Web Vitals forman parte de la señal de experiencia de página. Una puntuación de laboratorio en verde es una hipótesis. Los datos de campo son el veredicto.

El laboratorio no es inútil, es diagnóstico

Eso no vuelve inútil el laboratorio, y creerlo es el error simétrico. Los datos de campo te dicen **que** hay un problema y para quién; no te dirán qué script bloqueó el hilo principal. Las herramientas de laboratorio son reproducibles y atribuibles, que es justo lo que hace falta una vez que el campo ha señalado una página. Algunas métricas, como el [Speed Index](/es/articles/que-es-el-speed-index) y el Total Blocking Time, solo existen en el laboratorio y son diagnósticos por diseño.

El punto ciego: cuando CrUX no tiene nada de ti

Conviene conocer un límite antes de apoyarse por completo en el campo. CrUX solo recoge datos desde Chrome, y no desde Chrome en iOS ni desde los WebView de Android. Solo cuenta a los usuarios que han activado el envío de estadísticas de uso, sincronizan su historial de navegación y no tienen definida una frase de contraseña de sincronización. La página debe ser públicamente detectable y debe superar un número mínimo de visitantes que Google deliberadamente no publica. Una página por debajo de ese umbral sencillamente no tiene datos de campo, y un sitio joven o de poco tráfico puede no tenerlos en ninguna parte. Ese es el hueco que llena tu propio Real User Monitoring: tus páginas, todos los navegadores, desde la primera visita y no desde la milésima.

El orden que funciona

El orden práctico es, por tanto: leer el campo para decidir **dónde** trabajar, usar el laboratorio para averiguar **qué** cambiar, y volver al campo veintiocho días después para comprobar que de verdad se ha movido. Todo lo demás es optimizar una cifra que nadie experimenta. Para las palancas concretas una vez que sabes dónde excavar, empieza por [mejorar tus Core Web Vitals](/es/articles/mejorar-los-core-web-vitals).