¿Por qué elegimos Hyvä? (Parte II)
Seguimos conociendo Hyvä, particularmente como gestiona el código JavaScript, punto crítico para el éxito de nuestros proyectos de ecommerce.
En la primera parte de esta serie intento darte una visión de la problemática que nos ha traído hasta este punto. En esta nueva entrega ahondamos en la idea de por qué en Ebolution Hyvä nos parece una apuesta de futuro dentro del mundillo de desarrollo de frontend para la plataforma Adobe Commerce (AKA Magento).
Desgranaremos de forma general el conjunto de tecnologías con las cuales está construido el tema Hyvä, y como siguiendo un enfoque “minimalista” afrontamos de forma eficaz dos retos fundamentales de toda tienda de comercio electrónico: 1) entregar valor al cliente de una forma ágil y 2) optimizar lo máximo posible las métricas de los motores de búsqueda, y con ello el posicionamiento de nuestra tienda.
Si quieres saber algo más acerca de cómo comenzó la minirevolución que significa Hyvä, dejo más información en este enlace.
Menos es más
El tema nativo de Magento (Luma) y prácticamente todos los temas basados en este, o con cierto nivel de soporte del mismo, padecen de una problemática similar, dependencia excesiva de recursos especialmente de JavaScript, pero también en cierta medida de CSS.
Ambas dependencias acarrean problemas de diferente índole acerca de los cuales comienzo a dar mi punto de vista en los siguientes párrafos, siendo necesaria para su resolución la aplicación de una serie de técnicas de optimización, tanto estándar como algo más “artesanales” de acuerdo sea el caso.
Primero veamos el problema, después comentamos un poco acerca de las técnicas necesarias para mitigarlo.
Primero JavaScript … en Luma
Esta es la página de inicio de una instalación de Magento en su última versión (actualmente 2.4.5-p1) sin ningún tipo de optimización activa. Como reza el refrán: “una imagen vale más que mil palabras”, y en este caso pienso que es cierto.
No quiero entrar a valorar si 205 peticiones a ficheros individuales de JavaScript son muchas o pocas en una página web moderna, simplemente pensemos en que conforman prácticamente el 85% de todas las peticiones realizadas por el navegador, desde un frontend “tradicional”.
Esta no es una Progressive Web App, o una Single Page Application, aquí no hay un framework de JavaScript de última generación como React, VueJS o similares, que de algún modo hagan pensar que este escenario es justificable.
Simplemente es la forma como está construido el frontend nativo de Magento, puesto que RequireJS solicita al servidor todos los recursos que cree necesitar en un momento dado, y aunque es posible controlar que estas solicitudes sean muy granulares, la realidad es que esto se pone muy poco en práctica y terminamos descargando desde el servidor una cantidad ingente de código que muy probablemente no tenga un uso real dentro de la página que estamos viendo en un momento dado.
jQuery
Mención aparte debo hacer en este punto a la librería jQuery. No la identifiqué antes como un problema porque pienso que no es parte del problema estructural, y aunque he podido ver que en el gremio del frontend hay algo de consenso desaconsejando su uso, no quiero usar este espacio para tomar una posición concreta en su contra. Simplemente pienso que a día de hoy jQuery es en muchos casos innecesaria y mantenerla en proyectos legacy responde o bien al alto nivel de acoplamiento que nuestro desarrollo tenga con dicha librería, o simplemente por la dependencia de algún plugin desarrollado para la misma.
Honestamente, parto de la base de que para usar Select2 (por mencionar sólo un ejemplo al azar y sin intención de quitar mérito a su utilidad), en un único campo de un formulario dentro de la página, no debería ser necesario añadir primero jQuery y luego el propio plugin. Es muy probable que una opción desarrollada con JavaScript nativo igual, o mejor ya exista para este caso concreto.
No obstante, pensar justo lo contrario, o sea que sí es necesario “por si acaso” es lo que obliga a una página web simple como la del pantallazo de arriba a dedicar el 25% de todas sus peticiones de JavaScript a dependencias de jQuery y jQuery-UI, cuando prácticamente ninguna de ellas se usa en absoluto.
No hemos llegado a ese punto aún, pero esta situación se agrava cuando encima de esta base se ponen módulos de terceros, o incluso módulos desarrollados a medida para un proyecto concreto, pero a esto le dedico unas líneas un poco más abajo.
¿Soluciones?
Las posibles soluciones, o por lo menos las más comunes:
Primero que nada, minimicemos, que no vaya ni uno de esos ficheros de forma plana sino en una versión mínima. Primera pieza del puzzle.
Luego un CDN, por supuesto. Estos recursos estáticos no se deben servir directamente desde el mismo sitio donde opera la lógica de negocio de la plataforma. Segunda pieza.
Para evitar posibles bloqueos o tiempos de espera innecesarios, hagamos que la mayor parte de las peticiones de recursos JavaScript carguen al final de la página y de forma asíncrona. Tercera pieza y primer punto de conflicto. La teoría es muy clara, la práctica no lo es tanto. Muchas funcionalidades no están preparadas para esto, hay que estar constantemente alerta de que no se rompan cosas por el camino.
¿Y si juntamos todo el código JavasScript? Cuarta pieza, pero no es tan fácil como suena. El orden de los factores si altera el producto, y como en Magento nativo tenemos RequireJS en medio, son necesarios muchos cálculos nada más para saber cuál va a ser el código necesario. De hecho, la funcionalidad nativa de Magento de JavaScript Bundling está ahí y parece que viene a salvarnos el día, pero no son pocas las quejas que he visto en el ancho y largo mundo de internet con respecto a su uso o a su efectividad.
La lista puede continuar, el campo de la Web Page Optimization (WPO) es apasionante y basto a partes iguales, pero esta sección comenzó con la premisa “Menos es más”, así que paremos aquí.
El meollo de todo el asunto es que se requiere mayor esfuerzo en WPO cuanto más compleja es la base con la que trabajamos.
… ¿y esto mismo en Hyvä?
Veamos qué pinta tiene la página de inicio de la misma tienda, pero ahora con Hyvä.
No, no es magia pero tiene truco. Pero un truco a mi entender bastante bien justificado. Ni siquiera me detengo en el hecho de que tenemos el 8.6% de las peticiones totales de un frontend basado en Luma; ahora me interesa destacar que hay sólo una petición a un recurso JavaScript, y es a una librería que pesa 14.9kB, os presento a AlpineJS.
El truco es que todo el frontend está desarrollado con una filosofía de componentes. Pero no los UIComponents del frontend de Luma que ya dejaba claro antes que para mi puede ser uno de los puntos más complicados de entender y dominar en toda la plataforma Magento.
En su lugar se usa una aproximación ordenes de magnitud más simple, utilizando el potente sistema nativo de layouts de Magento, con Hyvä es posible controlar realmente cuando una pieza de código debe ser cargada en el navegador y ejecutada siguiendo una simple pero efectiva idea:
Si lo veo (literalmente) en el frontend, cargo el JavaScript necesario
Por ejemplo, para conseguir el funcionamiento de mostrar/ocultar paneles de filtros en la vista de categorías, tanto en vista móvil como escritorio:
El código está estructurado de este modo:
Lo que vemos es una combinación de directivas de AlpineJS y código JavaScript nativo lo más cerca posible de los elementos a los que afecta.
AlpineJS… ¿otro framework de JavaScript?
Me parece que el bueno de Willem se inspiró en el mundo de Laravel, siendo este uno de los frameworks de PHP mas en forma en la actualidad, pues las herramientas que selecciono para Hyvä están de algún modo relacionadas.
Es el caso de AlpineJS. En palabras lo más llanas posible, es un framework mínimo de JavaScript pensado para dotar de comportamiento a nuestro código HTML. No es un sustituto de jQuery, ni cuenta con numerosos plugins asociados, simplemente nos permite controlar lo que sucede en el navegador, mostrando/ocultando información y rellenando contenidos de forma dinámica, entre algunas otras funcionalidades, todas ellas más que suficientes para servir de punto de partida de cualquier tienda.
En el extenso mundo de los frameworks JavaScript, donde React, VueJS, Angular y similares llevan la voz cantante en cuanto a herramientas de desarrollo, parece que comienza a surgir el interés en ofrecer paquetes de opciones mínimas.
Por ejemplo, el proyecto petite-vue, que no es más que una simplificación al mínimo posible de funcionalidades de VueJS para hacer prácticamente lo mismo que AlpineJS. Para mi esto último valida al menos su pertinencia, la idoneidad está siempre bajo evaluación.
La incorporación de AlpineJS, en conjunto con el desarrollo de código JavaScript lo más cerca posible del código HTML que lo utiliza, permite que con Hyvä reduzcamos la complejidad inicial de los proyectos permitiéndoles escalar de una forma mas natural.
En el post anterior hablamos de RequireJS, pero también de KnockoutJS, pues justo aquí es donde Hyvä le deja fuera de combate… 😉
No, ahora en serio. Al final del día KnockoutJS es un framework JavaScript bastante más complejo de lo que realmente hace, o le hacemos que haga en Magento, que en resumen no es más que:
“controlar lo que sucede en el navegador, mostrando/ocultando información y rellenando contenidos de forma dinámica, entre algunas otras funcionalidades“
🤔 … es decir, lo mismo que se puede hacer con AlpineJS. Para todo lo demás, que tampoco es muchísimo más, siempre Vanilla JavaScript será el mejor aliado.
¿Y era necesario rehacer todo para facilitar el WPO?
Puede que si. El punto no es que no existan herramientas y técnicas avanzadas de WPO que ayuden a atajar los problemas asociados a la complejidad que estoy describiendo, sino que no estamos obligados a llevarla como lastre desde el mismísimo inicio del proyecto.
Es como querer sembrar patatas y tener que comenzar en un terreno lleno de maleza, o hacerlo en uno que ya ha sido incluso arado. Por supuesto que en algún momento se podrá terminar sembrando igualmente en el primero, pero la labor será mas costosa en términos de esfuerzo y recursos.
El escenario se complica aún más cuando comenzamos a añadir piezas a nuestra tienda.
Por ejemplo, módulos de terceros que dotan de funcionalidad adicional no provista de forma nativa por Magento, o la tan versátil herramienta Google Tag Manager, y similares, que permiten añadir código de forma prácticamente arbitraria a la web.
Este proceso repetido muchas veces (muchos módulos de terceros o a medida, muchas librerías externas inyectadas a la tienda, etc), como es normal en un eCommerce moderno, puede tender fácilmente al descontrol, por ello considero fundamental partir de la mejor base posible en este sentido, como la que ofrece Hyvä.
Vemos por lo menos 55 peticiones adicionales a recursos JavaScript a los de una instalación nueva, cada uno de ellos puede representar una amenaza potencial para el rendimiento de la página, para la forma como la califican los motores de búsqueda, para la experiencia del usuario, etc, etc, etc.
Hyvä no es la única opción
Muchas más cosas están sucediendo ahora mismo en torno a la problemática que estamos planteando, hay mucha gente pensando en esto, y tomando acciones al respecto.
El problema es claro, si nuestra tienda no le gusta a los motores de búsqueda, tenemos más complicado conseguir resultados. Pero además de ello, hilo con la primera parte de esta publicación, no solo el posicionamiento es importante, entregar valor al cliente también lo es tanto o mas, y a mayor complejidad de la plataforma, más difícil será aportar valor de forma ágil.
Es como querer que nuestro coche, de ruedas cuadradas, vaya más rápido. Mucha será la energía que necesitará para apenas moverse… lo siento, último símil 😉
Hyvä es desde mi punto de vista la mejor de esas cosas que están sucediendo, básicamente porque detrás hay una comunidad de personas apostando por una misma idea, lo cual es un activo en si mismo de cara a darle respaldo a un proyecto que sin duda tiene todo el potencial para ayudarnos a satisfacer mejor las necesidades de nuestros clientes.
Como quien dice, para muestra un botón. Cuento 2.735 profesionales en torno a esta idea en la comunidad de Slack del proyecto.
A día de hoy la comunidad oficial de Magento en Slack tiene unos 12.000 miembros. Hablamos de que en Hyvä hay un 22% de ese total, en dos años. Me parece cuanto menos significativo.
Quiero cerrar este post incidiendo sobre lo importante de la simplicidad. Contar con una plataforma muy completa pero lo más simple posible es fundamental a la hora de comenzar a darle forma a un nuevo proyecto de eCommerce.
En la siguiente entrega hablaremos del CSS, que junto con JavaScript, es el cambio mas disruptivo que plantea el uso de Hyvä, en concreto con la incorporación de Tailwind CSS al stack de tecnologías, y analizaremos cómo ambas cosas impactan directamente en los resultados que nuestra tienda ofrece de cara a los motores de búsqueda contribuyendo a mejorar su posicionamiento.
Manuel García Solipa
Tech Lead en Ebolution