Experimentación en el Edge: Tests A/B en la Capa del CDN

El test A/B en el edge significa decidir qué variación ve un visitante en un punto de presencia del CDN, físicamente cercano a ese visitante, en vez de en el navegador o en un único servidor de origen distante. Toma prestada la mayor ventaja del test server-side, cero flicker, y añade una segunda encima: la decisión ocurre en uno de cientos de puntos de red cercanos al visitante en lugar de en una sola región, lo que recorta el viaje de ida y vuelta que el render server-side tradicional puede agregar. Esto no reemplaza los conceptos de feature flag que ya sostienen la mayoría de los experimentos server-side, son esos mismos conceptos ejecutados sobre infraestructura diferente, con un conjunto distinto de compromisos que esta guía cubre por completo: cómo elimina realmente el flicker, cómo se ve la segmentación geográfica nativa en la práctica, una mirada neutral a Cloudflare Workers, Vercel Edge Middleware, AWS Lambda@Edge y Fastly Compute, y los riesgos que nadie menciona hasta que una caché sirve al visitante equivocado la variante equivocada.

Tres lugares donde puede ocurrir la decisión de variación

Todo test A/B, sin importar la herramienta, responde la misma pregunta en algún punto del ciclo de vida de la petición: qué variación ve este visitante específico. Lo que cambia es dónde se responde esa pregunta.

El test client-side ejecuta un script en el navegador que reescribe la página ya renderizada, que es lo que causa el destello de contenido original cubierto en detalle en nuestra comparación client-side y server-side. Un test server-side tradicional mueve esa decisión al backend, antes de que se envíe HTML, lo que elimina el flicker por completo pero sigue enrutando a cada visitante hacia donde ese backend corre físicamente. El test en el edge conserva la propiedad de “decidir antes de enviar el HTML” del test server-side, y luego reubica la decisión misma en un punto de presencia del CDN cercano al visitante, uno de los cientos que Cloudflare, Fastly, Vercel y AWS operan globalmente.

Por qué el cero flicker es estructural, no una funcionalidad

El flicker existe solo porque el navegador renderiza alguna versión de la página antes de que el script de testing termine de decidir y reescribir el DOM. El edge computing elimina esa brecha del mismo modo que cualquier test server-side: el worker o la función de middleware evalúa la variación, construye o reenvía la respuesta correcta, y el navegador nunca recibe una versión que tenga que descartar y reemplazar. Cloudflare documenta este patrón directamente en su propio ejemplo de A/B testing con Workers, donde el worker lee una cookie de asignación y enruta la petición a la ruta de backend correcta antes de que cualquier contenido llegue al visitante, sin ningún paso de reescritura client-side, según la documentación de Cloudflare Workers.

Vercel hace explícito el mismo compromiso en su propia guía: ejecutar la decisión en Edge Middleware, antes de la respuesta, “reduce el desplazamiento de diseño al evitar experimentos cargados en el cliente” y evita enviar el JavaScript extra que requiere un script de testing client-side, según la base de conocimiento de Vercel. Fastly lo plantea igual en su documentación de A/B testing con Compute, describiendo el objetivo como servir la respuesta final, ya decidida, directamente desde el edge en vez de manipular el DOM después.

Lo que el edge añade encima del cero flicker: proximidad

La parte específica del edge, frente a un test server-side tradicional de una sola región, es dónde ocurre físicamente esa decisión. Un backend que vive en una región de AWS responde a todos los visitantes desde esa región, sin importar qué tan lejos estén. Un worker en el edge responde desde el punto de presencia más cercano al visitante que hace la petición. Cloudflare afirma que su red abarca 348 ciudades en 8 regiones, con el 95 por ciento de la población mundial conectada a internet a menos de 50 milisegundos de uno de sus centros de datos, según la página de red de Cloudflare. Esa proximidad es todo el argumento de latencia de la experimentación en el edge: no que el cómputo en el edge sea instantáneo, sino que el salto de red para alcanzarlo es corto casi en todas partes.

AWS Lambda@Edge, construido sobre CloudFront, corre bajo restricciones más estrictas que una función Lambda normal precisamente porque se ejecuta en la ruta de la petición en el edge: las funciones disparadas en el evento de viewer request o viewer response están limitadas a 128MB de memoria, una fracción de los 10.240MB disponibles para funciones en los eventos de origin request u origin response, y ambos tipos de evento tienen un tope de 30 segundos de tiempo de ejecución, muy por debajo del techo de 15 minutos de una función Lambda estándar, según la propia guía para desarrolladores de CloudFront de AWS que compara CloudFront Functions y Lambda@Edge. Ese techo de memoria no es una limitación para esquivar, es una señal sobre para qué sirve el cómputo en el edge: una decisión rápida tomada en cada petición, no un lugar para correr un cálculo pesado de significancia estadística, que pertenece al pipeline de análisis, no a la ruta de la petición.

Segmentación geográfica nativa, sin un segundo viaje

Una capacidad que las plataformas de edge ofrecen de forma nativa, y que el test client-side o server-side de una sola región no pueden sin peticiones extra, es la información geográfica ya resuelta por la propia red antes de que tu código corra. Cloudflare Workers la expone a través del objeto cf de la petición, que incluye el código de país de dos letras del visitante, su region, city, continent e incluso isEUCountry, todos poblados por la red edge de Cloudflare en el momento de la petición, según la documentación de la API del runtime de Cloudflare Workers. Un worker puede leer ese valor y elegir una variación, una moneda o un idioma, en la misma pasada en que decide el test A/B, sin una llamada separada a una API de geolocalización y sin latencia añadida por esa consulta.

Eso importa específicamente para tests que combinan un experimento con una regla geográfica: mostrar una variante de precio regional solo a visitantes de un país, o testear un formato de moneda que nunca debería filtrarse fuera de su región objetivo. El test client-side puede aproximar esto con una llamada a una API de geolocalización desde el navegador, lo que añade un viaje y una dependencia de un servicio de terceros; un servidor distante de una sola región también puede leer cabeceras geográficas, pero solo después de que la petición ya viajó hasta esa región. En el edge, el dato geográfico y la decisión de enrutamiento llegan juntos, en el punto más cercano al visitante.

Comparando las plataformas de edge, sin elegir favorita

No existe un runtime de edge universalmente mejor, solo el que encaja con el stack que un equipo ya tiene. Una foto neutral de lo que cada proveedor documenta sobre su propia plataforma:

Plataforma	Modelo de runtime	Fortaleza real	Limitación real
Cloudflare Workers	Isolates de V8, sin contenedor con arranque en frío, KV y Durable Objects para estado	Corre de forma independiente de cualquier proveedor de hosting; amplia huella de red (348 ciudades según la propia página de red de Cloudflare); ejemplo maduro de A/B testing en la documentación oficial	El modelo de isolates implica que no hay sistema de archivos local persistente; el estado necesita KV o Durable Objects, una pieza más de infraestructura que considerar
Vercel Edge Middleware	Edge Runtime basado en V8, muy integrado con Next.js	El camino más simple si la aplicación ya se despliega en Vercel; plantillas oficiales de A/B testing listas para clonar	Atado a la plataforma Vercel y a su modelo de despliegue; menos útil si la aplicación está alojada en otro lugar
AWS Lambda@Edge	Funciones AWS Lambda corriendo en las ubicaciones edge de CloudFront	Encaja naturalmente en un stack existente de CloudFront y AWS; reutiliza herramientas Lambda familiares	Los límites más ajustados de los cuatro: techo de 128MB de memoria en los disparadores viewer-request y viewer-response (frente a 10.240MB para origin-request), más latencia añadida de arranque en frío en ese punto, según la propia guía para desarrolladores de CloudFront de AWS
Fastly Compute	Sandbox de WebAssembly (Rust, JavaScript y otros lenguajes que compilan a Wasm)	Ejemplo documentado y dedicado de A/B testing y personalización con arranques en frío del orden de milisegundos; fuerte aislamiento entre inquilinos	Ecosistema y mercado de talento más pequeños que Workers o Lambda; la cadena de herramientas de WebAssembly añade un paso de build al que la mayoría de los equipos solo de JavaScript no está acostumbrada

Cada fila de esa tabla es una foto de lo que cada proveedor afirma hoy sobre su propio producto; los límites de runtime, la huella regional y las condiciones del plan gratuito cambian con la frecuencia suficiente como para revisar la documentación actual de cada plataforma antes de comprometerse con una.

Los riesgos que nadie menciona en el pitch

La experimentación en el edge resuelve el flicker y recorta la latencia, pero introduce modos de fallo que un snippet client-side o un render de servidor simple nunca enfrentan, porque todos se remontan a una sola cosa: una caché de CDN que no fue construida pensando en tu lógica de variación específica.

Envenenamiento de caché: el visitante equivocado recibe la variante equivocada

Una caché de CDN decide si dos peticiones son “la misma” usando una clave de caché, normalmente solo la URL. Si tu worker del edge varía la respuesta por una cookie de asignación, un país o un tipo de dispositivo, pero la clave de caché sigue ignorando todo eso, el CDN puede almacenar la respuesta personalizada del primer visitante y servir esa misma respuesta a todos los demás visitantes que pidan esa URL, sin importar a qué variante o región pertenezcan. La propia investigación de envenenamiento de caché web de PortSwigger describe el mecanismo subyacente con precisión: cualquier diferencia en una respuesta disparada por una entrada que la caché no incluye en su clave puede almacenarse y reproducirse a otros usuarios, convirtiendo a la caché misma en el mecanismo de entrega del contenido equivocado. En un test A/B, eso significa que el experimento entero puede colapsar en silencio en “todos ven lo que la primera petición haya recibido”, sin que se dispare ningún error en ningún lado.

La solución refleja el mismo principio que Cloudflare documenta para sus propias Cache Rules: cualquier cabecera de petición que cambie la respuesta, una cookie de variante, un valor de Accept-Language, un tipo de dispositivo, necesita estar reflejada en la clave de caché o en la configuración Vary del origen, o la respuesta necesita saltarse la caché por completo, según la documentación de caché de Cloudflare sobre el manejo de Vary. Sin esa configuración, el comportamiento por defecto de Cloudflare no aplica automáticamente la clave a cada cabecera por la que tu origen varía: el origen tiene que declarar Vary explícitamente y hay que indicarle a la regla de caché que lo respete, que es precisamente la brecha que convierte un error de personalización en un incidente de envenenamiento de caché.

La invalidación de caché se multiplica con cada dimensión que añades

Una vez que una variante forma parte de la clave de caché, “invalidar esta página” deja de significar un objeto y pasa a significar cada combinación de variante, región y dispositivo que alguna vez se sirvió para esa URL. Un test que despliega un nuevo control tras declarar un ganador, o que necesita un rollback de emergencia, tiene que purgar cada una de esas combinaciones en caché, no la única copia que tendría una página estática. Los equipos que no lo planean con antelación lo descubren de la misma forma: revierten una variante perdedora en el worker del edge, y una porción de visitantes sigue viendo la versión antigua, cacheada y perdedora hasta que cada combinación expira naturalmente o se purga a mano.

El costo de cómputo se factura distinto que un acierto de caché estático

Servir una respuesta estática y cacheada desde un CDN es casi gratis a los niveles de tráfico en que opera la mayoría de los sitios. Ejecutar un worker en cada petición, para leer una cookie, resolver la geografía y elegir una variante, no lo es: Cloudflare Workers, Fastly Compute, Lambda@Edge y Vercel Edge Middleware facturan todos según peticiones y tiempo de cómputo, siguiendo el modelo de precios publicado por cada proveedor, en vez de la economía plana de egreso y acierto de caché de un CDN simple. Rara vez es caro para un solo test, pero es una línea de costo real y recurrente que un snippet client-side o una página puramente estática no cargan, y vale la pena revisar la página de precios actual de cada plataforma antes de asumir que un test en el edge es “gratis porque es solo un CDN”.

Cuándo la experimentación en el edge justifica su complejidad, y cuándo es sobreingeniería

Situación	Encaja con el edge	Encaja mejor con client-side o server-side simple
El test solo cambia un titular, una imagen o un CTA en unas pocas páginas	Rara vez vale la pena	Un snippet liviano o un render de servidor simple lo resuelve con mucha menos superficie operativa
Cero tolerancia al flicker en una audiencia global de alto tráfico	Sí, este es el caso de uso central	No aplica, esto es exactamente lo que el test en el edge existe para resolver
El test necesita variar por país o región antes de ensamblar la página	Sí, el dato geográfico nativo elimina una consulta extra	La geolocalización client-side añade un viaje; el server-side de una región añade distancia
Equipo pequeño sin nadie que mantenga claves de caché y workers del edge	Normalmente todavía no vale la pena	Una arquitectura más simple reduce la posibilidad de un fallo silencioso de envenenamiento de caché
El test toca precios, permisos o lógica de negocio que ya vive server-side	Vale la pena si ese backend ya está detrás de un CDN con cómputo en el edge	Un test server-side tradicional puede bastar sin mudarse al edge

La regla honesta: la experimentación en el edge es una optimización de latencia y de flicker encima del test server-side, no una disciplina separada a la que recurrir por defecto. Si un test server-side simple ya cumple el estándar, cubierto paso a paso en nuestra guía de implementación server-side, mover esa misma lógica al edge solo vale la pena cuando la proximidad extra, o el dato geográfico nativo, realmente cambia el resultado para tus visitantes.

Una arquitectura mínima, descrita de punta a punta

Un experimento típico en el edge sigue la misma forma en Cloudflare Workers, Vercel Edge Middleware y Fastly Compute, y se diferencia sobre todo en la sintaxis. La función del edge intercepta la petición entrante antes de que llegue al origen o a la caché. Comprueba si existe una cookie de asignación; si no existe, asigna al visitante a una variante usando un método estable y determinista (un sorteo aleatorio persistido en una cookie, en el patrón que sigue el propio ejemplo de A/B testing de Cloudflare) para que el mismo visitante caiga en la misma variante en peticiones repetidas. Opcionalmente lee el dato geográfico provisto por la red para aplicar una regla regional en la misma pasada. Luego reescribe la ruta de la petición para traer una respuesta de origen diferente, como hace el ejemplo de Cloudflare, o ensambla la respuesta directamente en el edge, como demuestra el ejemplo de Compute de Fastly. Finalmente, y este es el paso que los equipos más suelen saltarse, se asegura de que la respuesta se salte la caché o lleve una clave de caché que refleje cada dimensión por la que la respuesta realmente varía, para que el CDN nunca confunda a dos visitantes que debían ver cosas distintas. Esto refleja la práctica de rollout progresivo en un punto más: empieza con la regla geográfica o de variante acotada de forma estrecha, confirma que el comportamiento de caché es correcto para esa porción, y luego amplíala, en vez de desplegar una regla global en el edge y descubrir una brecha en la clave de caché con el tráfico ya circulando por ahí.

Hazlo automático en Donnu

Todo lo anterior ocurre antes de que Donnu A/B entre en juego. Donnu es, a propósito, una herramienta de experimentación client-side: un snippet liviano que corre en el navegador, hecho para instalarse en minutos sin un worker en el edge, una auditoría de claves de caché o una distribución de CloudFront que mantener. Es un compromiso deliberado, no un descuido: el edge computing resuelve un problema de latencia y flicker que la mayoría de los tests de marketing y CRO nunca llega a tener, e introduce exactamente el riesgo de envenenamiento e invalidación de caché que esta guía acaba de recorrer.

Lo que no cambia según dónde ocurra la decisión, navegador, origen o edge, es la parte que la mayoría de los artículos sobre testing en el edge se saltan por completo: decidir un ganador con rigor estadístico real. Un test en el edge con cero flicker perfecto sigue produciendo un resultado sin sentido si se detiene antes de alcanzar el tamaño de muestra, o si alguien mira el panel y corta el test antes de tiempo. Donnu se enfoca en esa capa: tamaño de muestra calculado, una lectura bayesiana honesta de la significancia, y asignación estable de variantes, la misma disciplina que importa tanto si la variación se sirvió desde un nodo edge del CDN como desde un snippet en la página. Si tu test es un cambio visual y el flicker es un costo aceptable y bien mitigado, una prueba gratis de 14 días pone hoy mismo un experimento analizado con rigor a correr. Si tu caso realmente necesita infraestructura en el edge o en el servidor primero, empieza por nuestras guías de test client-side y server-side y cómo implementar test A/B en el servidor para mapear la arquitectura antes de añadir una capa de estadística encima.

Referencias

• Cloudflare. A/B testing with same-URL direct access. Documentación de Workers. developers.cloudflare.com/workers/examples/ab-testing.
• Cloudflare. Request properties (el objeto cf). Documentación de la API del runtime de Workers. developers.cloudflare.com/workers/runtime-apis/request.
• Cloudflare. Red global: 348 ciudades, menos de 50ms para el 95% de los usuarios. cloudflare.com/network.
• Cloudflare. Vary. Documentación de conceptos de caché. developers.cloudflare.com/cache/concepts/vary.
• Vercel. A/B Testing on Vercel. Guía de la base de conocimiento. vercel.com/kb/guide/ab-testing-on-vercel.
• Fastly. Use A/B testing to personalize responses. Ejemplos de soluciones. fastly.com/documentation/solutions/examples/ab-testing.
• AWS. Differences between CloudFront Functions and Lambda@Edge (cuotas de duración y memoria por tipo de evento). Guía para desarrolladores de Amazon CloudFront. docs.aws.amazon.com/AmazonCloudFront/…/edge-functions-choosing.html.
• AWS. Restrictions on Lambda@Edge. Guía para desarrolladores de Amazon CloudFront. docs.aws.amazon.com/AmazonCloudFront.
• PortSwigger. Practical Web Cache Poisoning. Investigación. portswigger.net/research/practical-web-cache-poisoning.
• Statsig. CDN Edge Testing for Cached Resources. docs.statsig.com/guides/cdn-edge-testing.

Lee también: La guía completa de feature flags, test A/B client-side y server-side, cómo implementar test A/B en el servidor, y rollout progresivo y canary releases.