Shopify y Vercel están reconstruyendo Hydrogen como una base abierta y agnóstica al runtime. Hydroge…
UX de búsqueda por facetas en storefronts Composable: del filtro a la conversión
La búsqueda por facetas es el punto de contacto con mayor intención de conversión en 9 de cada 10 storefronts. Y aun así se sigue tratando como una barra lateral de filtros de 2014. El 92 % de las marcas estadounidenses ya funciona de forma modular o API-driven (CXToday, BigCommerce, Industry Reports mayo de 2026). La capa de búsqueda es una de las superficies más visibles de ese stack, y la superficie UX con menos inversión en los storefronts Composable.
Este artículo explica por qué ocurre, qué cinco patrones funcionan, dónde está el coste de rendimiento y cómo hacer que la UX de búsqueda sea testable.
¿Qué es la búsqueda por facetas?
La búsqueda por facetas es una UX de búsqueda que expone los atributos de producto estructurados (categoría, marca, talla, color, precio, disponibilidad) como filtros combinables. Reduce grandes conjuntos de resultados en pocos clics, sin obligar al usuario a escribir una nueva consulta.
Mini glosario:
- Faceta: una dimensión de atributo (p. ej. «marca», «material»).
- Filtro: una selección concreta dentro de una faceta (p. ej. «Nike» dentro de «marca»).
- Refinamiento: cualquier adición o eliminación de un filtro que cambia el conjunto de resultados.
- Filtro blando: impulsa en lugar de excluir, los resultados se reordenan.
- Filtro estricto: exclusión estricta, solo permanecen los artículos que coinciden.
El Baymard Institute lleva años demostrando que una mala UX de búsqueda por facetas es la principal causa de abandono de búsqueda en las páginas de listado. En los setups Composable esto empeora, porque la capa UX está más lejos del backend.
Por qué los storefronts Composable suelen ser débiles aquí
En un monolito clásico, la API de búsqueda devuelve HTML, contadores y estado en un único roundtrip. En un storefront Composable la separación es más limpia, pero más cara:
- La API de búsqueda (Algolia, Coveo, Elastic, Bloomreach, Klevu, commercetools o Spryker nativos) solo devuelve datos.
- La capa UX tiene que resolver por su cuenta el enmascaramiento de la latencia, la conservación del estado, la sincronización de URL, la densidad en móvil y el A/B testing.
- La hidratación de la barra lateral de facetas suele costar más que la propia parrilla de productos en categorías grandes.
Así que el backend no es el problema. Lo es la capa frontend. Justo ahí es donde los storefronts Composable pierden conversión frente a monolitos más antiguos, pero mejor afinados.
Si quieres más contexto sobre esta brecha de conversión, desarrollamos el principal punto de dolor en La tasa de conversión como reto número uno en setups Composable.
Los 5 patrones de búsqueda por facetas más habituales
1. Barra lateral vertical (el clásico)
Columna izquierda, todas las facetas visibles, selección múltiple. Muy sólida en desktop, dominante en moda, mobiliario y retail tecnológico. Débil cuando la lista supera las 8 facetas y obliga a hacer scroll perdiendo de vista la parrilla de productos.
2. Barra de filtros horizontal superior
Una fila de pills desplegables sobre la parrilla. Funciona bien cuando rara vez superas de 4 a 6 facetas principales (tiendas de marca, shops de una sola categoría). Débil para el refinamiento multiatributo, porque cada desplegable es un estado modal.
3. Filtro modal (el estándar en móvil)
Un botón «Filtrar» abre una hoja a pantalla completa y la selección se confirma con una CTA «Aplicar». Es la convención en móvil, porque una barra lateral no tiene sentido en un viewport de 360 px. Riesgo: los usuarios pierden el contexto de la lista de resultados cuando los filtros requieren más de 2 refinamientos.
4. Facetas inline con search-as-you-type (patrón E-Mart)
Mientras el usuario escribe, las sugerencias en vivo muestran juntos productos y combinaciones de facetas («Nike en talla 42»). Muy potente en storefronts search-first (alimentación, farmacia, catálogos B2B). Requiere una suggest API rápida y un debouncing limpio.
5. Clúster de chips de selección múltiple con vista previa en vivo
Los filtros activos aparecen como chips en la parte superior y cada cambio vuelve a renderizar la parrilla en vivo, sin clic en «Aplicar». Elimina el problema de la confirmación modal, pero cuesta un roundtrip de búsqueda por cada refinamiento. Merece la pena cuando la latencia de búsqueda está por debajo de 200 ms.
Realidad mobile-first: la densidad de facetas es una decisión de compromiso
Un viewport móvil típico mide entre 360 px y 414 px de ancho. De forma realista caben de 3 a 4 encabezados de faceta visibles sin scroll, y solo de 8 a 12 opciones de filtro en una modal antes de que el usuario tenga que desplazarse. No es mucho.
De ahí se derivan tres decisiones explícitas:
- Priorización: ¿cuáles son las 3 facetas más utilizadas en cada categoría? Esas son las que deben ir en la barra de filtros superior, o como «facetas above the fold» dentro de la modal.
- Divulgación progresiva: esconde las facetas de uso poco frecuente detrás de un toggle «Más filtros», en lugar de renderizarlas siempre.
- Botón de confirmación sticky: la CTA «Aplicar» debe permanecer visible en todo momento, de lo contrario pierdes conversión al final de la modal.
Esto enlaza directamente con la brecha de conversión de los storefronts Composable que enlazamos arriba: la fricción de refinamiento en móvil es, de forma medible, una de las 3 palancas principales.
El coste de rendimiento de las facetas: qué es realmente caro
Las facetas son los asesinos de rendimiento más infravalorados en las páginas de listado. En las auditorías de Laioutr solemos ver estos perfiles de coste:
- Hidratación de la barra lateral de facetas: a partir de 60 opciones de filtro, el coste de JS suele situarse entre 80 y 150 ms de bloqueo del main thread. Eso impacta directamente en el INP.
- Contadores de faceta en vivo: cada refinamiento dispara una nueva llamada a la API para los contadores. Sin edge caching en la respuesta de la API de búsqueda, eso son de 150 a 400 ms de red por clic.
- Regresión de LCP por el estado de los filtros: si la página inicial se renderiza en servidor con el estado de los filtros tomado de la URL, suele costar de 200 a 500 ms de TTFB.
Qué ayuda:
- Optimistic UI: la selección del filtro se activa visualmente al instante y la parrilla se carga en paralelo. Los usuarios perciben 0 ms de latencia.
- Edge caching para los contadores de faceta: cachés por categoría con TTL corto, combinadas con stale-while-revalidate.
- SSR en streaming: primero la parrilla de productos, las facetas llegan en streaming. Mejora el LCP sin renunciar a las facetas.
Con esta combinación, los storefronts de Laioutr alcanzan medianas de LCP en torno a 1,2 s con datos de campo reales. No es un número de laboratorio, son evidencias de CrUX del Q2 de 2026 procedentes de frontends en producción.
Haz testable la UX de búsqueda: patrones de A/B testing para el orden de las facetas
En nuestras auditorías, el orden de las facetas es de forma recurrente la palanca con mayor impacto en conversión por unidad de esfuerzo de test. Y aun así, en la mayoría de storefronts Composable ese orden está hard-coded. Es una carencia evitable.
El patrón que funciona:
- El orden como configuración: el orden de las facetas viene de un feed de configuración, no del código frontend.
- Override por categoría: «moda» prioriza distinto que «electrónica». Ambas funcionan con el mismo framework de test.
- Auto-pilot: un agente de sales steering rota el orden automáticamente y conserva la variante con la mejor tasa de add-to-cart por categoría. Sin un ticket de marketing por cada test.
Esa es exactamente la capa agéntica que Laioutr entrega como «A/B test auto-pilot». Más sobre eso y sobre patrones relacionados en nuestros Insights.
Qué ganas
Métrica | Antes (barra lateral estática) | Después (UX de facetas optimizada) |
|---|---|---|
Tasa de rebote en las landings de búsqueda | 48 % | 31 % |
Adopción de filtros (sesiones con al menos 1 refinamiento) | 22 % | 41 % |
Conversión móvil en las listas de búsqueda | 1,3 % | 2,1 % |
Time-to-decision (primer add-to-cart) | 4:20 min | 2:45 min |
Valores de auditorías agregadas de Laioutr del Q1 y Q2 de 2026, cuatro storefronts DACH con más de 50.000 SKU.
FAQ
¿Por qué no confiar simplemente en la búsqueda nativa del backend? La búsqueda del backend devuelve datos y contadores. El estado de la UX, la sincronización de URL, la densidad en móvil y el A/B testing viven en el frontend. Saltárselo te deja una API limpia sin palanca de conversión.
¿Cómo integro Algolia o Coveo en un storefront Composable? Mediante los clientes de búsqueda oficiales en la capa edge (Cloudflare Worker, Vercel Edge), con respuestas en un esquema que alimenta directamente el componente de facetas. Importante: cachea los contadores de faceta en el edge, o la API de búsqueda se comerá tu presupuesto de latencia.
Densidad de facetas en móvil vs. desktop: ¿en qué se diferencia? El desktop admite de 6 a 10 facetas sin fricción. El móvil acepta como máximo de 3 a 4 encabezados de faceta visibles y de 8 a 12 opciones de filtro por hoja. Todo lo que exceda eso va detrás de la divulgación progresiva.
¿Cuánto cuestan realmente las facetas en rendimiento? Números reales a partir de 60 opciones de filtro: de 80 a 150 ms de bloqueo del main thread por hidratación, de 150 a 400 ms de red por refinamiento sin edge cache. Con optimistic UI, SSR en streaming y edge caching te quedas por debajo de 1,5 s de LCP, incluso en 4G.
¿Consejos de A/B testing para el orden de las facetas? Tres palancas de alto impacto: el orden de las 3 primeras facetas, la selección por defecto (p. ej. «en stock» premarcado), la redacción de los encabezados de faceta («talla» vs. «número de calzado»). Testea por categoría, no de forma global. Y asegúrate de que el test pueda salir sin que marketing dependa de ingeniería.
Próximos pasos
La UX de búsqueda no es una funcionalidad que se lanza una vez. Es una superficie que necesita optimización continua, idealmente por parte del propio sistema.
Construye una UX de búsqueda que se optimiza sola