Why We Stopped Using Page Builders (And What We Use Instead)

Page builders — Elementor, Divi, Webflow to some extent, GHL's built-in editor — made sense when we were building sites fast for clients who wanted to self-manage their content. They're visual, they're quick, and they feel powerful until you need the site to do something specific.

Then you hit the wall. The site slows down because the builder loads a megabyte of JavaScript for every page. You want a component to behave a certain way and you spend three hours fighting the drag-and-drop interface. You try to integrate with a specific tool and the builder's ecosystem doesn't support it cleanly. You spend more time working around the platform than building what you actually need.

We moved away from page builders about 18 months ago. Here's what we learned.

The Real Cost of Page Builder Speed

Page builders are fast to start and slow at everything else. The first page takes an hour. But iteration is slow — you're clicking through menus instead of editing code. Performance is slow — a Divi or Elementor page typically loads 800KB–1.5MB of CSS and JS before your actual content. And maintenance is slow — a plugin update breaks a layout, and you're hunting through nested rows and columns trying to figure out what changed.

For a business whose website is a lead generation tool, page load speed directly affects conversion rate. A page that loads in 1.2 seconds converts meaningfully better than one that loads in 3.8 seconds. Page builders make it structurally difficult to hit that 1.2s target.

What We Use Now

For most client projects today, we build in plain HTML, CSS, and JavaScript. No framework overhead, no builder dependency, no plugin ecosystem to maintain. A typical page we build loads in under 1 second and scores 95+ on Google PageSpeed.

For clients who need to self-manage content — blog posts, team pages, product listings — we use a lightweight headless CMS that outputs clean HTML. The client gets an editor. The site stays fast.

For more complex web applications, we use React or Next.js where the added framework overhead is justified by the functionality it enables. But for marketing sites and landing pages, it's almost never justified.

When Page Builders Still Make Sense

We're not ideologues about this. Page builders are the right choice when:

• The client needs to make frequent, significant layout changes without a developer
• The site is a prototype or MVP that needs to launch in days, not weeks
• The existing ecosystem (WordPress plugins, integrations) is already built around a specific platform and switching costs are high
• Performance isn't a primary concern (internal tools, password-protected portals)

In these cases, a page builder might be the pragmatic choice. The mistake is using a page builder by default when the project actually justifies a custom build.

The Conversation We Now Have With Clients

Before we build anything, we ask: who maintains this after we're done, and what are they capable of? If the answer is "nobody" or "our marketing team needs to update blog posts," we design accordingly — usually a static site with a simple CMS for content. If the answer is "the developer team manages it," we build for performance and flexibility.

The tool should match the use case. Page builders matched a use case that was common five years ago and less common now. Build for how the site actually gets used, not for how fast you can deliver the first draft.