Gutenberg and Blocks
Elementor, Divi or Gutenberg? Choosing a Builder for Client Sites
The builder you pick on day one decides what the next three years cost. Elementor, Divi and Gutenberg compared on the criteria that actually affect an agency's margin.
The builder you pick on day one of a project decides what the next three years cost. It sets your build speed, the licence bill, how much your client can safely change on their own, and whether the site is still maintainable when the original developer has left. Yet the choice is usually made by habit rather than by fit. The best page builder for client sites is not a single product — it depends on who edits the site, how bespoke the design is, and how long you intend to support it.
This post compares Elementor, Divi and Gutenberg on the criteria that actually affect an agency’s margin, then gives a decision rule you can apply during scoping instead of arguing about it internally.
The criteria that matter
Feature comparisons are mostly noise. All three can build the layout your designer drew. What separates them commercially is a shorter list:
- Time to first draft. How fast one developer gets from Figma to a reviewable page.
- Editing safety. How much damage a non-technical client can do before they call you.
- Front-end weight. What the builder adds to page size and render path before you have written a line of your own CSS.
- Lock-in. What the content looks like if the builder is removed or the licence lapses.
- Ongoing cost. Licences, add-ons, and the maintenance load of an extra major dependency.
- Hireability. How easily you can find someone to take over the codebase in two years.
Elementor, Divi and Gutenberg side by side
| Criterion | Elementor | Divi | Gutenberg |
|---|---|---|---|
| Time to first draft | Fast; huge template and widget ecosystem | Fast; strong visual editing, generous global settings | Slower initially, fast once a block library exists |
| Editing safety | Moderate; needs role and lock configuration | Moderate; similar caveats | Strongest, with locked patterns and block templates |
| Front-end weight | Heavier baseline; improved but still meaningful | Heavier baseline | Lightest baseline; close to whatever your theme ships |
| Lock-in | High; content stored in builder-specific markup | High; shortcode-based legacy content is worst case | Low; block markup is HTML with comment delimiters |
| Ongoing cost | Annual licence per site or bundle, plus add-ons | Single lifetime or annual licence, unlimited sites | None |
| Hireability | Very large talent pool | Large pool | Growing; block development is a real skill |
None of those rows makes a product bad. They describe different bets. Elementor and Divi buy speed now and pay for it in weight and lock-in later. Gutenberg costs more up front and pays back over the life of the site.
Where Elementor wins
Elementor is the pragmatic pick for marketing sites that need to move quickly and be edited constantly by a marketing team. Campaign landing pages, event microsites, sites where the client wants to spin up a new page on Thursday afternoon without a ticket. The widget ecosystem means edge-case requirements — a pricing toggle, a filterable portfolio, a comparison slider — usually already exist rather than needing to be built.
The costs are real. The DOM is heavier than hand-built markup, so Core Web Vitals need active attention rather than assumption. Licences renew annually and multiply across a portfolio. And a client who leaves Elementor is looking at a rebuild, not a migration — which is a genuine conversation to have honestly at proposal stage rather than discovering it three years in.
Used well, it is excellent. Agencies that get value from it standardise: one global style system, a locked set of approved widgets, and a template library reused across clients. Ad-hoc Elementor, where every developer builds differently, is where the maintenance costs come from. If you are building conversion pages at volume, disciplined page builder development with a shared component set is the difference between a fast studio and a slow one.
Where Divi wins
Divi’s commercial model is its strongest argument. One licence covers unlimited sites, which changes the arithmetic entirely for an agency running thirty or forty client sites. If you maintain a large portfolio and every site needs the same builder, that is a material line-item saving every year.
It also suits agencies with a strong design team and a lighter development bench. The visual editing model is direct, global presets are genuinely good, and non-developers can produce polished work inside it. The trade-off is the same shape as Elementor’s: extra front-end weight, and content that is deeply tied to the builder. Legacy Divi sites built on shortcodes are the hardest thing in this comparison to unpick — worth checking before you inherit one.
Where Gutenberg wins
Gutenberg is the right answer more often than agency habit suggests, and the gap has closed faster than most teams have noticed. Block themes, theme.json, block patterns, block bindings and synced patterns cover the large majority of what a client site needs, with no licence, no third-party dependency, and no rendering layer between WordPress and the browser.
The compelling argument is control. You can define exactly which blocks are available, lock a pattern so the client can change the copy and the image but not the structure, and set the entire design system in theme.json so brand colours and spacing cannot drift. That is a much better client experience than “here is a canvas, please do not break it” — and it is why we cover building reusable blocks clients cannot break as its own topic.
The honest downside is the first project. Building a custom block library takes real development time, and if you only ever build one site a year with it you will not recover that investment. It pays back from the second or third project, when the library becomes a starting point. Custom blocks are also where the field is still moving — the choice between ACF-based blocks and native block bindings for client builds is worth deciding deliberately rather than by default.
A decision rule for picking the best page builder for client sites
Run these five questions during scoping, in order. Stop at the first clear answer.
- Does the client already have a builder across their portfolio? Consistency usually beats optimisation. Match it unless there is a specific reason not to.
- Will the client’s own team publish new pages weekly? If yes, a visual builder with a locked template library is worth the weight. If they publish twice a year, it is not.
- Is performance a stated requirement or a contractual one? Sites with strict Core Web Vitals targets or heavy paid traffic lean towards Gutenberg with a lean custom theme.
- How bespoke is the design? Highly custom layouts and interaction end up fighting a visual builder. At that point you are writing custom CSS inside someone else’s abstraction, which is the worst of both worlds.
- Who maintains this in three years? If the answer is “we do not know”, weight lock-in heavily and choose the option that leaves portable content behind.
One pattern that works well in practice: Gutenberg for the site structure and templates, a visual builder confined to campaign landing pages that marketing owns. You get a fast, portable core site and give the client a safe sandbox where speed matters more than purity.
Standardising the decision across your agency
Whichever way you go, the cost sits in inconsistency. Three developers using the same builder three different ways produces a portfolio nobody can support. Write down your default stack, your approved add-ons, your naming conventions and your handoff standard, then make deviation a decision someone has to justify.
This is also the point where outsourced capacity becomes easy or painful. A partner can build cleanly inside any of these three, but only if your conventions exist in writing. Agencies that work with a white label WordPress development partner successfully almost always have a documented stack; the ones that struggle send a Figma file and hope. If your builds mix a bespoke theme with builder-driven pages, being explicit about where the boundary sits between custom theme development and builder templates removes most of the ambiguity from a brief.
Frequently asked questions
Is Gutenberg ready to replace Elementor and Divi for client work?
For most business and marketing sites, yes — provided you invest in a block library and templates. It is less ready when a client needs to assemble complex one-off layouts themselves with no developer involved, which is still where visual builders lead.
Can you migrate an Elementor or Divi site to Gutenberg?
Content can be moved, but layouts effectively have to be rebuilt. Treat it as a redesign with content reuse, and price it that way. Automated converters handle simple text and image sections and leave the complex sections needing manual work anyway.
Do page builders hurt Core Web Vitals?
They add weight, but they do not make good scores impossible. Most failing builder sites fail because of unoptimised images, too many third-party scripts and no caching — problems that exist independently of the builder. A disciplined build with a good host passes comfortably.
Which builder is cheapest across a large portfolio?
Gutenberg, because there is no licence at all, then Divi’s unlimited-site model, then per-site Elementor licences with add-ons. Licence cost is rarely the deciding factor on a single project, but at forty sites it becomes a genuine annual budget line.
Should we let clients edit templates directly?
Generally no. Give clients content editing and lock structure, whichever builder you use. Combining locked patterns with restricted user roles prevents the great majority of support tickets that begin with “the page looks strange now”.
If you are weighing up a stack change or need extra hands to build the block library that makes Gutenberg viable for your team, have a look at the monthly development plans — that kind of foundational work fits neatly into a fixed hour block.
// related