Por qué campo y laboratorio nunca coinciden

“Lighthouse me da 1,8 segundos de LCP y PageSpeed Insights dice que mis usuarios tienen 4,3. ¿Cuál miente?” Ninguno. Hay al menos diez causas identificadas de discrepancia, la mayoría con efectos de segundos, y saber cuál te está afectando es un ejercicio de diagnóstico en sí mismo. Esta lección las ordena por magnitud y da la señal que delata cada una.

Las causas, ordenadas por magnitud

1. La mezcla de dispositivos y redes. El campo agrega miles de combinaciones; el laboratorio elige una. Si tu laboratorio emula móvil de gama media a 150 ms de latencia y tu tráfico real es 70% escritorio con fibra, tus números de campo serán mucho mejores. Y al revés. Efecto: de segundos. Señal que lo delata: la discrepancia desaparece o se invierte al segmentar el campo por tipo de dispositivo.

2. El estado de la caché. El laboratorio mide casi siempre con caché fría; el campo mezcla primeras visitas y repetidas. Un sitio con buena política de caché y muchos usuarios recurrentes tendrá un campo notablemente mejor. Efecto: de segundos en la parte de transferencia. Señal: el TTFB de campo es mucho mejor que el de laboratorio y el porcentaje de visitas rápidas es muy alto.

3. Los iframes. El campo los incluye; la API que usa tu instrumentación no. Si tu elemento LCP está dentro de un iframe, tu instrumentación medirá otra cosa. Si un iframe genera desplazamientos de layout, tú no los verás y el campo público sí. Efecto: grande y en una sola dirección, el campo público sale peor. Señal: tienes contenido incrustado significativo y tu instrumentación propia da números sistemáticamente mejores que los públicos.

4. La interacción del usuario detiene el LCP. El navegador deja de emitir candidatos de LCP en cuanto el usuario toca, desplaza o pulsa una tecla. En laboratorio nadie toca nada, así que el LCP se computa hasta el final. En campo, un usuario que hace scroll a los 1.200 milisegundos congela el LCP en ese punto aunque la imagen grande llegue después. Efecto: el campo sale mejor, a veces mucho. Señal: tu LCP de campo es sospechosamente bueno comparado con lo que ves al cargar la página tú mismo.

5. El modelo de simulación de Lighthouse. La limitación simulada carga sin limitar y después modela. Falla en páginas con lógica adaptativa a la red o al dispositivo. Efecto: de segundos, en cualquier dirección. Señal: cambiar a limitación de DevTools o a nivel de paquete mueve mucho el número.

6. La geografía. Tu laboratorio corre desde donde corras tú; tus usuarios están donde están. Con una CDN el efecto se atenúa; sin ella, el TTFB puede variar cientos de milisegundos. Efecto: cientos de milisegundos. Señal: gran dispersión del TTFB de campo, y mejora al probar en laboratorio desde varias ubicaciones.

7. La ventana de agregación. Las herramientas que exponen CrUX usan mayoritariamente una media móvil de 28 días actualizada a diario, salvo el conjunto de BigQuery que es mensual. Un cambio desplegado hace tres días apenas se refleja. Efecto: retardo, no sesgo. Señal: la discrepancia se reduce sola con el paso de los días.

8. El nivel de agregación. PageSpeed Insights cae al dato de origen cuando no hay suficiente tráfico a nivel de página, y no lo destaca. Estás comparando tu laboratorio de una página con el agregado de todo el sitio. Efecto: arbitrario. Señal: el selector de la herramienta está en origen y no en esta URL.

9. El sesgo de supervivencia del campo. Solo se reportan las visitas que llegaron a completarse. El usuario que abandonó a los ocho segundos no aparece. Efecto: el campo sale mejor de lo que la experiencia real fue. Señal: caída del volumen de muestras junto con mejora de percentiles.

10. La varianza normal. Dos ejecuciones consecutivas de Lighthouse sobre la misma página en la misma máquina difieren, y a veces bastante. Efecto: decenas o pocos cientos de milisegundos. Señal: la discrepancia cambia de signo entre ejecuciones.

Cómo acercar el laboratorio al campo

El objetivo no es que coincidan, que no van a coincidir, sino que el laboratorio reproduzca el caso que te interesa arreglar.

1. Elige el segmento del campo que tiene el problema. Por ejemplo, móvil, primeras visitas, España.
2. Configura la limitación para ese segmento. Si el tipo de conexión efectiva mayoritaria de ese segmento es peor que el perfil por defecto, ajústalo. BigQuery expone esa dimensión.
3. Calibra el multiplicador de CPU. Mira el índice de referencia de tu máquina en el informe y ajústalo si estás fuera del rango esperado.
4. Reproduce el estado de caché correcto. Si el problema está en primeras visitas, caché fría. Si está en visitas repetidas, carga dos veces y mide la segunda.
5. Considera cambiar el método de limitación. Si sospechas del modelo, usa limitación a nivel de paquete.
6. Ejecuta varias veces y usa la mediana. Nunca una sola ejecución.

Con esos seis pasos, el laboratorio deja de ser “un número” y pasa a ser “el número de este segmento”, que es lo que puedes comparar con el campo de ese mismo segmento.

Cuándo la discrepancia es informativa

No toda discrepancia es un problema a resolver. Hay dos casos en que la brecha en sí misma es el hallazgo.

Laboratorio mucho mejor que campo, y no se explica por dispositivos ni caché. Suele significar que hay algo en producción que no está en tu entorno de prueba: scripts de terceros inyectados por un gestor de etiquetas, personalización que añade latencia de servidor, o un aviso de consentimiento que solo aparece a usuarios reales. Merece la pena probar en laboratorio con una URL de producción real y con las cookies de un usuario nuevo.

Campo mucho mejor que laboratorio, con LCP. Sospecha del punto 4: los usuarios están interactuando antes de que llegue el elemento grande, y eso congela el LCP artificialmente. Es una buena noticia para la métrica y no para la experiencia, porque significa que el contenido principal llega tarde y el usuario se ha puesto a hacer scroll sin él.