Aprovecha las pruebas A/B para evaluar el impacto de la velocidad del sitio en tus métricas comerciales.
En los últimos años, se estableció claramente que el rendimiento de la velocidad del sitio es una parte significativa de la experiencia del usuario y que mejorarlo beneficia a diferentes métricas comerciales, como los porcentajes de conversiones y de rebote. Se publicaron varios artículos y casos de éxito para respaldar esta afirmación, como Cómo el rendimiento del sitio web afecta las tasas de conversión de Cloudflare, Milliseconds Make Millions de Deloitte y Shopping for Speed on eBay.com, por nombrar algunos.
Si bien el caso de la velocidad es claro, muchas empresas aún tienen dificultades para priorizar el trabajo que mejorará la velocidad de su sitio, ya que no saben exactamente cómo afecta a sus usuarios y, como resultado, a su empresa.
En ausencia de datos, es fácil retrasar el trabajo de velocidad del sitio y enfocarse en otras tareas. Una situación común es que algunas personas de la empresa reconozcan la importancia de la velocidad del sitio y, sin embargo, no puedan justificarla ni convencer a varias partes interesadas para que inviertan en consecuencia.
En este artículo, se proporciona orientación de alto nivel sobre cómo aprovechar las pruebas A/B para evaluar el impacto de la velocidad del sitio en las métricas comerciales, lo que permite tomar decisiones más eficaces sobre el tema.
Paso 1: Elige una página para realizar una prueba A/B
Tu objetivo es probar la hipótesis de que la velocidad de la página se relaciona con las métricas de tu empresa. Para simplificar, puedes limitarte, en un principio, a identificar una sola página para el análisis. El trabajo futuro puede expandirse a varias páginas del mismo tipo para verificar los hallazgos y, luego, a otras áreas del sitio. En la parte inferior de este paso, se proporcionan algunas sugerencias para comenzar. Varios requisitos guían el proceso de selección de páginas:
- La prueba A/B solo debe ejecutarse en los dispositivos de los usuarios de dispositivos móviles. A nivel global, los sitios asociados a los que ayudamos reciben un promedio de más del 50% (y sigue aumentando) de su tráfico desde dispositivos móviles, pero esto puede aumentar significativamente según la región y la vertical. Los dispositivos móviles son más sensibles a los sitios web más lentos debido a las limitaciones de procesamiento y memoria, y a las redes menos estables. Además, los patrones de uso sobre la marcha significan que las expectativas de velocidad son más altas.
La página que elijas para realizar la prueba debe ser una parte importante de tu embudo de conversión. Cada sitio tiene un propósito diferente, por lo que cada uno realiza un seguimiento de métricas de éxito diferentes. Por lo general, estas métricas se relacionan con el recorrido del usuario, que se analiza con un embudo. Por ejemplo, los usuarios de un sitio web de comercio electrónico tendrán que navegar por una página principal, páginas de categorías, páginas de productos y una página de confirmación de compras para completar una compra. Si realizas optimizaciones para generar conversiones, una de esas páginas sería una buena opción.
La página debe tener un propósito único. A menos que tu sitio tenga una misión muy específica, por lo general, es mejor evitar usar la página principal para la prueba. Muchas páginas principales de sitios comerciales son portales a una amplia variedad de funciones que harán que tu análisis sea poco claro. Por ejemplo, si realizas optimizaciones para las vistas de página por sesión en un sitio de noticias, lo mejor sería excluir las secciones no comerciales del sitio y enfocarte en las secciones y los artículos monetizados.
La página elegida debe recibir suficiente tráfico para que no tengas que esperar mucho antes de obtener un resultado con importancia estadística.
La página seleccionada debe ser relativamente lenta. De hecho, cuanto más lento, mejor. Esto no solo significa que es probable que te resulte más fácil mejorar la página, sino que también significa que los datos deberían ser mucho más claros. Puedes realizar un análisis rápido a través del informe de velocidad de Google Analytics o del informe de Métricas web esenciales de Search Console para ver cuáles de tus páginas son más lentas.
La página debe ser relativamente estable. No actualices las páginas (nada que afecte las métricas de la empresa) hasta que se complete la prueba. Cuantos menos factores externos se tengan en cuenta, más claro será el análisis.
Si usas lo anterior como guía, debería quedar un poco más claro qué páginas son buenas candidatas para tu prueba. Las páginas de destino de los anuncios también son una buena opción, ya que es probable que tengas métricas comerciales, pruebas A/B y análisis integrados a tu disposición. Si aún tienes dudas, aquí tienes algunas ideas por vertical:
- Sitios web de contenido: secciones y artículos
- Vitrinas: páginas de categorías y páginas de productos
- Reproductores multimedia: páginas de descubrimiento o búsqueda de videos, página de reproducción de videos
- Servicios y descubrimiento (viajes, alquiler de automóviles, registro de servicios, etcétera): página de entrada de formulario inicial
Paso 2: Mide el rendimiento
Existen dos formas generales de medir las métricas: en el lab y en el campo. En lo personal, consideramos que medir las métricas en el campo (también conocidas como supervisión de usuarios reales [RUM]) es más útil porque refleja la experiencia de los usuarios reales. Entre los ejemplos de bibliotecas y servicios que pueden ayudarte a informar datos de RUM, se incluyen Perfume, Firebase Performance Monitoring y Eventos de Google Analytics.
Hay muchas métricas para elegir, ya que su objetivo es captar diferentes aspectos de la experiencia del usuario. Recuerda que tu objetivo es determinar, en última instancia, si existe una correlación directa entre tu velocidad y las métricas empresariales, por lo que podría ser útil hacer un seguimiento de algunas métricas de velocidad para determinar cuál tiene la correlación más sólida con el éxito de tu empresa. En general, recomendamos comenzar con los indicadores clave de rendimiento web. La biblioteca web-vitals.js puede ayudarte a medir algunas de las Métricas web esenciales en el campo, aunque ten en cuenta que la compatibilidad con los navegadores no es del 100%. Además de las Métricas web esenciales, también vale la pena consultar las otras métricas web. También puedes definir métricas personalizadas, como "Tiempo hasta el primer clic en el anuncio".
Paso 3: Crea variantes de rendimiento de velocidad
En esta etapa, implementarás cambios para crear una versión más rápida de la página que se probará en comparación con la versión actual.
Ten en cuenta lo siguiente:
- Evita hacer cambios en la IU o la UX. Además de que una página sea más rápida que la otra, los cambios deben ser invisibles para los usuarios.
- La medición también es un aspecto clave de esta etapa. Durante el desarrollo, se deben usar herramientas de pruebas de lab, como Lighthouse, para indicar el efecto que tienen los cambios en el rendimiento. Ten en cuenta que los cambios en una métrica a menudo pueden influir en otra. Una vez que las páginas estén publicadas, usa RUM para obtener una evaluación más precisa.
Puedes crear variantes de rendimiento de diferentes maneras. Para la prueba, debes hacerlo de la manera más simple posible. A continuación, se muestran algunas opciones.
Cómo crear una página más rápida
- Usa una herramienta como Squoosh para optimizar manualmente las imágenes de tu página de prueba.
- Usa la cobertura de código de DevTools para eliminar manualmente el código JavaScript o CSS que no se usa solo para esa página.
- Carga secuencias de comandos de terceros de forma eficiente
- Usa una herramienta como Critical para intercalar y separar el CSS crítico.
- Quita el código JavaScript no esencial que no afecte la experiencia del usuario y del que puedes prescindir para la prueba (por ejemplo, ciertas bibliotecas de terceros).
- Implementa la carga diferida a nivel del navegador, que no es compatible con todos los navegadores, pero que puede mejorar el rendimiento de forma significativa en los casos en que sí es compatible.
- Quita las etiquetas de estadísticas que no sean fundamentales o cárgalas de forma asíncrona
Puedes encontrar optimizaciones adicionales que debes tener en cuenta en Tiempo de carga rápido y Lista de tareas para mejorar el rendimiento del frontend. También puedes usar las estadísticas de PageSpeed para ejecutar Lighthouse, que identifica oportunidades para mejorar el rendimiento.
Cómo ralentizar la página
Esta puede ser la forma más fácil de crear variantes y se puede lograr agregando una secuencia de comandos simple, ralentizando los tiempos de respuesta del servidor, cargando imágenes más grandes, etcétera. Financial Times optó por esta opción cuando probó el impacto del rendimiento en sus métricas comerciales: consulta Un FT.com más rápido.
Acelera la carga de la página
En los casos en que la página de prueba (por ejemplo, una página de detalles del producto) esté vinculada principalmente desde otra página (por ejemplo, la página principal), la prefetching o la renderización previa de la página del producto directamente desde la página principal del grupo de prueba acelerará la carga posterior de la página. Ten en cuenta que, en este caso, la división de la prueba A/B (paso 4) se realiza en la página principal. Además, todo esto puede ralentizar la primera página, así que asegúrate de medirlo y tenerlo en cuenta cuando analices los resultados de la prueba (paso 5).
Paso 4: Crea una prueba A/B
Una vez que tengas dos versiones de la misma página en las que una sea más rápida que la otra, el siguiente paso es dividir el tráfico para medir el impacto. En general, existen muchas técnicas y herramientas para realizar pruebas A/B, pero ten en cuenta que no todos los métodos son adecuados para medir el impacto en el rendimiento de la velocidad.
Si usas una herramienta de pruebas A/B, como Optimizely o Optimize, te recomendamos configurar una prueba del servidor en lugar de una prueba del cliente, ya que las pruebas A/B del cliente suelen funcionar ocultando el contenido de la página hasta que se carga el experimento, lo que significa que las pruebas A/B en sí sesgarán las métricas que deseas medir. Si solo puedes realizar pruebas del cliente, considera configurar el experimento en una página diferente y cambiar los vínculos a tu página de prueba para dividir el tráfico. De esta manera, la prueba del cliente no arrastra la página de prueba.
Ejemplo de cambios en el rendimiento de las pruebas A/B en una página de detalles de producto (PDP) determinada a través de pruebas del servidor:
La solicitud se envía al backend, que distribuye a los usuarios a las dos versiones diferentes de la página. Si bien esta es, en general, una buena configuración, a menudo se necesitan recursos de TI para configurar la división del servidor.
Este es un ejemplo de una configuración de prueba del cliente que usa la página anterior (la página principal en el siguiente diagrama) para ejecutar el código JavaScript de prueba:
El código JavaScript de prueba manipula el vínculo saliente para proporcionar a los dos grupos de prueba de usuarios vínculos a las dos versiones del PDP en cuestión. Esto es fácil de configurar y mantener a través de herramientas comunes de pruebas A/B, como Optimizely o Optimize, y no influye en la prueba de rendimiento porque el código JavaScript de prueba se ejecuta en una página diferente.
Como alternativa, puedes elegir dos páginas que se comporten y tengan un rendimiento muy similares (por ejemplo, para dos productos muy similares). Aplica los cambios a uno de ellos y, luego, compara la diferencia en las métricas a lo largo del tiempo. Esto significa que no estás realizando una prueba A/B adecuada, pero aún puede ser bastante útil.
En caso de que tu página de prueba se use como página de destino para campañas publicitarias, puede ser útil usar las herramientas de pruebas A/B integradas de tu red de publicidad, como la prueba dividida de anuncios de Facebook o los borradores y experimentos de Google Ads. Si esa no es una opción, puedes usar dos campañas con la misma configuración y establecer diferentes páginas de destino como objetivos.
Paso 5: Analiza la prueba A/B
Después de ejecutar la prueba durante el tiempo suficiente y tener suficientes datos para sentir seguridad con los resultados, es hora de reunir todo y ejecutar un análisis. La forma de hacerlo depende de cómo se ejecutó la prueba, así que repasemos las opciones.
Si la prueba se ejecutó en páginas de destino de anuncios con las herramientas mencionadas anteriormente, el análisis debería ser tan sencillo como leer un resultado. Si usas Borradores y experimentos de Google, consulta la comparación con el ScoreCard.
Plataformas como Optimizely o Optimize también ofrecen formas fáciles de interpretar los resultados y determinar qué impacto tiene la velocidad en tus páginas.
Si usas Google Analytics o una herramienta similar, deberás elaborar el informe por tu cuenta. Por suerte, Google Analytics facilita mucho la compilación de informes personalizados, así que ahí es donde debes comenzar. Si enviaste datos de velocidad a Google Analytics con una dimensión personalizada, consulta la Guía de informes para obtener información sobre cómo configurarlos y, luego, incluirlos en tus informes personalizados. Asegúrate de que el informe incluya la fecha del experimento y esté configurado para mostrar ambas variantes. ¿Qué debe incluir este informe?
- En primer lugar, debes incluir las métricas comerciales que más te interesan: conversiones, vistas de página, anuncios vistos, porcentaje de conversiones, métricas de comercio electrónico, tasa de clics, etcétera.
- Además, otras métricas de página estándar que también son buenas para mejorar la velocidad del sitio son el porcentaje de rebote, la duración promedio de la sesión y el porcentaje de salida.
También es posible que debas filtrar por dispositivos móviles y asegurarte de excluir bots y otro tráfico que no sea de usuarios. Un análisis más avanzado también filtraría por región, redes, dispositivos, fuente de tráfico y perfiles y tipos de usuarios, como usuarios nuevos en comparación con visitantes recurrentes. Cada grupo de usuarios puede ser más o menos sensible a velocidades más lentas, y identificarlos también es muy útil.
Looker Studio (antes Data Studio) o otras herramientas de visualización de datos facilitan la integración de varias fuentes de datos, incluida Google Analytics. Esto facilita la realización de análisis y también la creación de paneles que se pueden compartir con las muchas partes interesadas involucradas en la administración de un sitio web moderno para lograr una mayor aceptación. Por ejemplo, The Guardian creó un sistema de alertas automatizado que advertía al equipo editorial cuando el contenido publicado recientemente superaba los umbrales de tamaño de página o velocidad, y era probable que generara usuarios insatisfechos.
Paso 6: Saca conclusiones y decide los próximos pasos
Una vez que tengas datos que conecten el rendimiento y las métricas empresariales, podrás examinar los resultados y comenzar a sacar conclusiones.
Si puedes ver claramente una correlación entre mejorar el rendimiento y mejorar las métricas de la empresa, resume los resultados y comunícalos a toda la empresa. Ahora que puedes hablar sobre el rendimiento de la velocidad en un "lenguaje empresarial", es más probable que captes la atención de las diferentes partes interesadas y que el rendimiento de la velocidad del sitio esté en el radar de todos. El siguiente paso es establecer presupuestos de rendimiento en función de los resultados y planificar el trabajo para cumplir con esos presupuestos. Como sabes el valor que proporcionará ese trabajo, podrás priorizarlo según corresponda.
Si no puedes identificar una correlación, consulta las siguientes advertencias y evalúa si se deben ejecutar pruebas similares en otro lugar del sitio (por ejemplo, en todo el embudo de compra o en un tipo de página diferente).
Advertencias
Puede haber varios motivos por los que no se encuentra una correlación significativa entre las métricas de velocidad del sitio y las métricas comerciales:
- La página elegida no tiene suficiente influencia en las métricas comerciales que estás examinando. Por ejemplo, una página de productos más rápida puede no tener un gran efecto en los porcentajes de conversiones si la página de confirmación de la compra es muy poco intuitiva o lenta. Considera analizar métricas más relevantes, como los porcentajes de rebote, los porcentajes de productos agregados al carrito o cualquier otra métrica que esté más directamente relacionada con la página que estás probando.
- La diferencia de velocidad no es lo suficientemente significativa entre las dos versiones. Esto se debe evaluar según las métricas de RUM que midas.
- Hay un error en el mecanismo de pruebas A/B. Es posible que el tráfico no se distribuya correctamente o que las estadísticas no se informen de forma correcta. Para descartar esta posibilidad, considera ejecutar una prueba A/A en la que pruebes la misma versión de una página con el mismo mecanismo de prueba y asegúrate de que no haya diferencias en los resultados cuando lo hagas.
- La velocidad del sitio no influye en tus métricas comerciales. Esto es poco frecuente, pero puede ocurrir en casos en los que tu mercado objetivo sea menos sensible a la velocidad (p.ej., se accede al sitio principalmente desde dispositivos potentes en una red potente) o la demanda de los usuarios es muy alta y la elección es limitada (p.ej., un servicio de venta de entradas que vende exclusivamente entradas para espectáculos con alta demanda). Ten en cuenta que esto no significa que un sitio más rápido no mejorará la experiencia del usuario y, como resultado, afectará la reputación de la marca.
Conclusión
Si bien es tentador lanzar optimizaciones de velocidad en todo el sitio, a largo plazo, suele ser más beneficioso comprender primero lo que significa para tus usuarios y tu empresa tener un sitio web más rápido. Es la diferencia entre decir "mejoramos el FCP en 1.5 segundos" y "mejoramos el FCP en 1.5 segundos y eso mejoró nuestros porcentajes de conversiones en un 5%". Esto te permitirá priorizar el trabajo adicional, obtener la aceptación de las diferentes partes interesadas y hacer que el rendimiento de la velocidad del sitio sea un esfuerzo de toda la empresa.