WPBakery Page Builder is the WordPress tool almost nobody chose on purpose. For more than a decade it shipped bundled "free" inside thousands of ThemeForest themes — Salient, The7, Avada-era alternatives, and countless niche templates — which means most people running it today inherited it rather than evaluated it. So the honest version of the question isn't "is WPBakery the best page builder?" It's "I already have it on a site that works — should I keep it, and what does leaving actually cost?" That's a different and more useful question, and the answer turns almost entirely on one technical fact about how WPBakery stores your content.

The shortcode architecture is the whole story

WPBakery is a shortcode-based builder. When you drag a row, a column, and a text block onto a page, it doesn't save a structured layout in a separate table or a clean block format. It writes nested shortcodes directly into your post content, like this:

[vc_row][vc_column width="1/2"][vc_column_text]Your text[/vc_column_text][/vc_column][/vc_row]

Everything you build is stored as text like that, interpreted at render time by the plugin. This single design decision explains both why WPBakery felt convenient in 2015 and why it's a liability in 2026.

The convenience: shortcodes are theme-agnostic and self-contained, so a theme author could bundle the builder, ship a hundred demo layouts, and have them render anywhere. The liability: those shortcodes only mean anything while the plugin is active. Deactivate WPBakery — or migrate to a theme that doesn't include a license for it — and every page collapses into visible raw shortcode soup. Your homepage becomes literal [vc_row] text in front of visitors. There is no graceful degradation.

This is the key contrast with the alternatives. Gutenberg stores blocks as HTML comments wrapped around real markup (), so if you disable the block, the underlying HTML still renders as plain content. Builders like Bricks and Breakdance store layout as structured data and output clean markup. WPBakery's shortcodes are the most locked-in format of the major builders, and that lock-in is the thing to weigh before you do anything else.

Clearing up the WPBakery vs. Visual Composer confusion

Before going further, it's worth untangling a naming mess that trips up almost everyone, because getting it wrong leads to buying the wrong product. These are two separate plugins from the same company:

WPBakery Page Builder is the original shortcode plugin. Until October 2017 it was actually called "Visual Composer," which is why old tutorials and theme docs use that name. It edits the content area only — it can't touch your header, footer, or sidebar.
Visual Composer Website Builder is a separate, newer product. It's a from-scratch rewrite built on React with no shortcodes, and it controls the entire site including headers and footers. It is not a drop-in replacement for WPBakery — you can't simply switch one for the other and keep your layouts.

So when someone says "I use Visual Composer," they almost always mean the old shortcode WPBakery plugin bundled with their theme — not the modern rewrite. If you're shopping, know which one you're actually buying.

Where WPBakery hurts you in 2026: performance

The reason this matters beyond nostalgia is Core Web Vitals. Google's field thresholds for a "good" experience are LCP under 2.5 seconds, INP under 200 milliseconds (INP replaced FID as a Core Web Vital in March 2024), and CLS under 0.1. WPBakery makes all three harder to hit, and not by accident — it's structural:

Deep div nesting. The shortcode-to-HTML conversion produces heavily wrapped markup — rows inside columns inside inner-rows inside elements. More DOM nodes mean more layout work and more for the browser to paint, which pressures both LCP and INP.
Render-blocking CSS and jQuery. WPBakery leans on jQuery and loads its own grid and animation stylesheets, frequently on every page whether the page uses those elements or not. That's render-blocking weight on the critical path.
Bloat you can't see. Many bundled themes layer WPBakery plus a "core" companion plugin plus Slider Revolution, each adding its own scripts. The page weight is rarely from WPBakery alone — it's the whole inherited stack.

None of this makes a fast site impossible. With a quality host (TTFB ideally under ~200ms), aggressive caching, a CDN, and a plugin like Asset CleanUp or Perfmatters to dequeue WPBakery's assets on pages that don't need them, plenty of WPBakery sites pass Core Web Vitals. But you're spending optimization effort to claw back performance the architecture gave away — effort a leaner stack wouldn't demand in the first place.

The verdict: keep it, but don't start new builds on it

Here's the practical call, split by situation.

If you have a working WPBakery site

Keep it. The migration cost is the trap here. Because every layout lives as shortcodes, you can't "switch" builders — you'd have to rebuild every page by hand in the new tool, then strip out the orphaned shortcodes the old plugin leaves behind. For a brochure site of a dozen pages that's an annoying weekend; for a content site with hundreds of pages it's a genuine project with real risk of breaking URLs and layouts. If your site renders fine and passes Core Web Vitals, the rational move is to optimize what you have: trim unused assets, add caching, and leave the builder alone. Don't rip out working infrastructure for ideological tidiness.

If you're starting a new site in 2026

Don't choose WPBakery. There's no scenario where it's the best available option for a fresh build, and you'd be signing up for the same shortcode lock-in that makes existing sites painful to leave. The 2026 shortlist, depending on your priorities:

Gutenberg / Full Site Editing, ideally paired with GenerateBlocks or Kadence Blocks — native, lean, no plugin lock-in, and the direction WordPress itself is investing in.
Bricks — a developer-leaning visual builder with famously clean markup and strong performance, increasingly the default for agencies that left the old builders.
Breakdance — full-site visual building with a gentler learning curve than Bricks and similarly lightweight output.

If you're buying a ThemeForest theme

Check what builder it ships with before you buy. A theme that's hard-wired to WPBakery is selling you the lock-in along with the design. Increasingly, the better-maintained premium themes ship Gutenberg-native or builder-agnostic — favor those.

So: outdated or still useful? Both, honestly. WPBakery is genuinely outdated technology — a jQuery-and-shortcode relic from a different era of WordPress — and it's still perfectly useful on the millions of sites already running it well. The mistake isn't using WPBakery. The mistake is mistaking "it came with my theme" for "I should build my next site on it."

WPBakery Page Builder: Outdated or Still Useful?