Comercio electrónico: la percepción de la velocidad del sitio web marca la diferencia

Todos sabemos que la velocidad del sitio web puede marcar una gran diferencia en la tasa de conversión y la adherencia de un sitio web de comercio electrónico.

Un estudio de caso de SOASTA afirmó que mejorar la velocidad de carga de la página móvil aumentó la tasa de conversión en más del 25%. En su impulso constante por poner al usuario en primer lugar, Jeff Bezos, fundador y director ejecutivo de Amazon, está obsesionado con la velocidad de carga de la página y constantemente impulsa a sus empleados a reducir la velocidad de la página del sitio web de Amazon.

El auge del dominio móvil ha amplificado la necesidad de una velocidad de carga de página más rápida, ya que los usuarios a menudo navegan por sitios web con conexiones más lentas.

Existen muchas herramientas para ayudarlo a mejorar la velocidad de las páginas web, como Yslow o Google Pagespeed Insights, y existen varias prácticas recomendadas, como la minificación y fusión de css y js, el uso de sprites de css y la minimización de las solicitudes de red que un desarrollador front-end debe seguir para garantizar que la velocidad de la página se maximice.

El problema que tenemos es que una vez que sigue las mejores prácticas estándar y se da cuenta de las grandes ganancias, pronto comenzará a ver rendimientos decrecientes en los esfuerzos para mejorar la velocidad general de la página.

Puede dedicar una gran cantidad de tiempo a realizar mejoras incrementales cada vez más pequeñas y este será un proceso costoso y lento. Los desarrolladores front-end con las habilidades y la experiencia necesarias para trabajar a este nivel son sorprendentemente escasos y costosos.

Hay algunas cosas que no puede controlar, como la latencia de la red o las velocidades de conexión móvil, por lo que hay un límite en lo que se puede lograr con la velocidad de página sin procesar. En una conexión 3G, cualquier lugar entre 600 ms y 1 s es consumido por los gastos generales obligatorios de la red, sobre los que no puede hacer nada. Basado en un tiempo de carga de página deseado de 2 segundos, esto nos da solo 1 segundo para jugar. Eso no es mucho.

No se puede negar que la velocidad de la página sin procesar es muy importante y todos los desarrolladores deben seguir las mejores prácticas estándar como mínimo.

Este artículo, sin embargo, no discutirá cómo hacer que su página se cargue más rápido. Hay muchos artículos sobre eso y todo es un poco tecnológico.

Este artículo se centrará en la percepción de la velocidad de la página.
¿Qué es más importante: qué tan rápido carga la página o qué tan rápido percibe el usuario que carga?

Seguramente la percepción es lo que más cuenta para el usuario.

Velocidad del sitio web: primeras impresiones

Centrémonos en la página de inicio de su sitio web. Es probable que contenga una navegación superior, una barra de búsqueda, un banner de héroe, tal vez enlaces a categorías clave, un carrusel y algo de contenido. Las páginas de inicio tienden a tener bastante contenido y cargar todo este contenido rápidamente en una conexión móvil será un gran desafío.

La clave aquí es priorizar la carga de contenido crítico primero, por delante de otro contenido: brinde al usuario algo importante para ver lo más rápido posible.

Mientras procesan esta información crítica, puede comenzar a cargar el siguiente nivel de contenido.

En un dispositivo móvil, gran parte del contenido comenzará en la mitad inferior de la página y, por lo tanto, debe cargarse después del contenido que está en la mitad superior de la página. Es una práctica común fusionar y minimizar JavaScript. Esto normalmente se ve como una mejor práctica, pero puede evitar que priorice la carga de JavaScript crítico antes que el código menos crítico. En su lugar, podría considerar dividir su JavaScript minificado y fusionado y cargarlo progresivamente según sea necesario. No es necesario cargar el JavaScript requerido para realizar una búsqueda antes de cargar el cuadro de búsqueda. Los usuarios no van a escribir caracteres en el campo de búsqueda durante al menos un par de segundos en la carga de una página.

Veamos un sitio que hace esto muy bien. Amazon ha dividido la entrega de activos y contenido para garantizar que el usuario reciba contenido crítico lo antes posible y luego cargue progresivamente los activos en orden de prioridad.

Esta prueba se ejecutó en un simulador de iPhone 6 con una buena conexión 3G y el almacenamiento en caché deshabilitado. Después de que la página se cargó inicialmente, inicié una actualización completa.

En poco más de 600 ms, tengo algo que comienza a cargarse con mi nombre en el encabezado. También notará que solo se han realizado 6 llamadas de red y se han cargado 5 activos (3 archivos css y 2 imágenes).

Solo 50 ms después, ahora veo los componentes clave del encabezado, así como el banner del héroe principal. Ya tengo la percepción de la velocidad, ya que el contenido clave se me entrega muy rápidamente y mis ojos y mi cerebro tienen algo que procesar mientras se carga el contenido adicional.

Después de solo 1 segundo, se carga la navegación principal. Notará que no hay una barra de desplazamiento visible en esta etapa. Esto significa que actualmente no hay contenido debajo del pliegue. No se ha perdido un tiempo precioso cargando este contenido que el usuario no puede ver. También notará que hasta ahora solo se han realizado 13 solicitudes.

En menos de 2 segundos, ahora tengo una nueva sección de contenido importante.

En menos de 3 segundos, ahora percibo que la página se cargó por completo, mientras que la página en realidad tardó menos de 5 segundos en cargarse en su totalidad. Esto sugiere que percibo que el sitio está completamente cargado cuando, de hecho, solo está cargado en un 60 %.

El tiempo real de entrega de contenido variará de persona a persona, pero esto ilustra muy claramente cómo Amazon prioriza la carga de contenido móvil para garantizar que el contenido crítico se cargue lo más rápido posible y que los usuarios perciban que el sitio comienza a cargarse muy rápido.

Ahora echemos un vistazo a un sitio web que no hace esto tan bien. Esta prueba se ejecutó utilizando exactamente las mismas herramientas y la misma velocidad de red que la prueba anterior de Amazon. Si bien el sitio de Charles Tyrwhitt prioriza algunos contenidos, se podría hacer mucho más para acercarse a la optimización de Amazon.

No veo ningún contenido durante casi 7,5 segundos. Inmediatamente tengo la percepción de que este sitio es lento en mi dispositivo móvil. Aunque el sitio prioriza el contenido del encabezado, así como un banner de héroe, puede ver que se han realizado más de 90 solicitudes hasta este punto y, como puedo ver en la barra de desplazamiento, está claro que el contenido debe haberse cargado debajo del pliegue.

Después de 8,5 segundos, puedo ver que un carrusel comienza a cargarse. La cantidad de solicitudes no ha cambiado, lo que sugiere que la mayor parte de las solicitudes relacionadas con el contenido se realizan justo al comienzo de la carga de la página.

No es hasta casi 22 segundos que percibo que el sitio ahora se ha cargado por completo. En realidad, la página tardó un total de 28,4 segundos en cargarse por completo. Esto sugiere que percibo que la página estaba completamente cargada cuando en realidad estaba cargada en un 77%.

Es fácil ver la clara diferencia entre las 2 experiencias. Si bien la página de inicio móvil de Amazon se carga significativamente más rápido que la página de inicio de Charles Tyrwhitt, se ha hecho un esfuerzo para garantizar que los usuarios perciban que es aún más rápida. El usuario comienza a ver que algo se carga dentro del 12,5 % del tiempo total de carga de la página, mientras que los usuarios del sitio web de Charles Tyrwhitt solo ven algo que sucede dentro del 26 % del tiempo total de carga de la página. La página de inicio de Amazon ha realizado 6 solicitudes de red antes de que el usuario vea el progreso, mientras que la página de inicio de Charles Tyrwhitt ha realizado 90 solicitudes.

Esto no pretende ser demasiado crítico con Charles Tyrwhitt, ya que, de ninguna manera, son únicos en la forma en que han construido su sitio web. La mejor práctica aceptada se ha seguido en varias áreas, pero parece que se podría hacer mucho más para mejorar la percepción de la velocidad, así como la velocidad real.

Mejore la velocidad del sitio web priorizando CSS

Es bastante común que los desarrolladores front-end coloquen la mayoría del css de un sitio web en un puñado de archivos y siempre usen css externo, en lugar de en línea. El problema que esto causa es que se debe cargar un archivo css grande antes de que se pueda mostrar cualquier contenido a un usuario.

Una solución a esto es dividir sus archivos css y cargarlos en secuencia con el contenido crítico. Si miramos el ejemplo de Amazon, cargan un archivo css que tiene un tamaño de solo 6.5k como una de sus 6 solicitudes iniciales. Este archivo contiene el css que se requiere para diseñar el contenido crítico en su página de inicio. De hecho, el tamaño total de todos los archivos css que se solicitan antes de que el usuario vea el contenido en la página de inicio móvil de Amazon es inferior a 40 000, mientras que en la página de inicio de Charles Tyrwhitt supera los 500 000.

Esta práctica le permite entregar contenido crítico al usuario muy rápidamente y ayuda a reforzar la percepción de la velocidad.

Haz lo mismo con JavaScript

Además de priorizar css, debe considerar cómo hacerlo también con JavaScript. Casi todos los sitios web de comercio electrónico dependerán en gran medida de JavaScript para funcionar. Esto está bien siempre que JavaScript no bloquee la carga de contenido crítico. Si vuelvo a tomar el ejemplo del sitio web de Charles Tyrwhitt y desactivo JavaScript en mi navegador, ahora veo que el contenido se carga en 4,5 segundos. Este es un cambio masivo en mi percepción de la velocidad de ese sitio web y el JavaScript que se cargó antes del contenido crítico no tuvo impacto en ese contenido y, por lo tanto, no hay razón por la cual el JavaScript no se pueda cargar después de ese contenido.

Hay mucho que los desarrolladores web pueden aprender de la forma en que sitios web como Amazon se centran en la percepción de la velocidad de su sitio web, así como en la velocidad real. Aunque su sitio web es claramente muy rápido, los usuarios lo perciben como aún más rápido debido a la forma en que priorizan mostrar al usuario contenido crítico antes que cualquier otra cosa.

Mucho se ha hablado del impacto que la velocidad puede tener en su tasa de conversión, y los minoristas deberían considerar invertir en optimizar el rendimiento percibido de su sitio web junto con la velocidad real del sitio web.