Los límites metodológicos: por qué la correlación se infla sola

Si coges tus datos de campo, cruzas el tiempo de pintado con la tasa de conversión y dibujas la curva, sale una relación preciosa: cuanto más rápido, más conversión, con una limpieza que parece definitiva. Esa curva sale igual de bonita en sitios donde la velocidad no causa nada, y hay al menos seis mecanismos que la producen sin que exista ninguna relación causal. Conocerlos sirve para dos cosas: para no engañarse, y para diseñar un experimento que los esquive.

Los seis mecanismos

Uno: causalidad inversa. La conversión causa velocidad, y no solo al revés. Un usuario que compra ha visitado varias páginas, con lo que tiene la caché caliente, la conexión establecida y las fuentes descargadas: sus últimas páginas son rapidísimas. Un usuario que rebota tiene una sola carga, en frío, que es la más lenta de todas por construcción. Si agregas por sesión, los que convierten tienen medias mejores sin que nada de eso haya causado la compra.

Dos: confusión por dispositivo y por renta. La velocidad es un excelente indicador indirecto del poder adquisitivo. Quien tiene un teléfono reciente y fibra carga rápido, y también compra más, y las dos cosas están causadas por lo mismo. Este mecanismo por sí solo puede generar toda la correlación que ves. Comprobarlo es fácil y casi nadie lo hace: repite tu análisis dentro de cada clase de dispositivo. Si la relación se desvanece al segmentar, lo que tenías era esto.

Tres: sesgo de supervivencia dentro de la propia métrica. Este es el más sutil, el más específico del rendimiento web y el que menos gente conoce, así que merece su sección.

Cuatro: intervenciones confundidas. Casi todos los “antes y después” publicados corresponden a un rediseño que cambió la velocidad y el diseño, el texto, el flujo y la navegación. Atribuir el resultado a la velocidad es una elección, no un hallazgo.

Cinco: efectos de estacionalidad y de tendencia. Comparar el mes posterior a una mejora con el anterior mezcla el efecto con todo lo que cambió por el camino: la campaña de marketing, la temporada, el cambio de precios, un competidor. Sin grupo de control simultáneo, esta comparación no distingue nada.

Seis: sesgo de publicación y de selección de la métrica. Al analizar los datos propios se prueban varias métricas y varias segmentaciones, y se retiene la combinación que sale bien. Es el mismo problema de comparaciones múltiples que arruinaba las comprobaciones automáticas: con veinte cortes, uno sale significativo por azar. La defensa es declarar la métrica y el corte antes de mirar.

El sesgo de supervivencia de las métricas

Este mecanismo merece detalle porque es específico de esta disciplina y porque invalida análisis que por lo demás están bien hechos.

Las métricas de carga solo se informan si la carga llega a producirse. El pintado del elemento más grande se registra cuando ese elemento aparece; si el usuario se marcha antes, no hay ninguna medida. La sesión no aporta un valor alto: no aporta ninguno.

Las consecuencias son dos, y las dos van en la misma dirección:

Tu distribución medida es más optimista que la real. Los peores casos, los que hicieron que alguien se fuera, están sistemáticamente ausentes. Tu percentil 75 es el percentil 75 de los que se quedaron.

La correlación con la conversión se infla. Las cargas lentas que existen en tus datos son, por definición, las de gente que aguantó, y aguantar está correlacionado con tener más interés. Las cargas lentas de gente sin paciencia no aparecen en ninguna fila. El resultado es una relación observada más fuerte que la real.

Ese sesgo se puede medir, y es de las instrumentaciones más valiosas que se pueden añadir a un sitio:

// Cuenta las cargas que se abandonan antes de que llegue a haber LCP.
(function medirAbandonoDeCarga() {
  let lcpVisto = false;
  const inicio = performance.now();

  try {
    new PerformanceObserver((lista) => {
      if (lista.getEntries().length) lcpVisto = true;
    }).observe({ type: 'largest-contentful-paint', buffered: true });
  } catch {
    return;   // No soportado: no se informa nada.
  }

  const informar = () => {
    if (document.visibilityState !== 'hidden') return;
    if (lcpVisto) return;
    // La pagina se oculta y aun no habia LCP: carga abandonada.
    navigator.sendBeacon('/rum/abandono', JSON.stringify({
      ruta: location.pathname,
      msHastaAbandono: Math.round(performance.now() - inicio),
      claseDispositivo: window.__claseDispositivo ?? 'desconocida',
      conexion: navigator.connection?.effectiveType ?? null,
    }));
  };

  document.addEventListener('visibilitychange', informar, { once: true });
})();

El número que sale de ahí —qué porcentaje de tus cargas se abandonan antes de mostrar el contenido principal, segmentado por clase de dispositivo— es probablemente el dato de rendimiento con más carga de negocio que puedes obtener sin montar ningún experimento. Y tiene una ventaja retórica notable sobre cualquier percentil: no requiere que nadie crea en una relación entre velocidad y dinero. Un usuario que se fue antes de ver el contenido no compró, y eso no es una inferencia estadística, es una tautología.

Comprobar cuál te afecta

Cuatro comprobaciones, en orden de rentabilidad. Ninguna necesita un experimento.

Segmenta por clase de dispositivo y repite el análisis dentro de cada clase. Si la relación entre velocidad y conversión desaparece dentro de las clases, era confusión. Si sobrevive dentro de cada una, has descartado el mecanismo dos, que es el más potente de todos.

Usa solo la primera carga de cada sesión. Elimina de golpe la causalidad inversa por caché caliente. La relación se debilitará; lo que quede es más creíble.

Mide el abandono de carga y añádelo al análisis. Si el porcentaje es alto en los segmentos lentos, tu distribución está truncada y cualquier correlación calculada sobre ella está inflada.

Compara la ventana temporal con un grupo no afectado. Si mejoraste solo una sección, las demás sirven de control: si la conversión subió en las dos por igual, tu mejora no fue la causa. Es el diseño de diferencias en diferencias, y es lo mejor que se puede hacer sin aleatorizar.

-- Diferencias en diferencias, con la seccion no tocada como control.
-- Si el efecto de la mejora es real, la diferencia de diferencias no es cero.
SELECT
  seccion,
  AVG(CASE WHEN fecha <  '2026-05-01' THEN convirtio END) AS antes,
  AVG(CASE WHEN fecha >= '2026-05-01' THEN convirtio END) AS despues,
  AVG(CASE WHEN fecha >= '2026-05-01' THEN convirtio END)
    - AVG(CASE WHEN fecha <  '2026-05-01' THEN convirtio END) AS delta
FROM sesiones
WHERE fecha BETWEEN '2026-03-01' AND '2026-07-01'
  AND seccion IN ('catalogo', 'blog')   -- catalogo tocado, blog no
GROUP BY seccion;

Ese diseño exige un supuesto que hay que enunciar en voz alta: que sin la intervención las dos secciones habrían evolucionado en paralelo. Es comprobable mirando si lo hicieron en los meses anteriores, y si no lo hicieron, el diseño no vale.

Cómo formularlo entonces

Con datos observacionales bien tratados, la afirmación honesta tiene esta forma:

En nuestros datos, las sesiones con LCP por debajo de 2,5 s convierten
un 1,8 veces mas que las que estan por encima de 4 s.

Esa relacion se mantiene al segmentar por clase de dispositivo y al
usar solo la primera carga de cada sesion, lo que descarta las dos
explicaciones alternativas mas probables.

No podemos concluir que acelerar el sitio produzca ese aumento.
Para saberlo hace falta un experimento, que proponemos y que cuesta
dos semanas.

Ese párrafo es más fuerte que cualquier afirmación exagerada, por una razón práctica: sobrevive a las preguntas. Y el tercer bloque, que parece una concesión, es en realidad la petición, formulada de tal modo que conceder resulta más fácil que negar.