Three page builders dominate the legacy WordPress install base: Elementor, Divi, and WPBakery. Between them they account for tens of millions of active installations — Elementor alone claims 5 million — and they’re the starting point for most non-developer clients and the overwhelming majority of ThemeForest-purchased themes. This comparison covers where each stands in 2026, what each actually costs in performance and dollars, and the one risk all three share that most comparison articles skip past entirely.
If you’re evaluating Bricks Builder alongside Elementor and Divi, the dedicated Elementor vs Divi vs Bricks comparison covers that head-to-head in detail. This article focuses specifically on the three builders most likely to already be running on a site you’ve inherited or are being asked to work with.
WPBakery in 2026: The Honest Verdict
WPBakery (sold on CodeCanyon, formerly bundled as “Visual Composer” with countless ThemeForest themes) is the page builder most likely to appear on a site you’ve inherited from another developer. Understanding what you’re dealing with matters before you touch anything.
The core issue with WPBakery isn’t its interface — it’s how it stores content. WPBakery encodes your entire page layout as shortcodes written directly into the post content field: [vc_row][vc_column width="1/2"][vc_column_text]Your content[/vc_column_text][/vc_column][/vc_row]. These shortcodes live in wp_posts.post_content. If you deactivate the WPBakery plugin, every page it built displays raw shortcode strings to your visitors instead of content. You cannot safely remove the plugin without first migrating all content — and there is no automatic migration path.
The second issue is development pace. WPBakery is maintained and updated, but new feature development has slowed significantly compared to Elementor and Divi. It has no meaningful block editor (Gutenberg) integration, which means it operates in “Classic Editor” mode on every post it controls. For new projects in 2026, WPBakery is not a recommendation — it’s a tool you manage on existing sites until a migration is justified.
Pricing: A regular CodeCanyon licence costs approximately $64 USD per site, which includes 6 months of support updates. Extended support renews annually. There is no subscription model — you buy a per-site licence.
When to keep it: If you’ve inherited a WPBakery site and a full rebuild isn’t in scope, keep it, update it, and don’t deactivate it. For any new project, pick something else.
Elementor in 2026: The Mainstream Choice
Elementor Pro is the most widely deployed premium page builder in the WordPress ecosystem, and for most client projects it’s still the sensible default — not because it’s technically perfect but because its ecosystem is the largest. More third-party addons, more template kits, more developer familiarity, more tutorials, and more community support than any other builder. That ecosystem depth is a real advantage when something breaks or when a client needs an extension that doesn’t exist natively.
The 2026 state of Elementor includes container-based layouts (replacing the older section/column structure in Elementor 3.x), improved asset loading (load only the CSS for widgets actually on a given page — enable via Elementor → Settings → Experiments → Improved Asset Loading), an AI assistant for copy generation, and a maturing WooCommerce Builder add-on. The performance gap between Elementor and custom-built Gutenberg templates has narrowed but has not closed — Elementor still adds baseline CSS overhead that custom blocks don’t.
Pricing: Elementor Pro Essential starts at $59/yr for a single site. Advanced (3 sites) runs $99/yr; Expert (unlimited sites) $199/yr. A free version of Elementor exists with meaningful limitations — no Theme Builder, no popup builder, no WooCommerce widgets, and a smaller widget library. Most professional projects require Pro.
Lock-in reality: Elementor stores layout data in post meta as a JSON blob (the _elementor_data field), not in the post content field itself. This means deactivating Elementor doesn’t leave a wall of shortcodes in your content — the text content is still recoverable. The layout is lost, but that’s a much less catastrophic situation than WPBakery’s shortcode lock-in. It still takes significant effort to migrate a large Elementor site to another system, but it’s manageable.
Divi in 2026: The Value Case
Divi’s primary selling point is its pricing model: Elegant Themes charges $89/yr for access to Divi on unlimited sites, or a one-time $249 lifetime payment. For agencies managing multiple client sites, this makes Divi significantly cheaper per-site than Elementor Pro — especially for smaller builds where the per-site cost of an Essential licence adds up.
Divi has been undergoing architectural changes to address longstanding performance criticisms. Its visual builder has improved, and Elegant Themes has invested in making Divi more competitive on Core Web Vitals. Divi 5 represents a significant backend rewrite aimed at improving performance and compatibility with modern WordPress.
Pricing: $89/yr for unlimited sites (Elegant Themes membership, which also includes Extra theme and other ET products), or $249 one-time lifetime access.
Lock-in reality: Divi has historically stored layouts as shortcodes in the post content field, similar to WPBakery — deactivating Divi on a site built with older versions produces the same shortcode-in-content problem. Divi 5’s architectural changes address some of this, but if you’re inheriting a Divi 4.x site, treat the lock-in risk the same way you would WPBakery: the plugin stays until a migration is planned and executed.
When Divi makes sense: Multi-site agency setups where you’re building similar sites and want a unified tool at a fixed cost. Clients who need A/B testing on landing pages (Divi Leads is built in). Projects where the Elegant Themes template library covers the design requirements. For a single site or a technically demanding custom build, the per-site value proposition of Divi matters less.
Head-to-Head: The Numbers That Matter
| Criteria | Elementor Pro | Divi | WPBakery |
|---|---|---|---|
| Pricing | $59/yr (1 site) to $199/yr (unlimited) | $89/yr or $249 lifetime (unlimited) | ~$64 one-time per site (CodeCanyon) |
| Content storage | Post meta (JSON) — recoverable text | Post content (shortcodes on 4.x) — lock-in risk | Post content (shortcodes) — severe lock-in |
| Performance overhead | Medium — improved with asset loading experiment | Medium — improving with v5 rewrite | High — heaviest per-element CSS/JS |
| WooCommerce support | Strong — dedicated WooCommerce Builder | Good — WooCommerce module set | Basic — limited WooCommerce integration |
| Third-party addons | Largest ecosystem (Essential Addons, Crocoblock, etc.) | Large (DiviBooster, Divi Extended, etc.) | Smaller and shrinking |
| Block editor integration | Partial (Elementor widgets in classic mode) | Partial | None — forces Classic Editor |
| New projects | Yes | Yes | No |
Performance: What Actually Happens to Your Page Speed
All three page builders load more CSS and JavaScript than a hand-built Gutenberg template. The gap is real and measurable, but the degree depends heavily on configuration. Unconfigured defaults are the worst-case scenario for all three.
For Elementor, the “Improved Asset Loading” experiment in Elementor → Settings → Experiments is the single most impactful performance setting. It switches Elementor from loading a monolithic CSS file for all widgets to loading only the CSS for widgets actually used on a given page. On a typical homepage using 8–12 widgets, this reduces the per-page Elementor CSS from ~300 KB to 40–80 KB. Enable it on any new Elementor install and test thoroughly — a small number of widget combinations have known compatibility issues with this setting on older builds.
For Divi, the static CSS file generation feature (Divi → Theme Options → Builder → Advanced → Static CSS) generates a static stylesheet per page instead of computing CSS dynamically on each page load. This substantially reduces TTFB on Divi sites. Enable it alongside a caching plugin.
WPBakery has no equivalent optimization path — its CSS/JS load is determined by the plugin architecture, not a settings toggle.
For any site where Core Web Vitals are a hard requirement — a WooCommerce store running paid ads, a landing page where LCP directly affects Quality Score, or a site under active speed audit — none of these page builders will match a custom Gutenberg block template. For context on what well-optimized WordPress performance looks like, see the WordPress performance guide targeting 100/100 Lighthouse. For a comparison of page builders against custom code on this specific axis, page builders vs custom WordPress code covers the trade-off honestly.
The Lock-In Risk Nobody Talks About Enough
The most underappreciated difference between these three page builders is not performance or pricing — it’s what happens to your content if you ever need to switch.
WPBakery and Divi 4.x store page layouts as shortcodes embedded directly in the WordPress post content field. A typical Divi or WPBakery page looks like this in the database:
[vc_row][vc_column width="1/2"][vc_column_text]
<h2>Your heading</h2>
<p>Your content paragraph.</p>
[/vc_column_text][/vc_column][/vc_row]Deactivate the plugin: every page that uses this structure displays those raw shortcode strings to visitors instead of content. There is no “graceful degradation.” A site with 50 WPBakery-built pages is not recoverable without the plugin running.
Elementor handles this differently. It stores layout data in a post meta field (_elementor_data) as a JSON structure. The WordPress post content field itself contains a rendered text excerpt. Deactivating Elementor loses the layout, but the text content survives in readable form. Migrating away from Elementor is still significant work, but it’s not an emergency.
When inheriting a WPBakery or Divi site, this distinction changes the conversation: the page builder is load-bearing infrastructure, not a removable tool. Budget any migration project accordingly — a WPBakery-to-Elementor migration on a 40-page site typically takes as long as a rebuild, because the shortcode content must be extracted and recomposed page by page.
WooCommerce: Which Builder to Pick
For WooCommerce stores, Elementor has the clearest advantage. Elementor’s WooCommerce Builder covers custom product pages, shop archives, cart, checkout, and account pages using the same visual editor. The archive widget handles product filtering and pagination. The depth of WooCommerce template coverage and the number of third-party WooCommerce-specific Elementor addons (like Crocoblock JetWooBuilder) make it the default choice for shops that need visual control over the WooCommerce template layer.
Divi’s WooCommerce modules cover the basics — product grid, add-to-cart button, product image — but the template-level control over checkout and account pages is limited. For a simple shop where the default WooCommerce templates handle checkout and account, Divi is fine. For stores needing a fully custom checkout flow or heavily branded product pages, Elementor’s WooCommerce Builder is the stronger tool.
WPBakery has minimal WooCommerce integration. For any new WooCommerce project, don’t start on WPBakery.
Decision Framework: Who Should Pick Which
Pick Elementor Pro if: you’re building a new site or store and want the largest ecosystem of addons and templates, you need WooCommerce template customisation, you’re the developer and want the widest range of client-facing support resources, or you’re building for a single client at $59/yr per site.
Pick Divi if: you’re an agency managing multiple sites and the unlimited-site pricing makes Divi significantly more cost-effective per project, your client needs built-in A/B testing via Divi Leads, or you’re comfortable with the Divi workflow and the template library covers your design requirements.
Keep WPBakery (but don’t start new projects on it) if: you’ve inherited a WPBakery site and rebuilding isn’t in scope. Update it, keep it active, and don’t touch the page builder layer unless you’re committing to a full migration. For guidance on what to look at when inheriting an existing site, the pre-build WordPress checklist covers the audit steps.
The Alternative Worth Considering
The conversation about page builders in 2026 is incomplete without acknowledging Gutenberg’s maturity. Full Site Editing, block patterns, and the Site Editor have closed the gap significantly. For sites where the person managing content is a developer — or where editorial needs don’t require drag-and-drop freedom — custom Gutenberg blocks with ACF fields produce better Lighthouse scores than any page builder and have no lock-in problem: blocks render as standard HTML regardless of what plugins are active.
For building custom blocks, the custom Gutenberg block guide covers the build process. For the full performance comparison between blocks and page builders, Elementor vs Gutenberg in 2026 examines both approaches on a like-for-like basis.
If performance is the deciding factor and you want a visual builder, Bricks Builder ($149 one-time) sits between the two extremes — it generates cleaner HTML than Elementor or Divi with per-element scoped CSS instead of a monolithic stylesheet, at the cost of a steeper learning curve. The Elementor vs Divi vs Bricks comparison covers this three-way in detail.
Conclusion
For new projects in 2026: Elementor Pro for client sites that need a builder and WooCommerce support; Divi for multi-site agency setups where unlimited-site pricing matters; Gutenberg blocks or Bricks for performance-critical builds. WPBakery for new projects: no.
For inherited sites: respect the lock-in reality before deactivating anything. A WPBakery migration is a rebuild, not a plugin swap. For custom field decisions that follow once you’ve picked a builder, the ACF Pro vs MetaBox vs Pods comparison covers the field plugin layer. For help auditing an existing site’s plugin stack and recommending a migration path, WordPress rescue and audit services cover that as a dedicated engagement.
