WordPress Custom Themes vs Page Builders: What 4 Years of Agency Work Taught Me

Roy De La Torre — Mon, 13 Jul 2026 01:40:46 +0000

I've spent the last four years building WordPress sites at an SEO-driven agency — some with page builders, most with custom themes. I've inherited Elementor sites gasping at 8-second load times, and I've watched clients pay developers to change a headline because their custom theme had no editing interface.

Both approaches get evangelized like religions. Both evangelists are wrong about half the time. Here's the honest breakdown I wish someone had given me in year one.

What we're actually comparing

Page builders (Elementor, Divi, Bricks, Beaver Builder) are drag-and-drop layers on top of WordPress. You assemble pages visually from pre-built widgets.

Custom theme development means writing your own theme: PHP templates, your own CSS and JavaScript, WordPress hooks, and (usually) native Gutenberg blocks or ACF fields for the editable parts.

There's a middle path too — a lean custom theme plus Gutenberg for content — and honestly, that's where I land for most client work now. More on that at the end.

Page builders: the real pros

Speed to launch. A competent freelancer can ship a decent 5-page business site in Elementor in two or three days. The same site as a custom theme is one to two weeks. For a client with a ₱30k budget and a launch deadline, this isn't a small thing — it's the whole thing.

The client can edit everything. No "email the developer to change a photo" bottleneck. For small businesses without a technical person, this genuinely matters more than a Lighthouse score they'll never look at.

Design without a designer. Template kits get a non-designer to "professional enough" fast. I've seen solo founders build things in Divi that would've cost them serious money otherwise.

Ecosystem. Popup builders, form integrations, theme kits — someone has already built whatever you need. Usually three someones.

Page builders: the real cons

Performance debt. This is the one I fight professionally. A typical Elementor page loads the builder's CSS and JS framework, the theme's assets, and every addon pack's assets — on every page, whether that page uses them or not. I've audited builder sites shipping 2MB+ of assets to render what is essentially text and four images. You can optimize builder sites (I've gotten Elementor builds under 2s), but you're swimming against the current the entire time.

DOM bloat. Builders nest wrappers inside wrappers inside wrappers. A simple two-column section can be 15+ nested divs. Google's Core Web Vitals notice. So does your mobile user on a mid-range phone — which, if your market is the Philippines like a lot of mine is, describes most of your traffic.

Lock-in. Turn off Elementor and your content becomes shortcode soup. Migrating a mature builder site to anything else is a rebuild, not a migration. Clients rarely understand this trade-off when they sign up for it.

Update roulette. Builder + addons + theme + WooCommerce all updating on their own schedules. When something breaks, you're debugging four vendors' code instead of your own.

Custom themes: the real pros

Performance is the default, not a project. You ship exactly the CSS and JS each template needs and nothing else. My custom builds routinely land 90+ mobile PageSpeed scores without heroics, because there's simply nothing to strip out. For e-commerce — where site speed measurably affects rankings and conversions — this is the strongest argument there is.

Total control. Client needs a product configurator, a custom checkout step, an unusual layout? You just build it. No fighting a builder's assumptions, no stacking three addons to approximate the thing.

Security surface. Fewer third-party components means fewer vulnerability announcements to lose sleep over. Every plugin and addon is someone else's code running with your site's privileges. I've cleaned up hacked WooCommerce sites; the entry point is almost never WordPress core — it's the ecosystem around it.

It's yours. Version-controlled, documented, no license renewals, no vendor deciding to go subscription-only next year.

Custom themes: the real cons

Cost and time. Real development takes real hours. If the budget is small, a custom theme is the wrong recommendation, and a developer who says otherwise is selling you their preference.

The editing problem. A custom theme without a proper editing experience is a trap: beautiful, fast, and the client needs you for every text change. This is a developer failure, not an inherent flaw — but it's a common one. If you build custom, budget time for Gutenberg blocks or ACF-driven sections so the client owns their content.

Bus factor. A poorly documented custom theme is a hostage situation when the original developer disappears. (Document your work. Please.)

My actual decision framework

After enough projects on both sides, here's what I tell clients:

Use a page builder when:

Budget is small and the timeline is short
The site is a straightforward brochure/marketing site
The client will edit layouts themselves, often
No developer will be on retainer after launch
Traffic expectations are modest and content is light

Go custom when:

Organic search is a primary acquisition channel (Core Web Vitals compound over hundreds of pages)
It's e-commerce with real traffic — every 100ms matters at checkout
You need functionality builders can't do cleanly
The site will live for 5+ years (builder lock-in gets more expensive with age)
Security requirements are elevated

The hybrid nobody markets: a lean custom theme with native Gutenberg blocks for content editing. Custom performance and control, client-friendly editing, no builder lock-in. It costs more than Elementor and less than fully bespoke, and for most serious small-business sites it's the right answer. It's the default I now reach for.

The one-question test

If you take one thing from this: "Who edits this site in year two, and what happens to the business if it's slow?"

If the answer is "the owner edits it weekly and speed is nice-to-have" — builder, no shame in it.

If the answer is "content is stable and organic traffic pays the bills" — custom, and treat the extra cost as the SEO investment it is.

The wrong answer is picking based on what the developer prefers rather than what the business needs. I say that as someone whose bias is obvious from this article — and who still recommends Elementor to clients when it's the honest fit.

Roy De La Torre is a WordPress/Shopify developer and SEO specialist based in Metro Manila, Philippines, with 4 years of agency experience building SEO-driven e-commerce sites. He specializes in custom theme development, site speed optimization, and WordPress security. See his work at roydetorre.com, or find him on GitHub.

DEV Community: Roy De La Torre