Es común la idea de que los proyectos desarrollados con Magento son poco performantes.
Mi opinión es, y creo que la mayoría de los desarrolladores van a coincidir, que lo que es a todas luces poco performante es el frontend o mejor dicho los temas que Adobe nos brinda por defecto (Blank y Luma), sobre los cuales se suelen hacer las implementaciones.
Para esto, al día de hoy hay temas alternativos (gratuitos y comerciales) que resuelven el problema. Si se necesita ir un paso más allá están todas las herramientas tecnológicas que se pueden aplicar tanto a un proyecto que use Magento como cualquier otra plataforma (siempre hablando de on-premise) como ser CSS Critical, JS bundling, optimización en formato y servido de imágenes, etc.
Entonces si descartamos el asunto del frontend, donde se esconden los problemas de performance?
En mi experiencia el problema suele estar en decisiones de arquitectura inapropiadas e implementaciones, en muchos casos, poco imaginativas.
Por ejemplo, algo que se repite es la consulta de API’s en tiempo real.
Para los que tienen menos idea, esto significa que el servidor web se quedará esperando la respuesta del API tanto tiempo como sea necesario para completar la petición y devolver la respuesta al cliente.
Es probable que esa consulta al API sea esporádica y el uso de recursos sea despreciable pero ya sabemos, como desarrolladores, que el sistema en ese punto no es escalable. (1 petición va bien, 10 ya es una pesadilla)
Cuando este tipo de prácticas se multiplican a lo largo y ancho de los proyectos vamos acumulando deuda técnica y como dice el dicho lo que mal empieza mal acaba.
En proyectos que suelen durar meses es común que los requerimientos vayan mutando o más bien “redefiniendose” mágicamente y por tanto arquitecturas limitadas pueden llevar al fracaso o a sobre costos que suelen terminar en discusiones con el cliente que no acaban bien o como mínimo minan la confianza mutua.
También tenemos el otro extremo, donde se piensa en una arquitectura súper abstracta que resuelve prácticamente todos los problemas de la humanidad pero que solo la entiende su creador y suele estar llena de opciones que jamás se utilizaran, o lo que es más común, jamás se terminan de desarrollar porque claramente los presupuestos no son infinitos.
Que algo sea escalable no implica que debe ser complejo, el concepto es claro y significa que debe permitir seguir edificando sobre la base de lo que hay sin mayores (idealmente ninguna) alteraciones de lo existente.
Como nadie nace sabiendo y no necesariamente es simple determinar desde el inicio hasta dónde vamos con la arquitectura (por eso he dicho arquitecturas “inapropiadas” y no “malas”) lo mejor es ir haciendo comprobaciones en la medida que vamos avanzando. Siempre es mejor, llegado el caso, cambiar la dirección antes de avanzar demasiado.
Para usar este esquema debemos pensar junto con la propuesta de arquitectura como la vamos a poner a prueba.
El punto de partida de una propuesta, y creo que es donde más se falla, es entender el requerimiento. Veo que es muy común hacer lo que nos piden sin contrastarlo contra un requerimiento explícito que nos permita verificar que la solución es viable en todos los planos. Hacer lo que nos dicen sin cuestionarlo y ponerlo a prueba puede ser un suicidio a mediano plazo.
Otro punto es pensar en las personas, si! Los requerimientos los implementan personas con conocimientos y capacidades dispares. Pensar que tienes un equipo formado por todos los cracks del mundo en todas las áreas es la peor mentira que te puedes hacer a ti mismo (a menos que tu estrategia sea echarles la culpa si algo sale mal 🙂 ).
Recientemente me han pedido que optimice una consulta que muestra en el área privada del cliente un listado de órdenes. Esta consulta, implica consultar muchas tablas con información particular del proyecto.
El tiempo para mostrar la grilla de órdenes (paginada de a 10 registros) para el ejemplo dado tomaba 16 segundos… el tiempo es directamente proporcional a la cantidad de órdenes que tiene un cliente.
Si me hubiese guiado por el pedido inicial, “optimizar” la consulta, y no hubiese intentado ver mas allá de la petición seguramente hubiese optimizado los indices de algunas tablas, tratar de no recopilar tanta información en una misma consulta, apelar a algún tipo de cache, no se….
Estaba claro que ese camino no permitía escalar el sistema, el “problema” era el número de registros no la eficiencia de la consulta.
La solución fue muy simple y barata. Desmenuzamos el requerimiento y decidimos mostrar registros de los últimos 6 meses (el 99% de las consultas) y en forma diferenciada el historial de órdenes.
Pero la consulta del histórico no tardaba tanto como la consulta original?
Si, claro, pero la expectativa del usuario para consultar un historial es muy diferente que la que tiene el usuario para consultar la orden reciente. (En cualquier caso también se optimizó la consulta del histórico y se la mejoró considerablemente)
El acento, desde mi punto de vista, no debe ser puesto en la técnica sino en el criterio. El criterio es el verdadero capital de las empresas.
El mejor “técnico” sin el criterio adecuado no suele ser capaz de orientar el barco en la dirección correcta.
Volviendo a la sentencia del comienzo, Magento sigue siendo la mejor opción para proyectos de comercio electrónico. Debemos ser nosotros los que cada día mejoremos nuestra performance mediante el compartir conocimiento y por sobre todo ser sinceros con nosotros mismos y medir objetivamente nuestros resultados en el camino de entender qué y cómo debemos mejorar.