Faceted Search UX in Composable Storefronts: from Filter to Conversion

Faceted search is the touchpoint with the highest conversion intent on 9 out of 10 storefronts. It still gets treated like a 2014 filter sidebar. 92 % of US brands are modular or API-driven (CXToday, BigCommerce, Industry Reports May 2026). The search layer is one of the most visible surfaces of that stack, and the most under-invested UX surface in composable storefronts.

This post covers why that happens, which five patterns work, where the performance cost lives, and how to make search UX testable.

What is faceted search?

Faceted search is a search UX that exposes structured product attributes (category, brand, size, color, price, availability) as combinable filters. It collapses large result sets in a few clicks, without forcing the user to type a new query.

Mini glossary:

• Facet: an attribute dimension (e.g. „brand", „material").
• Filter: a concrete selection within a facet (e.g. „Nike" inside „brand").
• Refinement: any add or remove of a filter that changes the result set.
• Soft filter: boost instead of exclude, results get re-ranked.
• Hard filter: strict exclusion, only matching items remain.

Baymard Institute has shown for years that bad faceted-search UX is the top cause of search abandonment on listing pages. In composable setups this gets worse, because the UX layer lives further away from the backend.

Why composable storefronts are often weak here

In a classic monolith, the search API returns HTML, counts, and state in one roundtrip. In a composable storefront the split is cleaner, but more expensive:

• The search API (Algolia, Coveo, Elastic, Bloomreach, Klevu, native commercetools or Spryker) only returns data.
• The UX layer has to solve latency masking, state preservation, URL sync, mobile density, and A/B testing on its own.
• Facet sidebar hydration often costs more than the actual product grid on large categories.

So the backend is not the problem. The frontend layer is. This is exactly where composable storefronts lose conversion against older, but better-tuned monoliths.

If you want more context on the conversion gap, we wrote up the top pain in Conversion rate as the top challenge in composable setups.

The 5 most common faceted-search patterns

1. Vertical sidebar (the classic)

Left column, all facets visible, multi-select. Strong on desktop, dominant in fashion, furniture, tech retail. Weak when the list goes beyond 8 facets and forces scroll without keeping the product grid in view.

2. Horizontal top filter bar

A row of dropdown pills above the grid. Good when you rarely exceed 4 to 6 primary facets (brand stores, single-category shops). Weak for multi-attribute refinement, because every dropdown is a modal state.

3. Modal filter (mobile default)

A „Filter" button opens a full-screen sheet, the selection commits via an „Apply" CTA. Mobile convention, because a sidebar makes no sense on a 360 px viewport. Risk: users lose context of the result list when filters need more than 2 refinements.

4. Search-as-you-type inline facets (E-Mart pattern)

While the user types, live suggestions surface products and facet combinations together („Nike in size 42"). Strong on search-first storefronts (grocery, pharma, B2B catalogs). Needs a fast suggest API and clean debouncing.

5. Multi-select chip cluster with live preview

Active filters appear as chips on top, every change re-renders the grid live, without an „Apply" click. Removes the modal-commit problem, but costs a search roundtrip per refinement. Worth it when search latency is under 200 ms.

Mobile-first reality: facet density is a trade-off decision

A typical mobile viewport sits between 360 px and 414 px wide. Realistically you fit 3 to 4 visible facet headers without scroll, and only 8 to 12 filter options in a modal before the user has to scroll. That is not a lot.

Three explicit decisions follow:

• Prioritization: which 3 facets are the most-used in each category? Those belong in the top filter bar, or as „above-the-fold facets" inside the modal.
• Progressive disclosure: hide rarely used facets behind a „More filters" toggle, instead of always rendering them.
• Sticky commit button: the „Apply" CTA must stay visible at all times, otherwise you lose conversion at the bottom of the modal.

This connects directly to the conversion gap of composable storefronts we linked above: mobile refinement friction is measurably one of the top 3 levers.

Performance cost of facets: what is actually expensive

Facets are the most underrated performance killers on listing pages. In Laioutr audits we typically see these cost profiles:

• Facet sidebar hydration: at 60+ filter options, JS cost often sits at 80 to 150 ms of main-thread blocking. That hits INP directly.
• Live facet counts: every refinement triggers a new API call for counts. Without edge caching on the search API response, that is 150 to 400 ms of network per click.
• LCP regression through filter state: if the initial page is server-rendered with filter state from the URL, it often costs 200 to 500 ms in TTFB.

What helps:

• Optimistic UI: the filter selection becomes visually active right away, the grid fetches in parallel. Users feel 0 ms of latency.
• Edge caching for facet counts: per-category caches with short TTL, combined with stale-while-revalidate.
• Streaming SSR: product grid first, facets stream in. Lifts LCP without killing facets.

Laioutr storefronts hit LCP medians around 1.2 s in real field data with this combination. That is not a lab number, it is Q2 2026 CrUX evidence from live frontends.

Make search UX testable: A/B test patterns for facet order

In our audits, facet order regularly delivers the highest conversion impact per unit of test effort. And yet, in most composable storefronts, facet order is hard-coded. That is an avoidable gap.

Pattern that works:

• Order as configuration: facet order comes from a config feed, not from frontend code.
• Per-category override: „fashion" prioritizes differently than „electronics". Both run from the same test framework.
• Auto-pilot: a sales-steering agent rotates the order automatically and keeps the variant with the highest add-to-cart rate per category. No marketer ticket per test.

That is exactly the agentic layer Laioutr ships as the „A/B test auto-pilot". More on that and on related patterns in our Insights.

What you gain

Values from aggregated Laioutr audits Q1 and Q2 2026, four DACH storefronts with 50k+ SKUs.

FAQ

Why not just rely on native backend search? Backend search returns data and counts. UX state, URL sync, mobile density, and A/B testing live in the frontend. Skipping that gives you a clean API without a conversion lever.

How do I integrate Algolia or Coveo into a composable storefront? Via the official search clients in the edge layer (Cloudflare Worker, Vercel Edge), with responses in a schema that feeds the facet component directly. Important: edge-cache facet counts, otherwise the search API eats your latency budget.

Mobile vs. desktop facet density: how does it differ? Desktop handles 6 to 10 facets without friction. Mobile takes 3 to 4 visible facet headers max, and 8 to 12 filter options per sheet. Anything beyond that belongs behind progressive disclosure.

How expensive are facets really in performance terms? Real numbers at 60+ filter options: 80 to 150 ms of main-thread blocking per hydration, 150 to 400 ms of network per refinement without an edge cache. With optimistic UI, streaming SSR, and edge caching, you land under 1.5 s LCP, even on 4G.

A/B test tips for facet order? Three high-impact levers: order of the top 3 facets, default selection (e.g. „in stock" pre-selected), wording of facet headers („size" vs. „shoe size"). Test per category, not globally. And make sure the test ships without marketing blocking on engineering.

Next steps

Search UX is not a feature you ship once. It is a surface that needs continuous optimization, ideally by the system itself.

Build a search UX that optimizes itself

More from the Laioutr Platform

• Composable and headless frontend at Laioutr
• Personalization as an AI touchpoint
• A/B testing as a conversion lever