Cuál manda para decidir

Cuando los datos se contradicen hay que tener decidido de antemano cuál gana, porque decidirlo en el momento significa decidir a favor del que confirma lo que ya querías hacer. La regla es simple de enunciar y sorprendentemente difícil de aplicar: el campo decide qué hay que arreglar, el laboratorio decide cómo. Todo lo demás se deriva de ahí.

La regla de precedencia

Escrita como tabla de decisión, para que no haya ambigüedad.

Las dos filas que más se incumplen son la tercera y la última. La tercera porque la lista de oportunidades de Lighthouse es cómoda y se parece a un backlog. La última porque cerrar una tarea cuando el laboratorio mejora es tentador y esperar 28 días a que el campo lo confirme no lo es.

La documentación oficial es explícita en el punto que más discusión genera: si Lighthouse y los datos de campo discrepan, los datos de campo probablemente reflejan mejor la experiencia de tus usuarios, siempre que te asegures de que estás mirando el dato de tu página y no el del origen completo.

Priorizar ponderando por tráfico

El error de priorización más caro es ordenar por severidad de la métrica en vez de por impacto total. Una página con un LCP de 6 segundos y cien visitas al mes importa menos que una con 3,2 segundos y doscientas mil.

La ponderación que funciona es sencilla:

impacto = visitas del segmento x fraccion de visitas por encima del umbral

Aplicado a un caso real:

El instinto dice arreglar el blog, que tiene el peor número. La ponderación dice arreglar las fichas de producto, que afectan a casi siete veces más usuarios. Y la portada, que parecía secundaria, es la segunda.

Fíjate en la columna que hace el trabajo: el porcentaje de visitas malas, no el percentil 75. Esa columna la da el histograma del campo, y es la razón por la que conviene mirar la distribución y no solo el valor puntual.

Verificar un arreglo sin engañarse

El criterio de verificación hay que escribirlo antes de hacer el cambio, porque después es demasiado fácil encontrar un corte de los datos donde el número ha mejorado.

Un criterio utilizable tiene cuatro partes:

1. La métrica y el segmento. “El LCP del percentil 75 en móvil, en fichas de producto.”
2. La magnitud mínima. “Debe bajar al menos 300 ms.” Poner un mínimo evita celebrar ruido.
3. La ventana temporal. “Medido sobre los 28 días completos posteriores al despliegue.”
4. La condición de control. “Y el volumen de visitas del segmento no debe haber caído más de un 10%.” Esta cuarta parte es la que protege del sesgo de supervivencia y de un cambio en la mezcla de tráfico.

En laboratorio, la verificación intermedia es más rápida pero necesita rigor propio: cinco ejecuciones antes y cinco después, comparando medianas, con la misma configuración y en la misma máquina, y mirando el índice de referencia de CPU para asegurarte de que la máquina estaba igual de ocupada en ambos casos.

Y una precaución que ahorra vergüenzas: comprueba que el cambio está realmente desplegado en producción y no bloqueado por una caché de la CDN. Es sorprendente cuántas verificaciones fallidas se explican así.

Qué umbral rompe el build

La integración continua necesita un umbral que falle, y elegirlo mal produce uno de dos fracasos: si es demasiado estricto, falla constantemente y el equipo aprende a ignorarlo; si es demasiado laxo, no protege de nada.

El criterio que mejor funciona es no poner el umbral sobre las métricas de laboratorio, que tienen mucha varianza, sino sobre magnitudes deterministas:

• Tamaño de los recursos, comprimidos, por tipo. Un presupuesto de bytes de JavaScript en la ruta crítica es reproducible al byte y no varía entre ejecuciones.
• Número de peticiones bloqueantes del renderizado.
• Número de orígenes distintos que toca la página.
• Presencia de patrones concretos: ninguna imagen sin width y height, ningún script síncrono en el head, ninguna imagen con loading="lazy" en el área visible inicial.

Sobre esas magnitudes, el umbral se puede poner ajustado y no dará falsos positivos. Las métricas de laboratorio se pueden seguir midiendo y graficando, pero como aviso, no como fallo, y siempre con mediana de varias ejecuciones.

Una convención que funciona bien es fijar el presupuesto en el valor actual más un margen pequeño, y bajarlo cada vez que se consigue una mejora. Así el presupuesto actúa de trinquete: impide volver atrás sin exigir mejoras imposibles.