Fast product filters for WooCommerce

The usual layered-navigation plugin re-requests the page on every filter change and swaps out a large chunk of DOM, so the shopper waits, the grid flashes, and the scroll position jumps. On a big catalogue the query behind it also gets expensive, adding server delay on top of the frontend cost. The shopper experiences all of this as hesitation right at the moment they are trying to narrow down and buy.

• Full-page or large AJAX reloads on every filter tap
• Whole-grid DOM replacement causing flashes and scroll jumps
• Expensive queries as facet combinations grow
• Layout shift as counts, badges and images settle late

A better model keeps the controls responsive immediately and updates only what changed. The storefront reflects the selection at once, shows a clear pending state while results load, and replaces the smallest region it can get away with. Combined with server-rendered results for the initial view and lightweight updates after, filtering feels immediate even on a mid-range Android phone. The number to hold it to is INP under 200 ms on the filter control itself, measured with CPU throttling, because everything passes on a laptop.

Filter state belongs in the URL. When selecting a colour and a size updates the address to a clean, readable URL, shoppers can share a filtered view, bookmark it, use the back button naturally, and land back on the same results. This also gives you control over which filtered views are meaningful pages. A Next.js storefront encodes filter state in real routes instead of opaque query soup, so the browsing experience and the URL structure are both deliberate.

• Readable URLs that reflect the active filters
• Back/forward and bookmarking work as shoppers expect
• Shareable filtered views instead of session-only state
• A URL structure you can decide to index or not, per view

Filters and SEO have to be reconciled, or faceted navigation floods search with near-duplicate URLs. The rule of thumb is that shoppers can use every filter, but only a small number of genuinely high-demand filtered views are indexable, while the rest are usable without being crawled and indexed. Because filter state lives in real, controllable routes, you can make that decision per view instead of letting a plugin expose thousands of combinations to crawlers.

Under the responsive UI, filtering is a data problem, and on a large catalogue the query is where it succeeds or stalls. Filtering WooCommerce attributes through the default meta and taxonomy queries gets expensive as facets combine, so a fast storefront leans on indexed attributes and pre-computed facet counts, so nothing counts matches on every request. For very large or heavily-faceted catalogues, a dedicated search-and-filter index — ElasticPress, Algolia, Typesense, the same class of engine used for search — returns filtered results and their counts in milliseconds regardless of catalogue size. What makes that instant feel hold up is a query designed to stay cheap at scale, not by hoping the default database path holds up.

• Watch the query count on a category page with three facets applied at once
• Facet counts recomputed per request are the first thing to cache
• Past what MySQL enjoys, the index goes to ElasticPress, Algolia or Typesense
• Test against the full catalogue, not the forty products on staging

The real test is a category with thousands of products and many facets. Performance there depends on efficient querying, sensible result batching and not shipping the entire catalogue to the browser. The storefront pages and streams results, reads counts efficiently, and keeps the interaction light so adding a fourth or fifth filter does not degrade into a stall. Filtering that is fine on a small demo but collapses on a real catalogue is the exact failure this is designed to avoid.

Most WooCommerce filtering runs a database query across product attributes for every combination a shopper selects, and on a large catalogue those queries get expensive quickly. Layer a plugin that re-renders the whole grid over AJAX on every checkbox, and each interaction becomes a round trip plus a full re-render. Filters feel fine on a demo catalogue of forty products and unusable on four thousand: the cost scales with attribute combinations, not with the number of products on screen.

• Attribute queries get expensive as the catalogue grows
• Full grid re-render on every checkbox multiplies the cost
• Counts per option are a separate query each
• Mobile devices pay the JavaScript cost twice over

Every filter combination can generate a URL, and left unchecked that produces thousands of near-identical pages competing with each other and consuming crawl budget. Decide explicitly: valuable combinations that people actually search for — a brand within a category, a size within a type — deserve real indexable pages with their own titles and copy. Everything else should be reachable, usable and excluded from the index. The arithmetic is unforgiving: five filters with four options each is over a thousand crawlable combinations from a single category. Getting this wrong is one of the most common causes of a large store's category pages quietly losing visibility.

A filter plugin is fine on a small catalogue and is the cheapest place to start. A hosted search and filtering service earns its subscription when the catalogue is large, faceted counts matter and relevance needs tuning. Building filtering into the storefront layer makes sense when you already control that layer and want filters that update instantly without a full page round trip. The right answer follows catalogue size and traffic, not preference — and the wrong answer is usually adding a second filtering plugin to fix the first.