Your designer wants to build the new site in a page builder so you can edit layouts yourself. A developer friend says builders are bloated and the block editor is all you need. Both are partly right, and the argument over page builder vs Gutenberg speed is easier to settle once you see what each one actually sends to a visitor’s browser.
Do not expect a winner here. A builder can be the right choice for a site even though it costs some speed, and the block editor can be the wrong choice for a team that will never get comfortable with it. What matters is making that trade-off knowingly.
What each one produces
Both tools are ways of writing a page. The difference is in what ends up stored in the database and sent to the browser.
The block editor
The block editor, which many people still call Gutenberg, saves each page as fairly plain HTML with small comments marking where each block starts and ends. A heading block becomes a heading element, a paragraph becomes a paragraph. Layout blocks such as Group, Columns and Row add a wrapper or two. In recent versions, particularly with block themes, WordPress can load the stylesheet for only the blocks a page uses, rather than one stylesheet for every block type.
A simple section with a heading, some text and a button might come out as a group wrapper, the heading, the paragraph, and the button inside its own small wrapper. A handful of elements.
A page builder
Builders such as Elementor, Divi, WPBakery, Beaver Builder and Bricks give you a visual canvas with fine control over spacing, positioning and responsive behaviour. To make that control possible, each element usually sits inside several wrappers that carry its settings. The same heading, text and button might come out as a section, an inner wrapper, a column, a column wrapper, then a widget wrapper and a widget container around each of the three items. Recent versions of most builders have reduced this, but the output is still usually deeper than block content.
Builders also load their own front-end framework: a base stylesheet, generated CSS for each page’s design settings, and scripts for interactive widgets. Some load per-widget files only where needed; others load a larger shared set everywhere.
| Block editor | Typical page builder | |
|---|---|---|
| HTML per section | Shallow, close to plain HTML | Deeper, with wrappers for each element |
| Front-end CSS | Core block styles plus the theme’s | Builder framework, page CSS, theme styles |
| Front-end scripts | Few for static content | Builder scripts, more for sliders, animations, popups |
| Design control without code | Good, improving, still more limited | Very fine-grained |
| Add-on ecosystem | Block plugins, varying weight | Large add-on packs, varying weight |
| Leaving later | Content stays readable | Rebuild needed, see below |
Is the block editor faster than a page builder?
For the same design, built carefully, the block editor version is usually lighter: less HTML, less CSS and fewer scripts. That matters most on mid-range phones, where a deep page structure takes longer to style and lay out, and on slower connections.
Three things complicate the simple answer.
How it was built matters as much as the tool. A tidy builder page with a few widgets can be lighter than a block page assembled from three different block plugins, each loading its own styles and scripts. Block plugins such as Kadence Blocks, Spectra, Stackable and GenerateBlocks vary in what they add, and stacking several cancels much of the advantage.
The theme counts. A heavy multipurpose theme under the block editor can outweigh a builder on a minimal theme. Our guide to picking a lightweight WordPress theme covers how to test that part separately.
Cached pages even out the server side. With a working page cache, both approaches serve a saved copy quickly. Builder weight shows up mostly in the browser, and in slower editing in the dashboard.
When a page builder is worth its weight
There are good reasons to choose a builder knowing it costs some speed:
- People who are not developers edit layouts often. A marketing person building a new landing page every month will move faster in a familiar builder.
- The design depends on control the block editor does not give you easily. Complex positioning, per-device adjustments, or theme-wide templates managed visually.
- The site already runs on a builder and works. A full rebuild costs time and money. Tuning the builder may get you most of the way. If you use Elementor, our post on getting a slow Elementor site back up to speed has the specific settings.
- Your designer or agency builds in it well. A builder used with discipline is better than a block site built by someone fighting the editor.
When the block editor is the better choice
- A new site where speed matters. Starting with blocks costs nothing extra and avoids a later migration.
- Content-led sites. Blogs, guides, service pages that are mostly text, images and a few calls to action.
- A long expected life. Block content stays readable whatever editor or theme you use in future.
- A small team with little editing of layouts. If layouts change once a year, fine-grained control is wasted weight.
The block editor has its own quirks. If you have hit some already, our notes on common block editor problems may save you time.
The cost of switching later
Moving from a builder to blocks is not a setting. It is a page-by-page rebuild, and it is worth understanding before you commit to either direction.
- What is left when you switch the builder off. Some builders store layouts as shortcodes; WPBakery and the long-established versions of Divi are well-known examples, and deactivating them leaves pages full of bracketed codes. Others store layout data separately and leave a basic, unstyled version of the content. Either way, the design is gone.
- Templates and global parts. Headers, footers and reusable sections built in the builder’s theme builder need rebuilding in the theme or in block templates.
- Forms, popups and widgets. Anything that came from the builder, including its add-on packs, needs a replacement.
- What carries over. URLs, titles, SEO settings stored by your SEO plugin, featured images and media all stay with the post. Keep the slugs the same and you avoid redirect work.
A sensible migration starts with the pages that get the most traffic and the most speed complaints, keeps the design the same so you are only testing one change, and leaves rarely visited pages until last. Test each rebuilt page on mobile before switching it live. A redesign that slows the site down is a common and avoidable outcome; why a new website can end up slower than the old one covers what to agree with a designer in advance.
A mixed setup
Some sites use a builder for a few landing pages and the block editor for blog posts and simple pages. That can work, with one catch: check whether the builder’s files are loaded on pages built with blocks. Look at the page source of a blog post and search for the builder’s folder name in /wp-content/plugins/. If its stylesheets and scripts appear there too, check the builder’s settings for an option that limits loading to its own pages.
Testing page builder vs Gutenberg speed on your own site
General advice only goes so far. If the decision matters, test it:
- On a staging copy, pick one important page.
- Rebuild it with blocks, matching the design as closely as you reasonably can.
- Test both versions on mobile, three runs each, and note page size, number of requests, and the main timings.
- Ask the person who edits the site to make a small change in each version and say which they would rather use every week.
Both answers matter. A faster page that nobody on the team can edit is a problem of a different kind. For how this decision fits with the other parts of WordPress speed, see the section guide on what makes plugins, themes and builders heavy, and for the wider picture of server, page weight and scripts, our website speed and performance guide.
Frequently asked questions
Can I use a page builder and still pass Core Web Vitals?
Yes, many builder sites do. It takes more care: restrained layouts, few add-on packs, limited fonts and animations, compressed images and a working cache. The builder makes good results harder to reach than with plain blocks, not impossible. Check your own pages in Search Console and PageSpeed Insights rather than assuming either way.
Are block plugins like Kadence Blocks or Spectra as light as core blocks?
They vary. Each adds its own styles and sometimes scripts, and some load more than the blocks on the page need. Many now load assets only where their blocks appear. Check the page source and a speed test with and without the plugin, and avoid stacking several block plugins that do similar things.
Will moving from a page builder to blocks hurt my SEO?
Not if the URLs, titles, headings and content stay the same and the pages still look right on mobile. SEO plugin settings are stored with each post, so they carry over. The risk comes from changing slugs, losing content during the rebuild or breaking internal links, so check each rebuilt page before it goes live.
How long does it take to rebuild a builder page in the block editor?
It depends on the design, and estimates without seeing the site are guesses. A text-heavy page with a simple layout is quick; a page with custom animations, tabs, sliders and forms takes much longer because each widget needs a replacement. Rebuild one representative page first and use it to judge the rest.
Still unsure whether to rebuild or tune what you have? Our speed optimisation service begins with an audit of the pages you already have, which shows how far the existing build can go before a rebuild is worth discussing.
Next in this series: How to Choose a Fast WordPress Theme
