Desarrollo e-commerce: sztuczne-rosliny.pl

#sztuczne-rosliny.pl

El problema de una tienda de plantas artificiales no está en la portada, está en la lista de categoría. El cliente llega mirando fotos y termina comprando por datos: altura, material, tipo de maceta y si la pieza encaja en el espacio donde va a quedarse. Cuando el catálogo crece, esas dos formas de buscar chocan dentro de la misma pantalla, y ahí se decide si la tienda vende o si el visitante se va a pedir presupuesto por teléfono.

sztuczne-rosliny.pl pertenece a una empresa que importa y distribuye plantas artificiales, trabaja también como mayorista y suministra composiciones vegetales para oficinas, hoteles, restaurantes, centros comerciales y stands de feria, con montaje y asesoramiento incluidos. La sede está en Varsovia y hay una delegación en Białystok, y el surtido incluye árboles, hierbas, flores, macetas y variantes ignífugas o resistentes a la radiación ultravioleta (fuente: sztuczne-rosliny.pl). La marca compite por calidad de producto y no por precio, y eso condiciona la tienda entera: la ficha tiene que sostener una comparación que el cliente hará de todos modos.

La implantación duró unas seis semanas. La capa técnica es WordPress con un modelo de producto propio, caché de objetos en Redis, HTML5, CSS3 y SASS en la interfaz, AJAX en la búsqueda y una CDN delante de las imágenes. El layout y la colocación de los elementos los aportó el cliente; sobre eso construí las plantillas, el modelo de datos y las integraciones.

#Qué resolvía el proyecto

El encargo se puede resumir en una frase: que una persona sin conocimientos técnicos pueda mantener un catálogo grande, y que un comprador llegue al producto correcto en pocos movimientos. Todo lo demás sale de ahí.

La base es el modelo de producto, construido sobre tipos de contenido propios y campos personalizados en lugar de descripciones escritas a mano. Altura, material, color, fabricante, tipo de maceta y acabado son valores en la base de datos, no frases dentro de un párrafo. La diferencia aparece en el primer filtro que alguien pide. Si la altura vive solo en el texto, el filtro de ciento veinte a ciento ochenta centímetros no se puede construir, porque no hay nada que comparar. Se puede disimular con etiquetas del tipo alto y muy alto, pero entonces el límite es una opinión, cada persona que edita lo entiende a su manera, y el comprador descubre la medida real ya dentro de la ficha. En un pedido para el vestíbulo de un hotel con altura de techo fijada, eso separa un minuto de elección de una devolución de dos metros de ficus.

Esta estructura tiene un coste que conviene decir en voz alta. Dar de alta un producto lleva más tiempo, porque el formulario tiene una docena de campos en vez de una caja de texto. El conjunto de atributos hay que pensarlo antes, ya que cambiarlo después es una migración de datos y no una corrección de redacción. La inversión se devuelve con cada nuevo centenar de referencias y con cada rediseño, porque los campos se colocan en una maquetación nueva con una sola plantilla, mientras que los datos escritos dentro del texto hay que repasarlos uno a uno.

#Filtrado, la consulta más cara de la tienda

La búsqueda y el filtrado funcionan de forma asíncrona, así que acotar la lista no recarga la página y el resultado aparece al momento. Cómodo para quien compra y caro para la base de datos, porque cada movimiento del control de altura es una consulta nueva.

Filtrar por varios atributos a la vez es la operación más costosa que existe sobre un listado de productos en WordPress. La consulta une las tablas de relaciones de taxonomía y de campos adicionales, y con cada condición activa el número de uniones crece más rápido que el número de filtros. Por eso el cuello de botella de una tienda así no es la portada, que prueba todo el mundo, sino la vista de categoría con tres filtros marcados, que no prueba nadie.

De aquí salieron tres decisiones prácticas. Los resultados de las combinaciones de filtros que se repiten se cachean por separado, porque la misma combinación vuelve más a menudo de lo que parece. Los contadores junto a cada opción, es decir cuántos productos hay detrás de cada valor, son la parte más cara de la vista y merece una decisión consciente si compensan. Y las pruebas solo valen sobre una copia de producción con el catálogo completo: en una instalación vacía con veinte productos todo va rápido, porque la base entera cabe en memoria y no hay nada que optimizar.

#Datos de proveedores de dos mercados

El surtido llega de fabricantes de Asia y de Europa, y eso significa formatos distintos, frecuencias distintas y calidades distintas. Un proveedor manda una hoja de cálculo con la especificación completa; otro, un fichero donde la altura aparece unas veces en centímetros y otras en pulgadas, y donde el nombre del color existe en tres grafías.

La capa de sincronización tiene una tarea previa a todas las demás: reducir eso a un vocabulario único antes de que toque el catálogo. Es un trabajo aburrido del que depende todo lo que viene después, porque un filtro por material solo funciona si diez formas de escribir el mismo plástico se han unificado en un valor. Lo que no se pueda clasificar debe quedarse visible en una lista de errores en lugar de colarse en silencio. Cinco minutos de trabajo editorial son más baratos que una referencia que está en el almacén y no aparece en ninguna búsqueda.

La segunda decisión es de quién es cada campo. El stock y el precio de compra son del proveedor y se pueden sobrescribir en cada pasada. La descripción, las fotos y la asignación a categorías son trabajo de la tienda y no se pueden tocar, porque entonces la importación nocturna borra lo que ha construido la redacción. La ausencia de esa frontera es la causa más común de avería en integraciones de producto, y siempre se manifiesta igual: a la mañana siguiente media tienda vuelve a llevar el texto del fabricante.

La tercera cuestión son las referencias que el proveedor descataloga. Borrarlas mata una dirección que está en los resultados de búsqueda y en los marcadores de compradores profesionales. Tiene más sentido marcar el producto como no disponible, mantener la página viva y enseñar alternativas al lado, porque en este sector proponer un árbol parecido forma parte normal de la venta y la mercancía se trae bajo pedido.

#Fotografía, entrega de archivos y picos de temporada

Aquí la fotografía no ilustra el producto, lo describe. El comprador juzga el tono del verde, la textura de la hoja y cómo se asienta la planta en la maceta, que es justo lo que separa una pieza convincente de otra que se delata a dos metros. Las galerías son amplias, los archivos pesan, y casi todo el peso de la página está ahí. No se arregla quitando fotos, así que se resuelve en la entrega.

El reparto de trabajo es sencillo. La CDN se lleva del servidor un tráfico que no debería atender y sirve las imágenes desde un punto más cercano al visitante. Redis acorta el trabajo de montar la página cuando no se puede devolver una respuesta ya preparada. A eso se suman la optimización de imágenes y un límite a la cantidad de hojas de estilo y scripts que arrastra cada vista, porque en un catálogo donde las fotos ya pesan, cada script extra se paga con el producto.

El tráfico tampoco se reparte de forma regular a lo largo del año. Sube antes de las fiestas y en las temporadas en las que las empresas acondicionan oficinas y locales, y hay días sueltos que traen varias veces la carga habitual. Ajustar la tienda a la media mensual sirve de poco. Lo que cuenta es el comportamiento en la hora punta, y en esa hora decide menos la velocidad del código que cuántas peticiones llegan siquiera a la aplicación.

#Pago y el límite de la caché

La tienda está conectada a pasarelas de pago y a la gestión de pedidos. Este es el punto donde el trabajo de rendimiento tiene que detenerse, y conviene entender por qué.

El carrito, el resumen del pedido y la página posterior al pago son distintos para cada usuario por definición. Meterlos en una caché de página completa termina en el peor fallo posible en comercio electrónico, que es enseñar a un cliente el carrito de otro. Por eso esas rutas quedan fuera de la caché de página, y la velocidad se busca en otro sitio: la caché de objetos en Redis acorta el montaje de la página también donde no se puede guardar una respuesta terminada.

La vuelta desde la pasarela es un caso límite aparte y hay que probarlo sobre una copia de producción. El cliente puede cerrar el navegador antes de regresar, volver dos veces, o encontrarse con que la notificación servidor a servidor del operador llega antes que su propia redirección. El estado del pedido tiene que salir de esa notificación y no de si el navegador aterrizó en la dirección correcta. Al revés, aparecen pedidos pagados que figuran como pendientes, y eso se descubre cuando alguien cuadra la contabilidad.

Queda un asunto que en una tienda paramétrica siempre hay que cerrar antes de publicar. Las páginas de categoría y los resultados de filtrado generan muchísimas direcciones que se diferencian solo en el orden de los parámetros, y esa es la manera clásica de diluir la visibilidad de un catálogo. Hay que decidir de antemano qué combinaciones son páginas propias e indexables y cuáles se quedan como herramienta de navegación sin dirección propia en el buscador. No dispongo de mediciones del efecto de ese trabajo, así que no doy ninguna.

#Resultado

Lo que decidió la calidad de esta tienda fue el modelo de datos y no la capa visual. Los parámetros guardados como campos, y no como frases, hicieron posible el filtrado sobre el que se apoya todo el recorrido de compra. La separación entre campos que pertenecen al proveedor y campos que pertenecen a la tienda permite sincronizar la oferta sin borrar el trabajo de la redacción. Sacar el recorrido de compra de la caché de página y acelerarlo con caché de objetos concilia rendimiento con pedidos correctos.

Al siguiente proyecto se traslada la capa técnica y la forma de trabajar: WordPress con modelo de producto propio, Redis, CDN y pruebas de filtros y de pago sobre copia de producción. No se traslada el diccionario de atributos de esta tienda ni sus integraciones con proveedores, porque nacieron para un surtido concreto y unos formatos de fichero concretos. Un proyecto nuevo empieza por un análisis de alcance, y el presupuesto viene después.