Campo y laboratorio: dos preguntas distintas
Qué pregunta responde cada tipo de dato, qué puede y qué no puede medir cada uno, y por qué intentar sustituir uno por otro produce decisiones equivocadas.
Hay dos formas de obtener datos de rendimiento y no compiten entre sí: responden a preguntas distintas. El campo te dice si tienes un problema y a quién le pasa. El laboratorio te dice por qué ocurre y si tu arreglo funciona. Confundir los papeles es la causa de la mitad de las discusiones estériles sobre por qué un número no coincide con otro.
- Asignar a cada tipo de dato la pregunta que responde y la que no.
- Enumerar las métricas que solo se pueden obtener en uno de los dos mundos.
- Diseñar un flujo de trabajo que use los dos en el orden correcto.
- Reconocer los tres errores clásicos de sustituir un mundo por el otro.
Dos mundos, dos preguntas
Los datos de campo proceden de usuarios reales navegando por tu sitio en producción, con sus dispositivos, sus redes y su estado de caché. Vienen de dos fuentes: el conjunto de datos público que recoge el navegador Chrome de sus usuarios, y tu propia instrumentación con la librería web-vitals. La pregunta que responden es ¿tengo un problema, y a quién le pasa?
Los datos de laboratorio proceden de una carga sintética en un entorno controlado y reproducible. Vienen de Lighthouse, del panel de rendimiento de las herramientas de desarrollo, y de servicios de prueba en la nube. La pregunta que responden es ¿por qué ocurre y ha funcionado mi arreglo?
La diferencia de fondo es la varianza. El campo tiene una varianza enorme porque cada visita es distinta; a cambio, es la verdad sobre lo que viven tus usuarios. El laboratorio tiene una varianza pequeña porque las condiciones están fijadas; a cambio, mide un escenario que puede no parecerse al de nadie.
| Propiedad | Campo | Laboratorio |
|---|---|---|
| Población | Usuarios reales | Un escenario elegido |
| Reproducible | No | Sí |
| Detecta regresiones al momento | No, con retardo | Sí, en cada commit |
| Explica la causa | Parcialmente | Sí, con detalle |
| Mide INP de verdad | Sí | No, hay que simular interacciones |
| Mide el CLS posterior a la carga | Sí | Casi nunca |
| Permite probar un cambio antes de desplegar | No | Sí |
Qué mide cada mundo en exclusiva
Solo en campo
Hay cosas que por su naturaleza no existen en un laboratorio.
El INP real. Una herramienta que carga la página y no la toca no puede reportar INP, porque no ha habido interacciones. Y aunque las simule, el INP depende de qué haga el usuario y cuándo lo haga: las interacciones que producen las peores latencias suelen ser las que ocurren durante la carga, cuando el usuario impaciente pulsa antes de que el hilo principal se libere. Eso no se guioniza fácilmente. En laboratorio se usa el Total Blocking Time como aproximación, sabiendo que es un sustituto.
El CLS de sesión larga. Las herramientas de laboratorio cargan la página y terminan. Todo lo que salte después, el aviso de consentimiento, el anuncio que se recarga, el contenido inyectado a los ocho segundos, no lo van a ver nunca. La propia documentación advierte de que los valores de CLS que reporta el laboratorio pueden ser menores que los reales por esta razón.
La distribución. El laboratorio da un valor; el campo da una distribución. Saber que el percentil 75 está en 2,4 segundos y que el 20% de las visitas superan los 5 es información que ninguna ejecución sintética produce.
El efecto de la caché. En campo conviven primeras visitas y visitas repetidas, y la proporción entre ambas depende de tu producto. El laboratorio elige una de las dos, normalmente la fría.
El efecto de la geografía y de la red real. Un usuario en una red móvil con pérdida de paquetes vive algo que ninguna emulación reproduce con fidelidad.
Solo en laboratorio
Y a la inversa.
La cascada completa de recursos con su cadena de dependencias. En campo puedes obtener tiempos de recursos individuales, pero no la visión de qué esperaba a qué.
El perfil del hilo principal. Qué función concreta ocupó 340 milisegundos, con su pila de llamadas. Eso exige un perfilador, y un perfilador no se despliega a usuarios reales.
El efecto de un cambio antes de desplegarlo. Es la razón de ser del laboratorio en integración continua: comparar antes y después sin exponer a nadie.
Escenarios que aún no existen. ¿Qué pasaría si la imagen del hero pesara la mitad? En laboratorio se prueba; en campo hay que desplegar y esperar.
Entre el campo y el laboratorio puntual está la monitorización sintética: ejecutar la misma prueba de laboratorio de forma periódica, desde las mismas ubicaciones y con la misma configuración, y guardar la serie temporal. No es campo, porque el escenario es artificial, pero detecta regresiones antes de que lleguen a los datos de campo, que tardan días en reflejar un cambio. Es el complemento natural de un panel de campo.
El flujo de trabajo correcto
El orden importa, y es siempre el mismo.
- Empieza por el campo. Mira tus tres métricas al percentil 75, segmentadas por tipo de dispositivo. Identifica cuál está peor y en qué segmento. Sin este paso, cualquier trabajo posterior es una apuesta.
- Acota con dimensiones de campo. ¿Es un problema de todo el sitio o de un tipo de página? ¿De todos los dispositivos o solo de móvil? ¿De primeras visitas o de todas? La atribución que expone la librería te dice además qué elemento o qué interacción concreta es la culpable.
- Reproduce en laboratorio con las condiciones del campo. Aquí está el paso que más gente se salta: si tu problema está en móvil de gama media en una red lenta, configura el laboratorio para eso. Medir en tu portátil con fibra no reproduce nada.
- Diagnostica con el perfilador. Ahora sí, cascada, hilo principal, subpartes de la métrica.
- Arregla y verifica en laboratorio. Comparación antes y después con la misma configuración.
- Confirma en campo. Espera a que los datos de campo reflejen el cambio y comprueba que el percentil 75 se ha movido en la población afectada. Este paso también se salta mucha gente, y es el único que demuestra que has arreglado algo.
El punto 6 tiene un detalle temporal importante que trataremos al hablar de las ventanas de agregación: los datos de campo agregados tardan en incorporar un cambio, y esa latencia hay que tenerla en la planificación.
Los tres errores clásicos
Usar el laboratorio para decidir prioridades. Es el más común. Lighthouse te da una lista de oportunidades ordenada por ahorro estimado, y es tentador tratarla como un backlog. Pero esa lista está calculada sobre un escenario concreto que puede no ser el de tus usuarios, y no sabe nada de qué páginas tienen tráfico. Optimizar la portada porque Lighthouse la puntúa mal, cuando el 80% de tu tráfico entra por fichas de producto, es trabajo desperdiciado.
Usar el campo para diagnosticar. El campo te dice que el LCP está en 4,1 segundos y que el elemento culpable es una imagen. No te dice por qué esa imagen tarda: si es que se descubre tarde, si compite con otros recursos, si el servidor la sirve lento, o si el elemento está oculto esperando a un script. Para eso hace falta laboratorio.
Comparar un número de campo con uno de laboratorio y concluir que uno miente. Ninguno miente. Miden poblaciones distintas en condiciones distintas. La lección siguiente detalla las razones concretas por las que difieren, y son muchas más de las que la gente supone.
Los datos de campo solo existen si el usuario llegó a cargar la página y se quedó lo suficiente para que la métrica se reportara. El usuario cuya conexión era tan mala que abandonó a los ocho segundos no aparece en tu percentil 75: se fue antes de generar la muestra. Lo mismo ocurre con el INP, que no se reporta si nadie interactúa, y con el CLS y el LCP, que no se reportan si la página se cargó en segundo plano. El resultado es que tus datos de campo describen a los usuarios que aguantaron, y cuanto peor va tu sitio, más filtrada está esa muestra hacia los pacientes. He visto un sitio mejorar su LCP de campo al empeorar de verdad, porque los usuarios de red lenta dejaron de llegar al final y desaparecieron de la muestra. La señal que delata esta situación es una caída del volumen de muestras junto con una mejora de los percentiles; si ves ese par, no celebres, investiga. Y por eso conviene mirar siempre el número de visitas junto a la métrica, no solo la métrica.