Estamos muy orgullosos de anunciar que a principios de esta semana lanzamos una nueva versión de nuestro plugin de pruebas A/B para WordPress y, aunque no quede muy bien decirlo nosotros mismos, la verdad es que es una pasada. Nelio A/B Testing 6.0 viene con un rediseño completo de los scripts que metemos en el front-end para la carga de alternativas y el seguimiento de visitantes, haciéndolos más rápidos y seguros. También implementa un nuevo tipo de prueba (una que lleváis tiempo pidiendo) y varias mejoras en las pruebas ya existentes.
Es por eso que hoy me gustaría compartir con vosotros todos los entresijos de esta nueva versión. Con suerte, al final de este artículo, querrás actualizarlo y probarlo de inmediato. Así que, sin más preámbulos, ¡vamos allá!
Simplificando los scripts de carga de alternativas y seguimiento de usuarios
Las pruebas A/B son, en esencia, un proceso bastante simple: dada una página de tu web, creas una versión B alternativa con la intención de que la mitad de tus visitantes vea la versión original y la otra mitad, la B. Luego haces el seguimiento de las acciones que hacen en cada variante y usas los datos recopilados para descubrir qué variante es «la mejor».
Esto significa que cualquier plugin de A/B testing necesita tres cosas:
- Un editor para crear variantes
- Un método para asignar y cargar contenido alternativo
- Un método para recolectar datos
Y nuestro plugin no es ninguna excepción. Ahora bien, al estar diseñado para WordPress, tenemos algunas ventajas. Para empezar, el editor de alternativas viene de serie en WordPress: con Nelio A/B Testing puedes usar tu editor favorito, el que llevas usando todo este tiempo. Genial, ¿no crees?
Si hablamos de la carga de alternativas (2), nuestro plugin combina código PHP y JavaScript. Los scripts de JavaScript se encargan de asignar una variante a cada visitante y redirigirlos a la URL adecuada. El código PHP (que, recordemos, se ejecuta en tu servidor) es el encargado luego de cargar la variante que toca según la URL solicitada aprovechando los filtros y acciones de WordPress.
Finalmente, con respecto al punto (3), nuestro plugin también confía en código JavaScript para escuchar y rastrear los eventos que hacen tus usuarios. Así, podemos tener controladas todas las visitas, clics, eventos y demás que ocurren en tu web.
Anteriormente en Nelio A/B Testing…
Las versiones anteriores de Nelio A/B Testing añadían varios scripts front-end, cada uno con una tarea concreta encomendada:
- el script
alternative-loader.js
se encargaba de determinar si la página actual estaba bajo pruebas y, de ser así, asignaba una variante al visitante y lo redirigía a dicha variante sobrescribiendo la URL del navegador - otro script
main.js
se encargaba de hacer el seguimiento de todos los eventos relevantes cuando confirmábamos que el visitante ya estaba viendo la variante correcta
Para que todo esto funcionara, ambos archivos JavaScript necesitaban sendos scripts en línea con información sobre tu web. En concreto, alternative-loader.js
necesitaba información sobre la configuración del plugin y las pruebas activas en esa páginas, mientras que main.js
necesitaba saber qué eventos eran relevantes para tus pruebas en ejecución (para, así, rastrearlos y poder calcular conversiones y tal).
Cuando implementamos Nelio A/B Testing 5, decidimos dividir ambas tareas en dos scripts porque nos dimos cuenta de que alternative-loader.js
solo debía cargarse en las páginas bajo test (normalmente, unas pocas páginas) y main.js
debía cargarse en todas (porque las conversiones pueden ocurrir en cualquier parte de tu sitio web). De cara a minimizar el impacto de nuestro plugin, pensamos que cargar los scripts según lo que necesitáramos en cada momento era la mejor solución.
Desafortunadamente, con el paso del tiempo, nuestro plugin se volvió más y más complejo para mejorar su compatibilidad con configuraciones de lo más habituales. Por ejemplo, muchos de vosotros usáis plugins de caché y optimización. Entre sus funciones, están las de retrasar y diferir la ejecución de scripts (entre ellos, los de Nelio A/B Testing), y eso generaba problemas a la hora de cargar alternativas y garantizar la ejecución de nuestros scripts en orden. Para solucionar este problema, metimos otro script en línea (conocido internamente como kickoff.js
) que hacía de director de orquesta y coordinaba los otros scripts…, pero no acababa de convencernos esta solución tan compleja.

Nelio A/B Testing
Me sorprendió mucho la calidad del plugin, lo fácil que fue configurarlo y el increíble soporte que me dio Nelio. Recomiendo encarecidamente usar Nelio A/B Testing.

Josette Millar
Solución más simple
En Nelio A/B Testing 6.0 decidimos deshacernos de todo este follón que te acabo de contar y optar por una solución mucho más simple que, además, abre la puerta a nuevas oportunidades. Así, esta nueva versión solo usa un script, public.js
, que aglutina las responsabilidades de todos nuestros scripts anteriores.
Al ser un solo script ya no necesitamos funciones auxiliares para coordinar y orquestar la ejecución de múltiples scripts: tan pronto como se ejecute public.js
, se garantiza que todo funcionará sin problemas y correctamente. Además, evitamos duplicidades entre los múltiples scripts anteriores, con lo que hemos podido optimizar el código fuente y conseguir una solución más pequeña.
Para que te hagas una idea: en versiones anteriores, alternative-loader.js
ocupaba 44Kb, main.js
ocupaba 52Kb y kickoff.js
ocupaba 4Kb (es decir, 100Kb en total). Hoy, public.js
ocupa solo 76 Kb, ¡eso es casi un 25 % menos que antes!
Y, ojo, que encima el script ahora viene con un algoritmo adicional para cargar contenido alternativo mucho más rápido (te lo cuento en un minuto).
Disimulando la carga de alternativas
Uno de los retos con las pruebas A/B es lo que se conoce como «parpadeo de contenido». Básicamente, es lo que pasa cuando un usuario llega a una página en pruebas, ve el contenido A durante un instante y, de repente, se le redirije a la variante que toca y ve cómo las cosas cambian de un estado a otro.
Para solucionar este problema, Nelio A/B Testing implementa una solución simple pero elegante: agrega una capa blanca por encima del contenido que oculta lo que se está cargando hasta que estemos seguros de que lo que hay debajo es lo que debes ver.
Esta capa se añade usando un pseudo-elemento en las etiquetas html
y body
, como puedes ver a continuación:
<style id="nelio-ab-testing-overlay" type="text/css">
@keyframes nelio-ab-testing-overlay {
to { width: 0; height: 0; }
}
html::before, body::before {
animation: 1ms {$time}ms linear nelio-ab-testing-overlay forwards;
background: #fff !important;
display: block;
content: "";
position: fixed;
top: 0;
left: 0;
width: 100vw;
height: 120vh;
mouse-events: none;
z-index: 9999999999;
}
</style>
Tan pronto como el contenido alternativo se haya cargado, nuestro plugin elimina la etiqueta style
del HTML y la capa desaparece.
Pero, ¿y si algo sale mal y nuestro script falla? ¿O qué pasa si tarda demasiado en ejecutarse? ¿Significa esto que la pantalla permanecerá en blanco indefinidamente? No, en absoluto. Si te fijas, verás que el estilo anterior tiene una animación que se ejecuta $time
milisegundos después de añadirse para hacerla desaparecer. Valor que, por cierto, puedes modificar con este filtro.
Las pruebas en línea son pruebas más rápidas
Nelio A/B Testing es un plugin que siempre ha cargado el contenido alternativo realizando una redirección. Es decir, si un visitante llega, por ejemplo, a https://example.com/some-page/
y esta página está bajo test, Nelio le asigna aleatoriamente una variante y modifica la URL para enviarle a la variante que toca:
https://example.com/some-page/?nab=0
es la variante Ahttps://example.com/some-page/?nab=1
es la variante B- etc
Al agregar el argumento nab
en la URL, nuestro plugin se asegura de que cada variante tenga su propia URL única y, por lo tanto, sea posible ejecutar pruebas en webs que usan plugins de cache o están detrás de CDNs. Desafortunadamente, las redirecciones tienen un gran inconveniente: la velocidad. O, mejor dicho, la falta de velocidad.
Piénsalo por un momento: cuando un visitante llega a https://example.com/some-page/
, el navegador solicita la página al servidor y empieza a renderizar su contenido a medida que recibe el código HTML. Además, en paralelo, va descargando todos los recursos que la web incluye (como imágenes, estilos, etc). Sin embargo, cuando le llega el turno a nuestro script y se ejecuta, lo mismo decide que hay que mandar al visitante a otra URL… con lo que todo lo que el navegador ha hecho hasta entonces no ha servido para nada y tenemos que volver a empezar de cero, aunque, ahora sí, en la variante correcta.
Siendo conscientes de este «problema», una de las primeras cosas que hicimos para minimizar el impacto de una redirección en Nelio A/B Testing fue añadir su script público en la parte superior del código fuente de una página. De esta forma, el navegador descargará y ejecutará nuestro script bien pronto y, por tanto, la redirección ocurrirá antes de que el navegador haya invertido mucho tiempo haciendo un trabajo inútil.
Pero queríamos hacerlo mejor.
Nelio A/B Testing 6.0 implementa «pruebas en línea», un tipo de pruebas en las que todas las variantes ya están incluidas en la página y la carga de contenido alternativo no requiere redirección alguna.
Pruebas en línea de CSS
Hablemos un minuto de las pruebas CSS, como ejemplo. Como ya sabrás, una prueba de CSS permite definir hojas de estilo CSS alternativas que solo se cargarán cuando se cargue la variante correspondiente.
En versiones anteriores de nuestro plugin, cuando un visitante accedía a, pongamos, https://example.com/some-page/?nab=1
, Nelio A/B Testing modificaba la etiqueta head
de la página solicitada e incluía el estilo alternativo (salvo que fuera la versión de control, en cuyo caso no metía nada). El resultado era algo parecido a esto:
<!DOCTYPE html>
<html lang="en-US">
<head>
<script id="nelio-ab-testing-main-js" ...></script>
...
<style id="nab-alternative-css" type="text/css">
/* alternative CSS here */
</style>
</head>
<body ...
Como puedes intuir, este enfoque siempre requería de una redirección JavaScript para cargar el estilo alternativo. Y es que el estilo alternativo no estaba disponible hasta que el visitante no accedía a la URL correcta.
Pues bien, Nelio A/B Testing 6.0 reinventa por completo este tipo de test y hace que la redirección ya no sea necesaria. Ahora todos los estilos alternativos están incluidos en la solicitud original. En otras palabras, a la que un usuario entra en https://example.com/some-page/
, nuestro plugin mete todos los estilos dentro, pero los deja inactivos:
<!DOCTYPE html>
<html lang="en-US">
<head>
<script id="nelio-ab-testing-main-js" ...></script>
...
<noscript class="nab-exp-ID nab-alt-1">
<style type="text/css">/* variant B */</style>
</noscript>
<noscript class="nab-exp-ID nab-alt-2">
<style type="text/css">/* variant C */</style>
</noscript>
<noscript class="nab-exp-ID nab-alt-3">
<style type="text/css">/* variant D */</style>
</noscript>
...
</head>
<body ...
Cuando se ejecuta nuestro script y se da cuenta de que tiene que cargar algún estilo alternativo, lo único que tiene que hacer es ir a buscarlo en el propio código de la página y aplicarlo. ¡Así de fácil y sin ninguna redirección de por medio!
Pruebas en línea disponibles
De momento, solo algunos tipos de prueba son compatibles con esta modalidad. En concreto:
- Pruebas de CSS (siempre)
- Pruebas de JavaScript (siempre)
- Pruebas de página, entrada o contenido personalizado (opcional)
Para las pruebas de página (o entrada o contenido personalizado), el modo «en línea» es opcional. Cuando estás editando la prueba, puedes activar o no la opción:

Se trata de un modo opcional porque, como puedes ver, activarlo limita la cantidad de cosas que se pueden modificar de una página. En concreto, solo podrás modificar el título y el contenido, pero no cosas como, por ejemplo, la plantilla que usa la página.
Las pruebas de JavaScript abren un nuevo mundo de posibilidades
Finalmente, Nelio A/B Testing 6.0 tiene un nuevo tipo de prueba: ¡las tan esperadas pruebas de JavaScript! Y no hay sorpresas aquí: una prueba de JavaScript es básicamente como una prueba de CSS, pero en lugar de escribir CSS escribes JavaScript. ¿Quién lo iba a decir, eh?

Simplemente comentarte que hay un par de cosas que debes saber cuando creas este tipo de pruebas. Para empezar, el código que escribas quedará encapsulado en una función como la siguiente:
function( done: () => void, utils: Utils ): void {
/* Your code */
}
type Utils = {
readonly domReady: ( fn: () => void ) => void;
}
de tal forma que:
- tienes acceso a un par de variables llamadas
utils
ydone
. - tienes que avisar a Nelio A/B Testing cuándo has acabado de cargar contenido alternativo haciendo una llamada a
done()
- puedes saber cuándo el DOM está listo (para hacer los cambios que quieras en él) usando
utils.domReady
- tu código no meterá cosas en el ámbito global de la web, salvo que lo hagas explícitamente. Es decir, si quieres definir una variable global
x
o una función globalf
, debes hacerlo usandowindow.x
owindow.f
.
Está guapo, ¿eh? Pues nada, eso es todo lo que quería contarte hoy. Espero que te guste esta nueva versión, que actualices pronto y que saques el máximo rendimiento a tu web con Nelio A/B Testing.
Deja una respuesta