Efecto Flicker en Test A/B: qué es y cómo eliminarlo

El efecto flicker es el intervalo en el que el visitante ve la página original antes de que la herramienta de test A/B cambie el contenido por la variación. Casi todo el mundo lo trata como un defecto estético, y es peor que eso: como solo la variación pasa por el cambio visible, su costo cae entero sobre un brazo, y el experimento pasa a medir la variación con una penalización incorporada. En el ejemplo trabajado de esta guía, un test A/A prima con 250.000 visitantes por brazo, en el que la variación solo vuelve a aplicar el mismo contenido, muestra una pérdida de 4,0 por ciento con valor p de 0,0036. Ninguna palabra de la página cambió. Esta guía explica la línea de tiempo que produce el flicker, por qué el snippet anti-flicker cambia un sesgo por otro, cómo medir el problema en tu sitio con A/A, A/A prima y marcas de rendimiento, y el checklist para eliminarlo. Forma parte de nuestra guía completa de feature flags y profundiza en el problema que presentamos en test A/B client-side vs server-side.

Qué es el efecto flicker y por qué ocurre

El efecto flicker, también llamado FOOC (flash of original content), es consecuencia directa de dónde ocurre la decisión del test. En un test client-side, el servidor entrega la página original a todo el mundo, y solo dentro del navegador un script decide en qué brazo está el visitante y modifica la página. Entre que llega el HTML y que el script actúa, el navegador no se queda quieto: pinta lo que ya tiene.

La secuencia es siempre la misma:

1. Llega el HTML y el navegador empieza a montar la página.
2. Ocurre el primer pintado con el contenido original, si nada lo impide.
3. Se descarga el script de la herramienta, a veces después de un gestor de etiquetas que también hay que descargar.
4. Se lee la configuración del test y el visitante es sorteado a un brazo.
5. Se aplica el cambio en el documento, y el navegador vuelve a pintar.

Todo lo que el visitante ve entre el paso 2 y el paso 5 es el control. Si ese intervalo es imperceptible, el flicker no existe en la práctica. Si dura más que un parpadeo, el visitante ve cambiar el título, saltar la imagen o cambiar de color el botón bajo el cursor.

Optimizely describe el mecanismo en su propia documentación: al cargar de forma asíncrona, el navegador no espera a que el script termine antes de mostrar el cuerpo de la página, y eso puede producir el parpadeo. La misma página registra la consecuencia que le importa a quien analiza experimentos: el flicker hace que el resultado del experimento sea menos confiable.

Tres formas de atacar el problema, tres cuentas distintas

Existen tres familias de solución, y cada una paga el problema con una moneda distinta.

Snippet síncrono arriba del todo en el head. El navegador deja de montar la página hasta que corre el script de la herramienta. Si la decisión y el cambio ocurren antes del primer pintado, no existe original visible. El costo es que el script se vuelve un recurso bloqueante: si tarda, la página entera tarda, para los dos brazos. Es el modo que recomienda Optimizely, con la observación de que la carga asíncrona elimina el retraso pero aumenta mucho la probabilidad de parpadeo.

Snippet anti-flicker. Un pequeño código en el head oculta la página (en general con opacity en cero o visibility oculta) hasta que la herramienta avisa que aplicó la variación, o hasta que expira un tiempo límite. El original nunca aparece, pero el visitante mira una pantalla vacía durante ese tiempo. Como la página se oculta antes de saber el brazo, el control también espera.

Decisión en el servidor o en el borde de la red. El HTML ya sale con la variación, y no existe versión equivocada que ocultar. El costo es de ingeniería, y parte de la latencia se desplaza al servidor. Es el camino descrito en cómo implementar pruebas A/B en el servidor y en experimentación en el edge.

enfoque	flicker visible	costo de velocidad	quién paga el costo	complejidad
asíncrono sin protección	alto, siempre que el script llega después del pintado	ninguno en la visualización inicial	solo la variación (cambio visible)	baja
asíncrono mediante gestor de etiquetas	el más alto, hay dos descargas antes de la decisión	ninguno en la visualización inicial	solo la variación	baja
síncrono arriba del todo en el head	bajo, si la decisión cabe antes del pintado	bloqueo durante la descarga y ejecución del script	los dos brazos	baja
anti-flicker con tiempo límite	ninguno hasta el límite, total después de él	página oculta hasta aplicar o expirar	los dos brazos, y además la variación si tarda más	baja a media
servidor o borde	ninguno	procesamiento en el servidor o en el borde	los dos brazos, en general poco	alta

La fila que más engaña es la del gestor de etiquetas. Optimizely es explícita: el snippet debe venir en la respuesta del servidor, y no entregado por un gestor de etiquetas ni inyectado por otro script. El motivo es aritmético: el gestor tiene que descargarse y ejecutarse antes de siquiera empezar a descargar la herramienta. La guía de Google Tag Manager para test A/B detalla cuándo esa instalación todavía tiene sentido.

Por qué el efecto flicker es un problema estadístico, no solo estético

Un test A/B solo es justo si los dos brazos reciben un trato idéntico en todo, excepto en el cambio que se prueba. El efecto flicker rompe esa premisa de tres formas distintas.

1. El cambio visible castiga solo a la variación

El control se pinta una vez y se queda. La variación se pinta, se deshace y se vuelve a pintar. Si el cambio provoca cualquier reacción (extrañeza, desconfianza, un clic en el lugar donde estaba el botón, scroll perdido por un salto de layout), esa reacción existe solo en un brazo. El experimento mide el contenido de la variación menos el costo del cambio, y reporta la suma como si fuera el contenido.

El tamaño del sesgo depende de dos cosas: la fracción de visitantes que llega a ver el cambio y cuánto pierden. El efecto global es el producto de las dos. La tabla de abajo es un modelo aritmético, no un dato de mercado: las fracciones y las pérdidas son hipótesis para mostrar el orden de magnitud.

fracción que ve el cambio	pérdida de quien lo ve	efecto en el brazo entero	visitantes por variación para detectarlo	días a 125.000/semana
10%	10%	1,00%	3.785.510	424
25%	10%	2,50%	610.010	69
40%	10%	4,00%	239.975	27
25%	20%	5,00%	154.304	18
50%	20%	10,00%	39.475	5

La conversión base es de 4 por ciento, con 95 por ciento de confianza y 80 por ciento de poder. La lectura importante está en las filas de arriba: un flicker que afecta a poca gente produce un sesgo demasiado pequeño para ser detectado, y lo bastante grande para borrar una victoria real de 1 o 2 por ciento. Un sesgo no necesita ser significativo para distorsionar una decisión.

2. El anti-flicker retrasa a todos, y a veces retrasa más a un brazo

El anti-flicker resuelve la asimetría visual ocultando la página a los dos brazos. El costo de velocidad, entonces, cae sobre los dos, y una comparación entre control y variación no ve ese costo: los dos pierden, la diferencia entre ellos no cambia. Solo un grupo sin ningún snippet mostraría cuánto le está costando el programa de tests al sitio entero.

La asimetría vuelve cuando la variación tarda más en estar lista. Una variación que espera a que exista un elemento, descarga una imagen nueva o corre más código libera la página después del control. Supón, solo para dimensionar, que cada 100 milisegundos cuestan 0,6 por ciento de la conversión, el mismo orden de magnitud que Bing midió en ingresos (la sección de velocidad de más abajo muestra de dónde sale ese número y por qué no se traslada directamente a tu sitio). Si la variación se revela 150 milisegundos después del control, pierde 0,9 por ciento. Una variación que vale más 3,00 por ciento aparece como más 2,07 por ciento. Con 250.000 visitantes por brazo, el poder para detectar el efecto cae de 57,52 a 31,87 por ciento, y la muestra necesaria sube de 424.620 a 885.402 por variación.

3. Cuando expira el tiempo límite, el test pierde visitantes de forma selectiva

El tiempo límite existe para que la página nunca quede atascada. Lo que le pasa al visitante que llega al límite es un detalle que cambia el análisis. VWO documenta que, cuando su código agota el tiempo límite, se muestra el contenido original, quien es nuevo en el test no entra en él, quien ya estaba en un brazo ve el original, y las visitas y conversiones no se registran. Entre las causas enumeradas están la conexión débil y la variación demasiado pesada.

Junta las dos frases: si la variación es más pesada, agota el tiempo más veces, y quienes desaparecen de su brazo son justamente los visitantes con dispositivo lento y mala conexión. El brazo queda más pequeño y más rico de lo que debería. Eso aparece como reparto desigual de tráfico (SRM): en un reparto planificado de 50/50, 250.000 visitantes en un brazo frente a 246.900 en el otro ya dan valor p de 0,00001 en el test de proporción, y el verificador de SRM hace esa cuenta con tus números.

Los tres mecanismos son variantes del mismo defecto: la forma de entregar el test afecta la métrica de un brazo de una manera distinta que la del otro. Es exactamente la definición de sesgo de instrumentación, y el motivo por el que un resultado demasiado grande pide desconfianza antes que celebración. Twyman resumió la regla en una frase que Kohavi y coautores citan en el artículo de KDD 2014: cualquier número que parece interesante o diferente suele estar equivocado. El blog trata esa disciplina en ley de Twyman. Con flicker, la señal de alerta es la inversa de la habitual: una variación que pierde de forma consistente, test tras test, en cambios visuales por encima del pliegue.

Cuánto cuesta la velocidad, según quienes la midieron de verdad

Dos fuentes se citan casi siempre que alguien habla de velocidad y conversión, y tienen calidades de evidencia muy distintas.

fuente	diseño	qué afirma	cómo leerla
Kohavi y coautores, KDD 2013 y KDD 2014 (Bing)	experimento controlado de lentitud: 10% de los usuarios retrasados en 100 ms y otro 10% en 250 ms, durante dos semanas	cada 100 ms de mejora aumenta los ingresos en 0,6%	causal, en un buscador de escala enorme; la pendiente vale para ese sitio en ese momento
Deloitte, “Milliseconds Make Millions”, 2020, encargado por Google	regresión logarítmica sobre 4 semanas de datos de 37 marcas y cerca de 30 millones de sesiones móviles	0,1 s de mejora en cuatro métricas de velocidad asociado a más 8,4% de conversión en retail y más 10,1% en viajes	observacional; el informe dice que solo entraron resultados estadísticamente significativos por marca y que Deloitte no auditó los datos

El experimento de Bing es el que sostiene la lógica de esta guía, porque aísla el retraso de todo lo demás. Los autores del artículo de 2014 añaden un detalle importante para el anti-flicker: retrasar 250 ms los elementos del panel derecho, cargados después del evento de carga de la ventana, no tuvo un impacto detectable, a pesar de que el experimento tenía casi 20 millones de usuarios. No toda espera cuesta lo mismo; ocultar la página entera es ocultar justamente lo que está en la ruta crítica.

El estudio de Deloitte es útil como señal de dirección y peligroso como número. Es una correlación entre velocidad y resultado, con selección de los resultados significativos, y un más 8,4 por ciento por 100 milisegundos es el tipo de número que merece la ley de Twyman antes de convertirse en premisa de planificación. El razonamiento completo sobre cómo obtener una pendiente propia está en velocidad de página y conversión.

Y las propias herramientas documentan números de espera. VWO informa que, por defecto, su código asíncrono espera 2.000 milisegundos por la configuración del test y 2.500 milisegundos por la biblioteca, con un límite superior configurable de 5.000 milisegundos que no recomienda superar. No es el tiempo que espera cada visitante, es el techo antes de rendirse. Pero es una escala de segundos, y el experimento de Bing ya midió pérdida de ingresos con retrasos de 100 y 250 milisegundos.

Cómo medir el flicker en tu sitio

No se puede arreglar lo que no se mide, y el flicker tiene la ventaja de ser medible con herramientas que todo navegador ya ofrece. Son cuatro mediciones, de la más barata a la más cara.

1. Tiempo hasta la aplicación, por brazo. En el punto en que el cambio termina de aplicarse, registra una marca con performance.mark. En el control, registra la misma marca en el punto equivalente del código. La interfaz de rendimiento del navegador también expone el primer pintado de contenido (First Contentful Paint), y la comparación entre las dos dice si el visitante llegó a ver el original.

// al final de la aplicación de la variación, y en el punto equivalente del control
performance.mark('ab-aplicado');
const aplicado = performance.getEntriesByName('ab-aplicado')[0].startTime;
const fcp = performance.getEntriesByName('first-contentful-paint')[0];
// si todavía no hubo pintado de contenido, el cambio llegó antes que él
const viuOriginal = fcp ? aplicado > fcp.startTime : false;
enviarEvento('ab_tempo_aplicacao', { braco, aplicado, viuOriginal });

Con el anti-flicker activado, registra también el momento en que se revela la página, porque esa marca es la que define la espera del visitante. Reporta por brazo la mediana, el percentil 75 y el percentil 95, y no la media: el flicker vive en la cola, en los dispositivos lentos.

2. Tasa de visitantes que vieron el original. Es la proporción de viuOriginal verdadero en la variación. Es el número que alimenta la primera columna de la tabla de sesgo de arriba, y el único que dice si el problema es del 2 o del 40 por ciento del tráfico.

3. Test A/A con el snippet. Los dos brazos pasan por el mismo camino de carga y ninguno cambia nada. Sirve para validar el sorteo, el reparto y el conteo, y el camino está en test A/A. No mide el flicker, porque ninguno de los brazos cambia contenido.

4. Test A/A prima. La variación pasa por el camino completo de aplicación, pero vuelve a aplicar exactamente el contenido del control: reescribe el mismo título, cambia la imagen por la misma imagen, vuelve a colocar el mismo bloque. El resultado final en pantalla es idéntico al control, y la única diferencia entre los brazos es el cambio en sí. Si el A/A prima pierde, la pérdida es el costo del mecanismo, y no del contenido.

El nombre no es invento de esta guía. Kohavi y Longbotham usan exactamente ese término (A/A′ en el original, leído “A/A prima”) en el artículo de resultados inesperados de SIGKDD Explorations, para el caso de la redirección: el brazo A prima muestra la misma página, solo que llegando a ella por una redirección. Y el resultado que relatan es el argumento entero de este texto: en todos los casos en que Microsoft corrió ese A/A prima, la versión con redirección tuvo un rendimiento significativamente peor que la otra. Su recomendación se traslada directamente al flicker: preferir un mecanismo en el servidor que genere el HTML y, cuando eso no sea posible, garantizar que control y tratamiento paguen la misma penalización, corriendo A, A prima y B prima para que la comparación entre A prima y B prima sea justa y la diferencia entre A y A prima mida el costo del mecanismo.

Ejemplo trabajado: el A/A prima que perdió un 4 por ciento

Escenario. Una tienda con conversión de 4,00 por ciento y 125.000 visitantes por semana instala la herramienta de test mediante un gestor de etiquetas, de forma asíncrona. La medición del tiempo hasta la aplicación muestra que una parte relevante de los visitantes móviles ve el título original antes del cambio. El equipo quiere saber si eso cuesta conversión antes de correr la próxima tanda de tests de título.

Diseño. Un A/A prima: el control carga el snippet y no cambia nada; la variación reescribe el título y la imagen principal con el mismo texto y la misma imagen. Hipótesis de planificación: pérdida de 4 por ciento relativo (por ejemplo, el 40 por ciento de los visitantes ve el cambio y pierde un 10 por ciento). Métrica primaria: conversión. Duración fijada antes de empezar.

Muestra. Pon los parámetros en la calculadora: tasa actual de 4, efecto mínimo de 4 por ciento relativo, confianza de 95, poder de 80, 125.000 visitantes por semana y test bilateral.

Tasa de conversión actual%Efecto mínimo detectablerelativo (%)absoluto (pp)Confianza909599%Poder8090%Visitantes por semana (total)Testbilateralunilateral

-Visitantes por variación

-Total (2 variaciones)

-Duración estimada

Cálculo por aproximación normal de dos proporciones, 2 variaciones (50/50). Cambia los campos y mira el impacto en vivo.

La pantalla muestra 239.975 visitantes por variación, 479.950 en total y 27 días. La calculadora dimensiona un efecto hacia arriba; una caída del mismo tamaño relativo exige un poco menos (230.949 por variación, con el mismo cálculo), así que 27 días es una estimación conservadora. Para sentir la sensibilidad, cambia solo el efecto mínimo:

pérdida que quieres detectar	visitantes por variación	total	días a 125.000/semana
5% relativo	154.304	308.608	18
4% relativo	239.975	479.950	27
3% relativo	424.620	849.240	48

El equipo redondea a cuatro semanas completas, lo que da 250.000 visitantes por brazo.

La lectura prematura que no se debe hacer. Después de una semana, con 62.500 visitantes por brazo, la variación tenía 2.400 conversiones frente a 2.500 del control. Es la misma pérdida de 4,0 por ciento, con valor p de 0,1450. Parar aquí y concluir que “el flicker no importa” sería leer un test con cerca de 30 por ciento de poder como si fuera prueba de ausencia. Mira el problema del peeking para el costo de mirar antes de tiempo en las dos direcciones.

El resultado. Después de cuatro semanas:

brazo	visitantes	conversiones	tasa
A, snippet sin cambio	250.000	10.000	4,00%
A prima, cambio por el mismo contenido	250.000	9.600	3,84%

Pégalo en la calculadora:

Control (A)

VisitantesConversiones

Variación (B)

VisitantesConversiones

Confianza90%95%99%

Control (A) · Tasa-

Variación (B) · Tasa-

Mejora relativa-

valor-p-

IC 95% de la diferencia-

Test z bilateral de dos proporciones. "Sin significancia" casi siempre significa que falta muestra, no que las versiones sean iguales.

La pantalla muestra una tasa de 4,00% en el control y 3,84% en la variación, mejora relativa de -4,0%, valor p de 0,0036, intervalo de 95 por ciento de la diferencia de -0,3% a -0,1% (pp) y el veredicto Ganadora con significancia · A gana. Detrás del redondeo de la pantalla, la diferencia absoluta es de menos 0,1600 puntos porcentuales, el z vale menos 2,9148, el valor p exacto es 0,003559 y el intervalo va de menos 0,2676 a menos 0,0524 puntos porcentuales.

Qué dice el resultado. El control le ganó a una versión idéntica a él. No existe explicación de contenido; la pérdida es el precio del mecanismo de entrega. Y el reparto era correcto: 250.000 frente a 250.000 no enciende ninguna alerta de SRM, y el A/A con el snippet, corrido antes, había dado 10.000 frente a 10.031 conversiones, con tasa de 4,00% frente a 4,01%, mejora de +0,3%, valor p de 0,8231 y el veredicto Todavía sin significancia. La regla funcionaba; solo pesaba sobre un lado.

Qué hacer con él. Tres consecuencias prácticas. Primero, todo A/B de cambio por encima del pliegue corrido en esa instalación carga una penalización del orden de 4 por ciento, con un intervalo que va de cerca de 1,3 a 6,7 por ciento relativo. Segundo, una variación que perdió por poco en los últimos meses puede haber sido buena. Tercero, la corrección va antes del próximo test: mover el snippet al head, de forma síncrona, y repetir el A/A prima para confirmar que la pérdida desapareció, con la misma lógica de la ronda de confirmación.

Checklist para eliminar el flicker

1. Snippet síncrono y liviano, arriba del todo en el head. Optimizely pide que sea el primer script de la página, justo después de las declaraciones de charset, las meta tags y el CSS. Cualquier script que venga antes retrasa la decisión.
2. Nada asíncrono delante de la herramienta. Un gestor de etiquetas añade una descarga entera antes de la decisión. Si necesitas usarlo, acepta el anti-flicker y mide el costo.
3. CSS de la variación aplicado antes del pintado. Un cambio de estilo puede entrar como regla de CSS en la propia carga síncrona, en vez de esperar a que el documento esté listo para modificar elemento por elemento.
4. Selectores estables. Un selector que depende de la posición o de una clase generada automáticamente falla en silencio o espera un elemento que llega tarde. Usa identificadores o atributos de datos fijos.
5. Anti-flicker acotado y con tiempo límite corto. Oculta solo los elementos que cambian, y solo en las páginas con test activo. Optimizely recuerda que el flicker solo es un problema en cambios visibles durante la carga, por encima del pliegue; un cambio por debajo del pliegue o disparado por una acción del visitante puede no necesitar ocultar nada.
6. Preconnect para los dominios de la herramienta. Optimizely recomienda preconnect y preload para el dominio del snippet arriba del todo en el head, y preconnect para el endpoint de eventos.
7. Variación liviana. Imagen nueva optimizada, poco código, ninguna dependencia extra. La variación pesada es la que agota el tiempo límite y pierde visitantes.
8. El cambio estructural va al servidor o al borde. Layout nuevo, página de precios, flujo distinto: cuando el cambio es grande, cambiar en el navegador es caro y visible. Es el terreno de la experimentación en el edge.
9. Tiempo hasta la aplicación medido por brazo, en todo test. Mediana, percentil 75 y percentil 95, con la tasa de quienes vieron el original. Trátalo como una métrica de guardrail.
10. A/A prima después de cualquier cambio de instalación. Cambiaste el snippet de lugar, cambiaste de herramienta, agregaste un gestor de etiquetas: córrelo de nuevo.

Errores comunes

• Probar el flicker solo en la computadora de la oficina. Una conexión rápida y una máquina potente esconden el problema. El flicker vive en el percentil 95, en el celular con red inestable.
• Creer que el anti-flicker eliminó el costo. Eliminó el parpadeo. La espera sigue, para los dos brazos, y solo aparece frente a un grupo sin snippet.
• Correr un A/A y concluir que no hay flicker. En un A/A ningún brazo cambia nada. Quien mide el costo del cambio es el A/A prima.
• Aumentar el tiempo límite para “no perder visitantes”. Reduce los casos en que se agota y aumenta la espera máxima de quien está en la página oculta. Es un intercambio, no una solución.
• Ignorar un SRM pequeño en un test de variación pesada. La diferencia de tamaño entre brazos puede ser el tiempo límite eliminando justamente a los visitantes lentos de un lado.
• Comparar herramientas solo por el tamaño del script. Lo que importa es cuándo ocurre la decisión respecto al primer pintado. El comparativo de herramientas de test A/B pone el rendimiento junto a los demás criterios.
• Descartar una variación que perdió por poco sin revisar el mecanismo. Una pérdida de 2 a 4 por ciento en un cambio visual por encima del pliegue es exactamente el tamaño que produce un flicker.

Hazlo automático en Donnu

El dolor específico del flicker es que no aparece en ningún lugar del informe. El test termina, la variación perdió por poco, y nadie sabe si perdió por el contenido o por la forma en que se entregó.

El snippet de Donnu se escribió con la regla de no romper nunca la página del cliente, y su código muestra cómo eso se traduce en el problema de esta guía. La configuración del test puede venir incrustada en la propia respuesta del script, y en ese camino la decisión del brazo se toma de forma síncrona, sin una segunda ida a la red (la excepción es la segmentación por etiquetas de WordPress, que espera a que el documento cargue). Si el script se instala de forma síncrona en el head, eso ocurre antes del primer pintado; la etiqueta estándar que entrega el panel es asíncrona, y para ella vale el fragmento anti-flicker descrito a continuación. En ese camino, la página solo se oculta cuando existe un test activo que coincide con esa URL, y control y variación pasan por el mismo camino de ocultar y revelar. Hay un tiempo límite de tolerancia, y ningún fallo rompe ni bloquea la página: si la configuración no llega y no hay una copia guardada en el navegador, el visitante ve la página original, y un error en el código de la variación se descarta en silencio, con la página visible. El panel ofrece también un fragmento anti-flicker opcional, para pegar en el head, que oculta la página antes de que llegue el script asíncrono. Y el snippet tiene un presupuesto de tamaño: la verificación que corre junto con el build falla si el archivo supera el techo.

Lo que ningún snippet resuelve solo es la instalación. Si el script llega mediante un gestor de etiquetas, el navegador ya puede haber pintado el original antes de que exista, y eso vale para cualquier herramienta. Por eso la recomendación honesta es la del checklist: instala de forma síncrona cuando puedas, mide el tiempo hasta la aplicación por brazo y corre un A/A prima antes de confiar en tests de cambio visual. La calculadora de significancia y la calculadora de tamaño de muestra hacen las cuentas de esta guía con tus números.

Referencias

• Kohavi, R., Deng, A., Frasca, B., Walker, T., Xu, Y. y Pohlmann, N. Online Controlled Experiments at Large Scale. KDD 2013. Fuente del experimento de lentitud de Bing que retrasó al 10 por ciento de los usuarios en 100 milisegundos y a otro 10 por ciento en 250 milisegundos durante dos semanas, con la conclusión de que cada 100 milisegundos de mejora aumenta los ingresos en 0,6 por ciento, y de la cita de Twyman de que cualquier número que parece interesante o diferente suele estar equivocado. PDF leído completo. exp-platform.com.
• Kohavi, R., Deng, A., Longbotham, R. y Xu, Y. Seven Rules of Thumb for Web Site Experimenters. KDD 2014. Fuente de la repetición del resultado de 0,6 por ciento por 100 milisegundos, del experimento en el que retrasar 250 milisegundos los elementos del panel derecho cargados después del evento de carga no tuvo un impacto detectable con casi 20 millones de usuarios, y de la aplicación de la ley de Twyman a resultados demasiado buenos. PDF leído completo. exp-platform.com.
• Deloitte Digital, Google y Fifty-Five. Milliseconds Make Millions. 2020. Fuente de la asociación entre 0,1 segundo de mejora en cuatro métricas de velocidad y más 8,4 por ciento de conversión en retail y más 10,1 por ciento en viajes, de la base de 37 marcas y cerca de 30 millones de sesiones en 4 semanas, del uso de regresión logarítmica, de la inclusión solo de resultados estadísticamente significativos por marca y de la advertencia de que Deloitte no auditó ni validó los datos. PDF leído completo. thinkwithgoogle.com.
• VWO (centro de ayuda bajo la marca Wingify). Why Does Wingify SmartCode Time-out and How to Resolve It? Fuente de los tiempos límite por defecto de 2.000 milisegundos para la configuración y 2.500 milisegundos para la biblioteca, del límite superior de 5.000 milisegundos, de las causas de agotamiento (variación pesada, conexión débil, servidor inaccesible) y del comportamiento cuando se agota: original mostrado, visitante nuevo fuera del test y visitas y conversiones no registradas. help.wingify.com.
• Optimizely. Site performance best practices, Load snippet synchronously and asynchronously e Install the snippet as a non-blocking resource. Fuente de las recomendaciones de colocar el snippet como primer script del head después de charset, meta tags y CSS, incluirlo en la respuesta del servidor en lugar de un gestor de etiquetas, cargarlo de forma síncrona porque la carga asíncrona aumenta mucho la probabilidad de parpadeo, y usar preconnect y preload; de la afirmación de que el flicker hace que el resultado del experimento sea menos confiable; y de la observación de que el flicker solo es un problema en experimentos visuales por encima del pliegue, con enmascaramiento mediante visibility: hidden de las partes afectadas. support.optimizely.com · support.optimizely.com · support.optimizely.com.
• Kohavi, R. y Longbotham, R. Unexpected Results in Online Controlled Experiments. SIGKDD Explorations, 12(2), 2010. Fuente del término test A/A prima para un brazo que llega a la misma página por una redirección, del relato de que en todos los casos la versión con redirección tuvo un rendimiento significativamente peor, de la recomendación de preferir un mecanismo en el servidor que genere el HTML o dar la misma penalización a los dos brazos, y del diseño A, A prima y B prima. PDF leído completo. kdd.org.
• MDN Web Docs. PerformancePaintTiming. Fuente de la definición de First Paint y First Contentful Paint expuestos por la interfaz de rendimiento del navegador, usados en la medición de quién vio el original. developer.mozilla.org.

Lee también: Test A/B client-side vs server-side · Cómo implementar pruebas A/B en el servidor · Experimentación en el edge · Velocidad de página y conversión · Sesgo de instrumentación · Test A/A · Calculadora de significancia · Leia em português · Read in English