Bricks Builder Review 2026: Two Years Building Client Sites On It

I moved this entire agency site off Oxygen and onto Bricks in early 2024, and I have not looked back. Two years later I have built or rebuilt a dozen client sites on it, watched it ship four major versions, and it is still the first thing I reach for when someone hands me a WordPress project.

So this is not a spec sheet. This is what it is actually like to build client sites with the Bricks builder for WordPress in 2026, what got genuinely good since the early days, and the parts that still annoy me.

What Bricks builder is, and why I switched to it

Bricks is a theme and a visual builder in one. That distinction matters more than it sounds. With Elementor or Divi you install a theme and then bolt a builder on top, and the two argue with each other about markup and CSS forever. With Bricks the builder is the theme, so the output is one clean, predictable layer instead of two fighting ones.

I came to it the hard way. Over the years I ran client sites on WPBakery, Elementor, LiveCanvas and Oxygen. Every one had its moment. But once I started caring about SEO and Core Web Vitals more than about how fast I could drag a box onto a page, the conversation changed. In 2018 I moved to Oxygen for the clean code. In 2024 I moved to Bricks because it kept Oxygen's lightweight output and added a builder I did not want to throw my laptop across the room over.

If you want the wider field, I put it up against the others in my comparison of the top WordPress page builders. This piece is the deep dive on Bricks specifically.

The interface got out of my way

Here is the thing that sold me first: I can edit basically anything without leaving the canvas. Change the button style once and it changes everywhere. Adjust the header and it is the header on all 40 pages, not a copy I have to remember to sync.

The panel on the left holds the structure, the panel on the right holds the styling, and the middle is your live site. The preview shows you desktop, tablet and phone before you publish, which matters because a WordPress page builder that looks great on a 27-inch monitor and breaks on an iPhone is worse than useless.

Two changes in Bricks 2.0 (July 2025) fixed my two biggest workflow complaints. The Command Palette (hit CMD or CTRL + K) lets me jump to any page, search post types, or type Emmet-style syntax to drop a whole nested layout in without touching the mouse. And the Element Manager lets me globally hide or disable elements I never use, so the insert list is not a wall of things I will never click. On top of that, Bricks 2.0 added granular builder permissions, over 50 of them, so when I hand a site to a client's marketing person they can edit content without nuking the layout. That one alone has saved me support calls.

Design tokens turned it into a real design system

This is the update that changed how I actually work, and it landed in Bricks 2.2 (February 2026): the Style Manager and Color Manager.

Before this, keeping a site's design consistent meant discipline and a lot of copy-paste. Now there is one centralized place for design tokens: theme styles, classes, CSS variables, color palettes, typography scales and spacing scales, all in tabbed panels. The Color Manager builds a scalable palette with light and dark mode variants, generates shades and harmonies, and exports to JSON. The typography and spacing generators build fluid, responsive scales with CSS clamp() under the hood and map them straight to global variables.

In plain terms: I define my client's brand once, as tokens, and the whole site inherits it. Change the primary color in one spot and it cascades everywhere it should, and nowhere it should not, because 2.0 also isolated theme, user and component styles into cascade layers so my overrides stop fighting each other.

And a small thing that saves me real time on redesigns: 2.2 shipped a CSS framework importer, and 2.3 (March 2026) added straight-up paste HTML and CSS into Bricks. Grab a section from a design a client sends me, paste it, and Bricks converts it into native elements, classes and variables. That used to be an afternoon of rebuilding by hand.

Performance is still the whole reason I am here

Bricks runs on Vue 3 and ships lightweight markup, and that shows up in the numbers. This agency site scores in the high 90s on PageSpeed after the move from Oxygen. The classic Bricks-versus-the-rest benchmark still holds up:

Metric	Bricks	Elementor Pro	Divi	Visual Composer
PageSpeed mobile	98	75	64	58
Pingdom result	98	79	82	79
HTTP requests	6	34	23	36
Page size	0.19 MB	1.7 MB	1.5 MB	1.1 MB

Six HTTP requests versus thirty-plus is not a rounding error, it is a different category of site. Bricks helps with a Smart Lazy Asset Loader, native lazy loading, image optimization, and the option to switch off default WordPress scripts you are not using.

Now, the builder is not a performance plugin, and I do not pretend it is. I still pair it with a caching layer, and I wrote up how I test all of this in my website speed testing guide. If a client's site is slow despite Bricks, the answer is usually hosting or an unoptimized asset, and I go through that in my FlyingPress review and my Cloudways hosting review. Fast markup plus good hosting is the combination. Bricks gives you the first half for free.

Building for clients: components, queries, and WooCommerce

The stuff that makes Bricks worth it on real projects rather than demos is the dynamic and reusable side.

Components got serious across 2.0 through 2.2. You can nest components inside components, add style variants (a primary and a secondary button living in one component structure), bind child properties to parent properties, and, crucially, register a Bricks component as a native Gutenberg block so a content editor can drop it into a post without ever opening the builder. For client handoff that is huge. I build the design system, they write the content.

Query loops got genuinely powerful too. Bricks 2.1 (October 2025) added a global Query Manager so I define a query once and reuse it everywhere, plus the ability to query data directly from external REST APIs and render the JSON. It also added creating and updating WordPress posts from frontend forms, which turns a plain site into something closer to a lightweight app. Then 2.3 layered on proper query filter controls: real datepickers, range sliders, searchable multi-selects with Choices.js, styled radios and checkboxes. Faceted filtering on an archive, no add-on required.

For shops, the WooCommerce side covers product, cart and checkout pages with the same drag-and-drop, and 2.0 added native variation swatches (color, image, text) and interaction triggers for cart events. You manage the whole storefront and the design in one place instead of switching tools.

Where Bricks still frustrates me

I would not trust a review that only gushed, so here is the honest part.

The theme library is still thin. Bricks 2.1 added Wireframes and pre-styled Design Sets, which helps, but if you want to buy a finished template and tweak it, this is not that ecosystem. Bricks rewards people who build from a blank canvas.

There is a learning curve, and 2.2 made it steeper before it made it better. The Style Manager, design tokens and the component system are powerful, but they are a real mental model. If you have never touched CSS variables, your first Bricks build will be slow. Someone coming from Elementor's "everything is a widget with a hundred toggles" world has to unlearn some habits.

And it is not free. The pricing is fair, but if your whole plan is a zero-cost site, look elsewhere. Bricks is a tool for people building sites that need to last, and it is honest about that.

I have also written about the other side of the coin, that WordPress itself is not always the right call. If you are questioning the whole stack, read why I stopped using WordPress for some projects. Bricks does not fix WordPress being WordPress. It just makes the good version of it.

When you cannot find an element, you build one

This is the escape hatch that makes Bricks feel like a developer's tool and not a walled garden. If you know PHP, HTML, CSS and JavaScript, you can build a custom element once and use it across every site you make. Plugin authors already do this, which is why the third-party element ecosystem is healthier than the theme one.

It also fits how I actually work: less reliance on plugins, more control over the output. If that is your instinct too, you will like my piece on the WordPress plugins you can replace with a few lines of PHP. Bricks is built for exactly that mindset.

Pricing: pay once, own it

Bricks is not a subscription. You pay a one-off flat fee and use it forever, with the full feature set on every tier. The only difference between tiers is how many sites your license covers, one site on the low end up to a thousand on the top tier. No feature gating, no monthly bill, no "upgrade to unlock this element."

After Elementor's annual renewals and Divi's ecosystem, paying once and being done with it feels almost quaint. For an agency running client sites, the math is obvious.

Would I recommend Bricks builder in 2026?

For the kind of work I do, building fast, custom, maintainable sites for clients who will keep them for years, yes, without hesitation. The performance is real, the design token system finally makes it a proper design tool, and the client handoff story with Gutenberg components is genuinely good.

I would not push it on someone who wants a template they can buy and finish in an afternoon, or someone who has never touched a line of CSS and wants to stay that way. Bricks rewards people who want control, and it asks for a little upfront effort in return.

If you are weighing up a new WordPress project and want a second opinion from someone who has shipped real sites on this thing, that is literally my job. Come say hi at wunderlandmedia.com and tell me what you are building.