The catalog filter in Woodmart and in Flatsome works with a request per filter action. On a small shop that feels like a smooth update. On a catalog of thousands to tens of thousands of products that request gets slow, because PHP and MySQL recalculate the archive on every click. After the first page load InstantFilter makes no further filter request.
Why is the Woodmart AJAX filter slow on a large shop?
Woodmart describes the shop filter as AJAX: you filter by category, price, color, size, brand, stock, or an attribute, and the results update in place, without a full page reload. That is on their shopping-experience page. The product-filter form documentation says it again: on shop and archive pages the filters work with WoodMart AJAX filtering when AJAX shop is enabled, under Theme Settings → Product archive.
An update without a full reload is still a request. The browser asks the server for the new set of products. WordPress boots, WooCommerce builds the query, the theme sends HTML or JSON back, and the grid is replaced. On a category with a few hundred products that round trip is short. If you are searching for woodmart ajax filter slow, you are at the moment the category has thousands of SKUs and the same round trip takes 800 ms to 2,500 ms, or times out when the workers are full.
This page does not claim that Woodmart’s request is named admin-ajax.php. The official text says AJAX shop and AJAX filtering. The cost is the request, not the filename. In the Network panel you see an XHR when you set a filter. The time on that row is the time the shopper waits.
Why is the Flatsome product filter slow on a large catalog?
Flatsome documents Pjax, PushState Ajax, as ajax-driven navigation. The UX Themes docs, updated on 10 June 2024, say this makes navigation and filtering smoother, and that you turn it on under Advanced → Content Delivery by activating an AJAX option. Pjax fetches a new fragment and places it in the page, without a classic full reload.
flatsome product filter slow is that fragment request on a heavy archive. The theme asks the server for the filtered products. The server runs the WooCommerce query. At 10,000, 20,000, or 50,000 products that query takes time, and the worker stays busy until it finishes. Pjax changes how the result lands in the page. It does not change that there is a request.
The docs call the feature experimental and note that scripts have to start again after a Pjax refresh. That is a front-end detail. It explains widgets that hiccup after a filter. It does not explain a slow query. A slow query shows up in the slow query log and in the duration of the request, whether or not the theme reinitialises a slider afterwards.
What is a theme AJAX catalog filter, apart from the theme name?
A theme filter draws the theme’s WooCommerce grid and refreshes that grid through a request. Woodmart and Flatsome are the two names agencies type most often, because those themes ship the filter. The pattern is the same in other themes that offer “AJAX shop” as a switch: the sidebar belongs to the theme’s product loop, and every click asks for that loop again.
That is a different grid from InstantFilter’s grid. InstantFilter does not filter the theme loop. The archive is its own grid, and the click after load stays in the browser. You do not stack a theme filter and InstantFilter on the same archive list. You choose which grid draws the category. As long as the theme grid is the page, the theme’s request remains the filter.
Why does that request get more expensive as the catalog grows?
The first HTML of the category can be cached. The filter click is a new combination and misses that cache. Every mix of color, size, and price is its own query. On a large catalog the query takes longer, and more shoppers run that query at once. The ceiling is the number of PHP workers. The email that describes it is the post on filters filling PHP workers.
The request itself, whether it comes from a theme or from a plugin, boots WordPress. That file is often admin-ajax.php, sometimes a route of the theme’s own. The filename is the symptom you read in DevTools. The architecture is: one click, one boot, one query. WooCommerce’s lookup table can shorten the attribute join. The boot remains. That is the post on the product attributes lookup table.
PageSpeed stays green as long as it measures the cached category. The shopper measures the click. An agency that puts Woodmart or Flatsome on a shop of tens of thousands of products sees that gap only when the assortment grows, not on a demo with a few dozen products.
How do you replace the theme filter without throwing the theme away?
The theme can keep drawing the header, the footer, and the product page. The archive people filter has to be the grid that makes no request after load. InstantFilter renders that archive on the server for the first HTML, hydrates, and then filters locally in 1.5 ms to 5 ms, with 0 SQL per click. The hub for that architecture is the guide on why WooCommerce filters get slow.
On staging, turn off AJAX shop or the Pjax filter for the archive you are replacing, so two filters do not try to refresh the same list. Then count the requests per click in the Network panel. The theme filter should show a request while it is on. The InstantFilter archive should be quiet after the first load. Use the catalog size as the test, not as the title.
Woodmart and Flatsome stay useful for everything that is not the filter archive. The slow click sits in the catalog filter the theme refreshes with a request. Take that click off the server, and the worker graph during filtering drops, regardless of which of the two themes draws the rest of the shop.
How do you compare Woodmart or Flatsome with a quiet click?
Make a staging clone with the same assortment as production. Leave the theme filter on. Open the Network panel, clear the list, and set one filter. Write down the URL, the method, and the duration. That is the baseline of Woodmart or of Flatsome on this catalog. Repeat it with two facets in a row, so you see whether the second click is as expensive as the first. A warm query can be a little faster. It is still a request.
Then put the archive on InstantFilter and do the same two clicks. After the first HTML the list should show no new filter request. The duration you write down then sits in the browser, in 1.5 ms to 5 ms, not in a worker. Keep both recordings. They are the answer to the client who asks why the theme demo was fast and the shop with the real assortment was not.
Leave the rest of the theme alone during that test. If the header, the menu, or the product page also fire requests, filter those out of the comparison. Only the row that appears at the moment of the facet click counts. The conclusion stays about the catalog filter, not about a font, a pixel, or a search box in the header.
Keep going
The theme supplies the request. These pages explain what that request costs.
- Why WooCommerce filters get slow
- One request per filter click
- PHP workers filling up while people filter
- The lookup table does not remove the request
- Pricing and trial
