Bricks Builder is known as the fastest, cleanest page builder for WordPress. But as soon as you connect a traditional AJAX filter plugin (such as FacetWP, WP Grid Builder, or JetSmartFilters from Crocoblock) to a Bricks Query Loop, you immediately give that carefully built performance away again. With InstantFilter’s 4 native Bricks elements you keep Bricks’ ultimate building freedom and get 0ms client-side DOM filtering without your database collapsing under heavy SQL queries.
Why traditional filters undermine Bricks Builder performance
Bricks Builder has won the hearts of professional WordPress developers by eliminating the “div soup” and bloat of older page builders. Bricks generates extremely clean, semantic HTML and has a powerful built-in Query Loop. Developers use it to build blazing-fast WooCommerce archives and category pages.
The problem arises when a store needs interactive filtering. Bricks’ native Query Loop itself has no advanced facet filter system. Developers therefore reach for external filter plugins:
- The server-side AJAX reload loop: Every filter change (size, color, price range) sends an AJAX request to the server to re-run the Bricks Query Loop.
- Database overload: The server runs multiple SQL joins across
wp_posts,wp_postmeta, andwp_term_relationships(see our in-depth analysis on fixing slow filter queries in wp_postmeta). With catalogs of 2,000 to 50,000 products (see how we filter 50,000 products instantly), this leads to 500ms to 2,000ms Time To First Byte (TTFB) per click. - Loss of caching: AJAX requests bypass Redis object caching and full-page caching (WP Rocket, LiteSpeed — read our guide on WooCommerce filter caching with Redis and WP Rocket), so every visitor puts a direct drain on your server’s CPU and PHP workers.
In short: you use an ultra-fast builder, but your filter experience still feels slow and stuttery for shoppers on mobile connections (which leads to direct revenue loss — see our research on mobile filter latency and conversions). Do you also build Elementor projects alongside Bricks? Then check out our specific guide for WooCommerce filters in Elementor. InstantFilter solves this at the root.
The 4 native Bricks elements of InstantFilter
Unlike plugins that require you to paste shortcodes manually or attach vague CSS classes to HTML divs, InstantFilter delivers an official, deep integration with Bricks Builder. In the source code (src/Frontend/Bricks/Bootstrap.php), InstantFilter registers four special elements on init (priority 11, right after Bricks core at priority 10) within their own category in the Bricks panel:
1. IF — Sidebar + Grid (`instantfilter-listing`)
This is the complete e-commerce archive shell. The element renders the filter sidebar, toolbar (with sorting and result count), and the product grid in one responsive container. In the Bricks settings panel you configure directly:
- Listing: Select a specific listing from InstantFilter or use the “Universal Archive”.
- Products per page: Number of visible products per page (default 24).
- Card design: Choose a custom-designed card from the Card Builder or use the theme template.
- Force category/tag: Optionally restrict the listing to a specific category slug.
- Default sort: Set the initial sort order (e.g. popularity, price, or date).
2. IF — Grid (`instantfilter-grid`)
Renders only the product grid without a filter sidebar. This is ideal for developers building a custom Bricks layout where the filters are placed elsewhere, such as in a horizontal bar above the products or in a separate Bricks Offcanvas drawer.
3. IF — Filter sidebar (`instantfilter-filters`)
Renders only the filter sidebar for the current WooCommerce context. This element can be placed in any Bricks container, section, or drawer and automatically synchronizes with the product grid on the page.
4. IF — Single filter (`instantfilter-filter`)
Want to render one specific filter standalone (for example only the color swatches or only the price slider)? With this element you choose a specific property key (e.g. pa_color or price) and place the filter exactly where you want it.
The division of labor: Bricks as content wrapper, the Layout Builder for the design
A critical detail for developers working with Bricks: the visual layout of the filters and product cards is NOT done via Bricks style controls, but via InstantFilter’s built-in Layout Builder. This is a fundamental design choice that is directly visible in the Bricks element panel:
“Styling for sidebar, grid, cards, mobile toggle, pagination and offcanvas is managed centrally in ‘InstantFilter → Layouts’. This widget only configures content (listing, per_page, card design).”
— Official settings note in the InstantFilter Bricks elements
Why is it designed this way? If you use a traditional filter plugin combined with a Bricks Query Loop, Bricks has to build and style dozens of nested DOM nodes for each individual product. As soon as a visitor filters, the server has to re-render that entire loop. InstantFilter fully decouples this:
What Bricks does (Content & Context)
In Bricks you define the page layout of your template: where the header sits, how wide the container is, and which InstantFilter element you use. In the Bricks element you configure content only: which listing is loaded, the number of products per page (per_page), the default sort order, and any category restrictions.
What the Layout Builder does (Render & Styling)
In the InstantFilter Layout Builder (in the WordPress dashboard under InstantFilter → Layouts, see the documentation) you define the complete visual structure and styling of the archive. Here you manage the grid columns per breakpoint (Wide, Desktop, Tablet, Mobile), the sidebar styling, the mobile drawer animation, and you design the product cards (images, prices, badges, variation swatches, and add-to-cart buttons).
Bricks Template Resolution & Editor Preview
A notorious problem with many WordPress plugins in Bricks is that Bricks templates (header, footer, archives, and popups) are stored as separate database posts of the post type bricks_template. Standard functions such as has_shortcode() fail on those templates because the content is not in the main post.
InstantFilter handles this elegantly in src/Frontend/FrontendService.php:
- Hook on `bricks_render_data`: InstantFilter hooks into priority 5 of the Bricks render cycle and reads
\Bricks\Database::$active_templates. It scans the_bricks_page_content_2meta field of each active template for filter elements and shortcodes. - REST API Preview in the Bricks Editor: When you work in the Bricks editor, Bricks renders elements via
/bricks/v1/render_elementand/bricks/v1/load_query_page. InstantFilter recognizes these REST endpoints and does load all required frontend assets, so you get a faithful visual preview of your filters and product cards directly in the editor.
Structure Only mode: Perfect harmony with Automatic.css (ACSS)
Many professional Bricks developers use utility frameworks such as Automatic.css (ACSS) or Tailwind, or manage all their styling via Bricks Global Theme Styles. A major frustration with traditional plugins is that they ship opinionated, hard-to-override CSS full of high specificity and !important rules.
InstantFilter introduces the Structure Only mode for this (available in layout settings via styling_mode = "structure"):
What ‘Structure Only’ does:
Look CSS is fully disabled: InstantFilter blocks loading of dist/frontend/style.css and dist/frontend/card.css. No forced background colors, no prescribed fonts, and no intrusive borders.
Functional Machine CSS only: InstantFilter delivers only the necessary functional layout CSS: CSS Grid tracks, responsive column variables (--if-cols-*), the mechanics of the off-canvas drawer, collapsible accordions, and the dual-range slider behavior.
ACSS and Bricks Theme Styles always win: Because InstantFilter does not inject conflicting design styles, your Bricks classes and ACSS utility classes directly control the look of buttons, checkboxes, typography, and cards without CSS fights.
Styling Modes Comparison
- Styled (Default): Full styling via InstantFilter’s visual Style Builder. Ideal if you do not use an external CSS framework.
- Structure only: Clean semantic markup + machine CSS. Ideal for Bricks developers with Automatic.css, Frames, or their own design tokens.
Benchmark: Bricks Query Loop with AJAX vs InstantFilter
What is the actual speed difference in practice? We compared a Bricks category archive of 5,000 WooCommerce products on a standard Cloud VPS (4 vCPU, 8GB RAM):
Step by step: Building a Category Archive in Bricks with InstantFilter
Setting up a lightning-fast archive in Bricks Builder takes less than five minutes:
Step 1: Create an Archive template in Bricks
In WordPress go to Bricks → Templates and click Add New. Choose Archive as the template type. In the template settings set the condition to Post type archive == Products or Taxonomy archive == Product categories.
Step 2: Add the InstantFilter Element
Open the Bricks editor. In the left elements panel, scroll to the InstantFilter section. Drag the IF — Sidebar + Grid element directly into your section or container. InstantFilter immediately generates the archive preview.
Step 3: Configure settings and styling mode
Select the element and adjust the desired number of products per page in the left panel (e.g. 24 or 48). Using Automatic.css or Bricks Global Styles? Then go in the WordPress menu to InstantFilter → Layouts (the Layout Builder) and set the layout to Structure only. Save the template and publish it.
Why developers choose InstantFilter in Bricks
- True native elements: No messy shortcodes or custom code snippets needed.
- 0ms response time: The client-side architecture aligns perfectly with Bricks’ performance philosophy.
- Structure Only mode: No fights with hardcoded CSS; ACSS and Bricks Global Styles work immediately.
What to keep in mind
- Exclusive to WooCommerce: InstantFilter specializes in WooCommerce products and does not support custom post types such as houses or blogs.
- Initial catalog indexing: On first install InstantFilter builds an index in the background. This takes a few seconds to minutes depending on your catalog size.
Frequently asked questions about Bricks Builder & InstantFilter
Go deeper into Bricks & filter performance
Discover more about advanced WooCommerce architecture and how to get the most out of Bricks Builder:
- InstantFilter vs WP Grid Builder
- WooCommerce filter by brand
- Dynamic facet counts without SQL
- Search vs filtering on category archives
- InstantFilter vs JetSmartFilters
- InstantFilter vs FacetWP
- WooCommerce filter for Elementor
- AJAX vs Frontend-first filtering
- Fixing slow queries and wp_postmeta
- View InstantFilter licenses and pricing
Experience 0ms filtering in Bricks Builder
Install InstantFilter on your staging environment and experience the ultimate combination of Bricks Builder and blazing-fast client-side product filtering.