Sugerencias
← TIL
~3 min de lectura
#edge-native#astro-6#performance#ab-testing#vercel

A/B Testing Sin JS: Evita CLS y Mejora Performance en el Edge

Cuando necesitás probar variantes de UI sin sacrificar performance, querés eliminar el JavaScript del cliente y evitar CLS para que tus usuarios experimenten fluidez en cualquier conexión.

Hacer A/B testing en el cliente (vía scripts de Optimizely o VWO) es pegarse un tiro en el pie en términos de Web Vitals. Si enviás 53.4kb de JavaScript solo para decidir si un botón es azul o rojo, ya perdiste la batalla del LCP y, casi seguro, introdujiste un CLS (Cumulative Layout Shift) que arruina la experiencia del usuario.

La solución no es optimizar el script, sino eliminarlo del cliente.

La arquitectura Zero-JS#

La clave está en el Edge Middleware. Al interceptar la solicitud antes de que llegue al servidor (o al CDN), podemos decidir qué versión del contenido entregar sin que el navegador tenga que procesar ni una línea de lógica de testing.

Usuario
Edge (Middleware)
Origen (A/B)

Implementación en Astro 6 + Vercel#

Astro 6 tiene un runtime nativo para el Edge que permite hacer rewrites internos antes de que el primer byte salga del CDN. El flujo se resume en estos cuatro pasos:

  1. Identificamos al usuario: Miramos si tiene una cookie de bucket.
  2. Asignamos bucket: Si no la tiene, lo sorteamos (50/50) y seteamos la cookie.
  3. Hacemos el Rewrite: Cambiamos la ruta interna del pedido sin cambiar la URL visible para el usuario.
  4. Header Vary: Configuramos el header Vary: Cookie para que el CDN cachee ambas versiones por separado.
src/middleware.ts
import { defineMiddleware } from "astro:middleware";

export const onRequest = defineMiddleware(async (context, next) => {
  const cookieName = "ab-test-bucket";
  let bucket = context.cookies.get(cookieName)?.value;

  if (!bucket) {
    bucket = Math.random() < 0.5 ? "control" : "variant-a";
    context.cookies.set(cookieName, bucket, { path: "/", httpOnly: true });
  }

  // Si es la variante, hacemos un rewrite interno eficiente
  if (bucket === "variant-a" && context.url.pathname === "/") {
    return next("/v1/experimental-home/");
  }

  return next();
});

Comparativa de Impacto#

Mover esta lógica al Edge no es solo una cuestión estética. En dispositivos de gama media con conexiones inestables (comunes en el interior de Paraguay), el impacto en el LCP es determinante:

Client-side vs Edge-side Testing

Edge-side (Astro 6)

  • 0ms de bloqueo de main thread
  • CLS inexistente (Visual Stability)
  • Funciona sin JS en el navegador
  • Seguridad: el usuario no ve la lógica

Client-side (Legacy)

  • FOUC (Flash of Unstyled Content)
  • Impacto negativo en LCP/INP
  • Dependencia de scripts externos
  • Fácil de bloquear por AdBlockers

Equidad Digital: De Asunción a Itapúa#

Accesibilidad y Equidad

Al eliminar scripts pesados, no solo ganás en Lighthouse. Estás permitiendo que una persona con un teléfono de hace 5 años y una conexión 3G en Itapúa pueda navegar tu sitio con la misma fluidez que alguien con un iPhone 15 en Asunción. El performance es una rampa de accesibilidad invisible.

La URL no cambia, el bucket es persistente y el JS es CERO.

Si querés llevar esto un paso más allá, podés integrar Astro 6 y el Unified Runtime para que tu middleware y tus funciones compartan el mismo entorno de ejecución.

Enlace copiado al portapapeles