Históricamente, el problema de la velocidad de carga se ha considerado exclusivamente como una métrica ingenieril, pero con la introducción de Core Web Vitals en los algoritmos de búsqueda y el aumento del tráfico móvil, se ha vuelto evidente que el rendimiento es una característica del producto. Los enfoques clásicos para evaluar el impacto de la velocidad se enfrentan a una endogeneidad fundamental: los usuarios con dispositivos rápidos y acceso a internet estable convierten mejor independientemente de la optimización del sitio, lo que crea una correlación espuria.
El problema se agrava con el uso de Edge Computing y arquitecturas CDN modernas, donde no es posible garantizar una división consistente del tráfico en grupos debido al agresivo almacenamiento en caché en los servidores de borde. Además, existe el efecto de auto-selección: los usuarios con conexiones lentas suelen abandonar el sitio antes de que se complete la carga, lo que distorsiona la distribución en la muestra y hace imposible una comparación A/B limpia.
La solución óptima combina Regression Discontinuity Design (RDD) en la frontera del umbral de “buen” rendimiento (por ejemplo, LCP = 2.5 segundos) con instrumental variables (IV) como herramienta. La variable instrumental utilizada es la proximidad geográfica del usuario al servidor de borde más cercano o el tipo de conexión (3G vs 4G), que influye aleatoriamente en la velocidad, pero no se correlaciona directamente con la intención de compra. Para el análisis de cohortes, se aplica el synthetic control method, donde el grupo de control se construye a partir de datos históricos de usuarios con una estructura de dispositivos y geolocalizaciones similares, lo que permite aislar el efecto puro de la optimización de la estacionalidad y las macro-tendencias.
En un gran proyecto de e-commerce, el equipo de frontend llevó a cabo una revolución: cambió las imágenes a formatos modernos (WebP, AVIF) con carga diferida y optimizó la ruta crítica de renderizado, reduciendo el LCP de 4.2 segundos a 1.8 segundos entre los usuarios con buena conexión. El equipo de producto registró un aumento del 12% en la conversión en la segmentación “después del lanzamiento”, pero surgieron dudas sobre la relación causal, ya que al mismo tiempo se lanzó una campaña publicitaria estacional y se actualizó el catálogo de productos.
Opción 1: Comparación ingenua de cohortes antes y después
Los analistas propusieron comparar la conversión de los usuarios durante la semana anterior a la optimización y la semana posterior, estratificando por regiones. Ventajas: simplicidad de implementación y ausencia de necesidad de infraestructura compleja. Desventajas: completa ignorancia de la estacionalidad (semana previa a las festividades), diferencias en la composición de la audiencia (nuevos usuarios llegaron de la publicidad con otra intención) y sesgo de supervivencia (survivorship bias) — los usuarios lentos “desaparecieron” de la muestra posterior, creando una ilusión de crecimiento.
Opción 2: Análisis correlacional de velocidad vs conversión
El segundo enfoque implicó crear una regresión donde la variable independiente era el LCP real del usuario, y la dependiente, el hecho de conversión. Ventajas: uso de todos los datos disponibles y granularidad hasta la sesión. Desventajas: endogeneidad fatal: los usuarios con dispositivos premium y acceso rápido a internet son inicialmente más ricos y motivados a comprar, mientras que los usuarios con dispositivos baratos en 3G tienen una baja intención de compra independientemente de la velocidad del sitio, lo que produce un sesgo operativo al alza del 40-60%.
Opción 3: Regression Discontinuity Design con herramienta geográfica
El equipo eligió un método híbrido: utilizó la distancia al servidor de edge más cercano como variable instrumental, correlacionándose con la velocidad, pero no con el comportamiento de compra. Los usuarios en la frontera de la zona de cobertura (donde la señal “corta” y la velocidad cae drásticamente a 2.6-2.8 segundos LCP) formaron una muestra localmente aleatoria alrededor del umbral de 2.5 segundos. Aplicando Local Average Treatment Effect (LATE) en la ventana ±0.3 segundos del umbral, midieron el efecto puro de la mejora de la velocidad para los cumplidores (usuarios cuya velocidad cambió debido a la infraestructura en lugar del dispositivo).
Solución elegida y resultado
Se implementó el enfoque RDD+IV con filtración adicional de los usuarios que regresan a través del análisis de localStorage en busca de recursos almacenados en caché. La evaluación final mostró que el efecto incremental real de la optimización fue de +8.5% en la conversión para nuevos usuarios y +3.2% para los que regresan (donde el efecto de novedad es menor), lo que permitió justificar la inversión en infraestructura de Edge Computing con un ROI del 340% durante el año.
¿Por qué la regresión OLS estándar de rendimiento vs conversión da estimaciones sesgadas, y qué mecanismo de endogeneidad aquí es dominante?
La respuesta radica en la doble auto-selección (double selection bias): en primer lugar, los usuarios con dispositivos lentos sistemáticamente tienen menos probabilidades de formar parte de la muestra de “sesiones exitosas” (abandonan antes de cargar), creando un sesgo de truncamiento; en segundo lugar, la velocidad de internet se correlaciona con el estatus socioeconómico y la geografía, que influyen directamente en la capacidad de pago. Sin variables instrumentales o RDD, la regresión mezcla el efecto de “internet rápido como marcador de riqueza” con el efecto de “páginas rápidas como desencadenantes de conversión”, sobrestimando el verdadero efecto causal entre 1.5 y 2 veces.
¿Cómo la caché del lado del cliente (client-side caching) y las visitas repetidas distorsionan la estimación del efecto de optimización en el análisis longitudinal, y qué método permite filtrar la “contaminación del tratamiento”?
Los visitantes que regresan, que visitaron el sitio antes de la optimización, tienen en HTTP-cache o Service Worker recursos viejos y pesados, por lo que para ellos el “tratamiento” (nueva versión rápida) se aplica parcial o completamente, creando contaminación entre tratamiento y control. Los candidatos a menudo olvidan verificar los encabezados If-None-Match o analizar las first-party cookies con el timestamp de la primera visita. El enfoque correcto es analizar intent-to-treat (ITT) separando en “sesiones nuevas limpias” (nuevos usuarios + caché vacía) vs “regresantes contaminados”, o utilizar difference-in-differences (DiD) con efectos fijos de usuario, lo que aísla el cambio dentro del usuario de la selección entre usuarios.
¿Cuál es la diferencia entre el análisis ITT (Intent-to-Treat) y el análisis TOT (Treatment-on-the-Treated) al evaluar el efecto de Core Web Vitals, y por qué es crítico reportar métricas de producto específicamente por ITT al planificar la escalabilidad?
ITT mide el efecto para toda la población, incluyendo a aquellos que no recibieron la mejora de velocidad (por ejemplo, usuarios en 2G o con JavaScript deshabilitado), mientras que TOT (o LATE en el contexto IV) mide el efecto solo para los “cumplidores” — aquellos que realmente obtuvieron el beneficio de la optimización. Los candidatos a menudo informan erróneamente al negocio una estimación TOT (+15% de conversión para quienes recibieron carga rápida), pero al escalar la optimización al 100% del tráfico, el efecto real está más cerca de ITT (+6-8%), ya que parte de la audiencia técnicamente no podrá recibir la mejora (dispositivos obsoletos, redes lentas). Para la planificación empresarial y la previsión de ingresos, es crítico utilizar la estimación conservadora de ITT para evitar errores de sobrecompromiso.