WordPress Page Builders in 2026: Elementor, Bricks, Gutenberg and the Real Trade-offs

We inherited a site last spring that took 11 seconds to load the Elementor editor on a 2023 MacBook Pro. Not the front end. The editor. The homepage had 1,843 DOM nodes, of which roughly 700 were nested divs doing nothing but holding padding, and the elementordata postmeta table had grown to 94MB because nobody had ever pruned revisions. The client wanted “a fresh look”. What they needed was an exit plan.

That’s the honest starting point for any conversation about a WordPress page builder in 2026. The tools are far better than they were three years ago. Elementor’s flexbox and grid containers killed the old section/column nesting disaster, Bricks proved a builder can emit markup you’d actually be willing to sign your name to, and Gutenberg finally grew up enough to be a real answer rather than a punchline. The trade-offs just moved. They didn’t disappear.

Here’s what we actually use, when, and what it costs you eighteen months later.

What actually changed since 2023

Three things, and only three, matter.

First, Gutenberg stopped being a beta. WordPress 6.5 shipped Block Bindings and the Interactivity API, which together mean you can build dynamic, ACF-driven layouts without a builder and without writing a React component for every variation. WordPress 6.6 added section-level style variations. 6.8 built the Speculation Rules API into core, so near-instant navigation is now a checkbox for everyone rather than a plugin. None of that made headlines. All of it removed a reason to install Elementor.

Second, Elementor got serious about performance. The container element replaced sections and columns, the CSS loading strategy changed from one global file to per-post files, and font icons went inline as SVG. A hero built with containers in 2026 emits roughly a third of the nodes the same design would have produced in 2021. The catch is brutal: none of this is retroactive. Every site built before containers still ships the old markup, and Elementor’s converter handles simple layouts well and complex ones badly.

Third, the middle of the market consolidated. Oxygen’s team folded their energy into Breakdance, WPBakery quietly became a legacy concern, and Bricks picked up the developers who wanted control without the enterprise pricing. The field narrowed to about four serious choices. That’s healthy.

Elementor vs Bricks: the comparison nobody publishes

The listicles compare feature checklists. Features are the least interesting axis. Here’s what we measure on client builds.

Markup and payload

Bricks emits close to what you’d write by hand. You choose the HTML tag on every element, nesting maps to what you see in the structure panel, and the frontend CSS and JS for a typical marketing page lands somewhere in the 40 to 70KB range before your own assets. Elementor, fully optimised and container-based, tends to land closer to 120 to 200KB once you account for frontend.min.js, Swiper (loaded if any carousel exists anywhere in the render tree) and the eicons fallback. That’s not fatal. On a decent host with proper caching it’s a couple hundred milliseconds of difference at most, and your hero image decision matters more. But it compounds across 60 pages.

Global classes

This is the real divide, and it’s a workflow issue, not a performance one. Bricks has had a proper global class system from the start: define .btn-primary once, apply it everywhere, change it once. Elementor has global colours, global fonts and a growing set of global styles, but class-first authoring has never been its native mental model. Elementor users end up styling individual widgets, then copy-pasting them, then discovering that the client wants the button radius changed on 43 pages.

If you have ever written Tailwind or BEM and liked it, you will be happier in Bricks. If your team is design-led and doesn’t think in classes, Elementor’s direct manipulation is genuinely faster to produce with.

Who has to maintain it

We have handed off Bricks sites to in-house marketing teams and watched them stall. The structure panel, the query loop conditions, the dynamic data tags: all of it assumes a mental model of the DOM. Elementor assumes nothing. If the person maintaining the site after you leave is a marketing coordinator, Elementor is the safer handoff, and that outweighs 80KB of JavaScript.

So the answer to elementor vs bricks isn’t a winner. It’s a question about who touches the site on a Tuesday afternoon six months from now.

Gutenberg in 2026: where it genuinely wins

Gutenberg wins on three fronts and loses on one.

It wins on portability. Block markup lives in post_content as HTML comments wrapping real HTML. Deactivate everything and your content is still readable, still indexable, still there. No other option on this list can say that.

It wins on design system enforcement. A locked-down theme.json stops clients producing a page with seven shades of blue, because the colour picker only offers the palette you defined.

{
  "$schema": "https://schemas.wp.org/trunk/theme.json",
  "version": 3,
  "settings": {
    "appearanceTools": true,
    "color": {
      "custom": false,
      "customGradient": false,
      "defaultPalette": false,
      "palette": [
        { "slug": "brand", "color": "#1a56db", "name": "Brand" },
        { "slug": "ink", "color": "#0f172a", "name": "Ink" }
      ]
    },
    "spacing": {
      "customSpacingSize": false,
      "spacingSizes": [
        { "slug": "40", "size": "clamp(1.5rem, 3vw, 2.5rem)", "name": "Medium" },
        { "slug": "60", "size": "clamp(3rem, 7vw, 6rem)", "name": "Large" }
      ]
    }
  }
}

Setting "custom": false and "customSpacingSize": false is the whole trick. It removes the free-text inputs from the sidebar entirely.

It wins on dynamic content, now that Block Bindings exist. You can bind a paragraph or image to a meta field with no custom block, no React, no build step:

add_action( 'init', function () {
	registerblockbindings_source( 'acme/case-study', [
		'label'              => __( 'Case Study Field', 'acme' ),
		'getvaluecallback' => function ( array $args, $block_instance ) {
			$postid = $blockinstance->context['postId'] ?? gettheID();
			// $args['key'] comes from the block's metadata.bindings attribute
			return getpostmeta( $post_id, $args['key'], true );
		},
		'uses_context'       => [ 'postId' ],
	] );
} );

Where it loses: precise layout control without writing CSS. Getting an overlapping two-column hero with a bleed image and a negative offset is a twenty second job in Bricks and a genuinely annoying one in the block editor unless you’ve prepared a custom block or a pattern. If you go the custom block route, our guide to building a custom Gutenberg block covers the parts that waste the most time.

The lock-in maths

Run this on any inherited site before you quote anything:

wp db query "SELECT metakey, ROUND(SUM(LENGTH(metavalue))/1048576, 2) AS mb, COUNT(*) AS rows
FROM wp_postmeta
WHERE metakey IN ('elementordata','brickspagecontent2','etpbuse_builder')
GROUP BY meta_key;" --skip-column-names

If elementordata is over 30MB you are looking at a site with thousands of unpruned revisions, each one storing a full JSON copy of the page tree. That alone slows every autosave and every backup. We covered the cleanup in detail in the piece on WordPress database bloat, but the short version is: cap revisions at 5 before you do anything else.

Migration cost scales with where the CSS lives. A Bricks or Elementor site where all custom styling sits in a stylesheet with sane class names migrates in a week. A site where 200 individual widgets each carry six lines of custom CSS in their Advanced tab does not migrate. It gets rebuilt. Price accordingly, and tell the client why.

Performance is mostly not the builder’s fault

We audit a lot of slow WordPress sites and the builder is rarely the top offender. The usual ranking, by impact on LCP: uncompressed hero images, no page cache, a shared host with 400ms TTFB, four analytics scripts in the head, a slider above the fold, then the builder’s own payload.

Fix the first four and a container-based Elementor site will pass Core Web Vitals comfortably. We’ve shipped plenty that do. What the builder genuinely controls is CLS from lazy-loaded sections that shift, and INP from bloated JS on interaction-heavy pages. Both are fixable. Neither is a reason to switch tools on its own.

The one honest exception: if you’re building a 500 page content site with heavy template reuse, the per-page CSS files a builder generates become a real cache management problem. That’s a Gutenberg or hand-coded theme job. See also our notes on choosing a theme that won’t wreck your Core Web Vitals, because theme choice constrains this more than builder choice does.

How we choose on client projects

No matrix, just the questions we ask in order.

1. Who edits it after launch? Non-technical marketing team, no dev retainer: Elementor or a well-patterned Gutenberg setup. In-house developer: Bricks.
2. Is there a design system or just a set of comps? Design system with reusable tokens: Gutenberg with a locked theme.json, or Bricks global classes. One-off comps with unique layouts per page: a visual builder saves real hours.
3. How many pages will exist in year two? Under 20 and static: reconsider whether you need WordPress at all.
4. What’s the ongoing budget? Builders create maintenance surface. If there’s no retainer, choose the option with the fewest moving parts, which is core blocks.

That fourth question decides more projects than the first three combined, and nobody asks it during the pitch.

The case for no builder at all

A brochure site with six pages, a contact form and a blog that gets updated quarterly does not need a page builder. It needs good markup and a host that doesn’t fall over. We build a lot of these from the Canvas HTML template when the client has no editing needs, and from CanvasWP when they want WordPress without a builder plugin sitting between them and the output. Forms go to an endpoint rather than a plugin, which removes an entire category of security patching from the equation.

We broke down the actual numbers in the cost comparison between templates, builders and custom builds. The summary: builders win on mid-size sites with ongoing content churn, and lose badly at both ends of the range.