This year we agreed to use a page builder on three different client projects, against our usual practice. One was Divi. One was WPBakery (formerly Visual Composer). One was a newer entrant whose name we will not advertise because it folded in August. Each project was a real paid build. Each one taught us the same lesson, three different ways.
The lesson is not that page builders are bad software. The lesson is that page builders solve a problem we should not be solving in 2018.
The pitch
Every page builder sells the same dream. The client edits the site themselves. The agency does not get nights-and-weekends emails asking to change a heading. The marketing team ships landing pages without a developer. Everyone is happy.
It does not work that way. We have watched three different marketing teams try, on three different builders, on three different projects. The first month the team is excited. The second month they are stuck on a layout choice. By month four they have created six pages that look almost-but-not-quite like the brand spec. By month six they have called us back to clean up.
The actual user
A page builder is not an editor’s tool. It is a developer’s tool with a softer interface. The mental model — rows, columns, modules, padding, breakpoints, conditional logic, responsive overrides — is the same mental model a developer holds when writing CSS. The interface just makes it clickable.
Asking a marketing manager to use it productively is asking them to learn front-end development through a GUI that is harder to use than the underlying CSS would have been. Most marketing managers, given the choice between learning the GUI and asking us to ship the change, will keep asking us.
The lock-in problem
Every page builder stores its content as proprietary shortcodes or JSON in post_content. Switch off the builder, or migrate to a different one, and the post content turns into a wall of raw markup nobody can read.
This is not the same problem as the ThemeForest theme lock-in we wrote about last year — it is worse. A theme lock-in only affects layout. A page builder lock-in affects every page of body content the team has ever produced.
We migrated a 140-page Divi site to native blocks earlier this summer. It took ninety-six hours of developer time. Half of that was a custom regex parser to extract the Divi shortcodes into something Gutenberg could ingest. The client had not anticipated that line on the invoice, and it stung.
The performance cost
The page builders we tested this year shipped between 180 and 320 kilobytes of CSS and JavaScript on every page load, before any content. That is more than the 200 kilobyte total budget we wrote about in April. It is unavoidable if the front end has to render arbitrary nested rows and columns and conditional visibility logic.
It also means that any page built with a builder ships those assets even on pages that use a tiny fraction of the builder’s features. A simple text-and-image landing page does not need a 320-kilobyte responsive grid framework. With the builder, it gets one.
The new alternative
Gutenberg has been in core since 5.0 went stable this December — which is two months from now as we write this, so we have been testing it on staging. The block editor is the answer to the page-builder question that does not have the same trade-offs.
Block content stores as semantic HTML with HTML comments delimiting block boundaries. Switch off the block editor or migrate the content somewhere else and the content is still readable. The block library ships in core, so no extra plugin chain. The block API is open enough that we can register custom blocks for the specific layouts a client needs without inheriting the kitchen sink.
The marketing team gets a meaningful editing experience that does not require them to learn front-end development. The agency gets a content store that survives platform changes. The content also moves cleanly to a headless front end if that is the future.
What we tell prospects now
The conversation we have with prospects who arrive asking for Divi or Elementor is the same conversation we used to have about ThemeForest themes. We do not refuse the work. We explain the trade-offs in writing, in the proposal, before anyone signs anything.
If they still want the builder, we build it. We are not in the business of refusing client preferences. But we charge for the migration cost up front, we set the performance budget so they know what they are buying, and we keep the email thread from the proposal as evidence when they call us in 2020 asking why their site is slow.
For everyone else — about ninety percent of prospects — we propose a block-based build with a tight custom block library and a content team trained on Gutenberg. It is the only option in 2018 that does not have a built-in expiry date.