Why We Build WordPress Themes Without Page Builders (or Build Tools)
Plain PHP and vanilla JavaScript are not old-fashioned — for most business sites they are the fastest, cheapest and most maintainable choice. An honest look at custom themes versus page builders, and when each makes sense.
pasindukw
· 7 min read
Every Trendlytik theme is written in plain PHP and vanilla JavaScript. No page builder, no Webpack, no node_modules folder. Clients sometimes ask whether that is a limitation — after all, page builders are hugely popular, and modern front-end tooling is powerful. For the sites we build, it is a deliberate advantage. This article explains why, and is honest about when a page builder is the better choice.
In this guide
What page builders actually do
A page builder — Elementor, Divi, WPBakery, Beaver Builder and others — lets you assemble pages visually by dragging sections, columns and widgets. It is genuinely useful: people who cannot write code can create complex layouts and change them whenever they like.
To make that possible, the builder has to support every layout any user might create. It ships the CSS and JavaScript for its widgets, animations, sliders and responsive controls, and wraps content in several layers of nested containers so each piece can be positioned independently. Modern builders have improved a lot at loading only what each page uses, but the underlying trade-off remains: flexibility costs code.
Where that cost shows up
Speed
Extra CSS and JavaScript take time to download and run, especially on mid-range phones over mobile data. Deeply nested markup makes pages heavier and slower to render. These costs show up directly in Core Web Vitals, particularly Interaction to Next Paint, which suffers when lots of JavaScript runs on the main thread.
Consistency
When every page is assembled by hand, small differences creep in — a heading size here, a button colour there. Over a few years, a site can drift a long way from its original design. A theme with fixed templates keeps every service page and every article consistent automatically.
Lock-in
Builder content is usually stored as builder-specific markup or data. Deactivate the plugin and pages can turn into a mess of shortcodes or unstyled blocks. Moving away later means rebuilding pages rather than switching themes.
Licences and updates
Pro features typically need a yearly licence. Builders also release frequent updates, each of which should be tested, because a builder touches every page on the site.
Why we skip build tools too
Modern front-end tooling — bundlers, transpilers, CSS frameworks with build steps — is excellent for large applications. For a business website, it introduces a second project to maintain: a dependency tree, a specific version of Node and a build command that must still work years from now. When the next developer opens the theme, they need to install and rebuild everything before changing a colour.
With plain files, they just edit and upload. Browsers now support the features we used to need tools for — CSS custom properties, modern layout with grid and flexbox, native modules — so the trade-off has shifted firmly in favour of simplicity for sites like these.
What we do instead
- One hand-written stylesheet built around CSS custom properties for colours, spacing and type, so a brand change is a few lines.
- One small deferred script with no dependencies, handling menus, carousels and similar interactions.
- Self-hosted, preloaded variable fonts — one file per family instead of a file per weight.
- Templates for each content type: services, projects, articles, products, packages. Each one outputs clean, semantic HTML with one H1 and logical headings.
- Structured data built into the templates, so every service page and article describes itself to search engines correctly.
- Cache busting with
filemtime(), so updates reach visitors immediately — see our note on cache busting.
How clients edit a custom theme
The most common worry is “will I be able to change anything myself?” The answer is yes — in a more structured way than a page builder:
- The Customizer holds homepage headlines, introductions, statistics, contact details and on/off switches for sections, with a live preview.
- Custom fields on services, projects, products and packages mean you fill in labelled boxes — price, timeline, what is included — and the template handles layout.
- The block editor handles articles and simple pages, styled to match the site.
What you cannot do is drag any element anywhere on any page. For most businesses that is a feature: the design stays coherent, and editing is faster because there are fewer decisions to make.
When a page builder is the right choice
We do not think page builders are wrong. They are the right tool when:
- A marketing team needs to create brand-new layouts every week — campaign landing pages, for example — without waiting for a developer.
- The budget does not allow custom development, and a well-chosen builder with a lightweight theme is the most affordable way to launch.
- The site is temporary, such as a short event microsite.
If you do use a builder, keep it lean: one builder, a lightweight base theme, a small number of add-ons, global styles instead of per-page tweaks, and regular speed checks.
Real-world results
When we rebuilt the homepage of NutrientsCalculator as a lean, ad-free theme and consolidated scattered sections, speed test scores improved substantially. The same approach runs through every project in our portfolio: fewer moving parts, faster pages and code the client fully owns.
What we look for when we inherit a builder site
Many of our projects start with a site someone else built on a page builder. Before recommending anything, we look at the same handful of signals:
- How many add-on plugins extend the builder. Three or four “addon packs” usually means a lot of unused widgets loading on every page.
- Global styles versus per-page styling. If every heading has been styled by hand, a brand change means editing every page.
- Page weight and requests on a typical service page, measured on a mid-range phone.
- Interaction delays — menus, accordions and tabs that feel sluggish point to heavy scripts.
- How content is stored. If the important text lives inside builder widgets, migration takes more care.
Sometimes the right answer is a careful clean-up: remove unused add-ons, switch to global styles, compress images and drop sliders. The site stays on the builder and becomes noticeably faster. When the builder itself is the bottleneck, a custom theme is the more durable fix.
Migrating away from a page builder
If you decide to move, treat it as a redesign rather than a plugin swap. The process we follow:
- Inventory every page and the content blocks it uses — services, testimonials, galleries, forms.
- Design templates around content types, not individual pages. Ten service pages become one service template with ten entries.
- Move content into structured fields or clean blocks, keeping the wording that already ranks.
- Keep every URL or redirect it, following the steps in our guide to redesigning without losing rankings.
- Deactivate the builder only after launch checks pass, and keep a backup in case any page was missed.
Done this way, the visitor sees a faster, more consistent site, and search engines see the same pages at the same addresses with the same content.
What it costs
A custom theme usually costs more upfront than installing a builder and a template, because the templates are designed and written for your site. Over time the picture changes: there is no builder licence to renew, fewer plugins to update, fewer layout bugs after updates and less time spent fighting the tool. For a site that will live for several years, the total cost is often similar or lower — and the site is faster throughout.
Accessibility is easier without a builder
Hand-written templates also make accessibility simpler. Headings follow a logical order because they are fixed in the template; buttons are real <button> elements; menus work with a keyboard; images get meaningful alternative text from their fields. Builders can produce accessible pages too, but it depends on every editor making the right choice on every page. With templates, the right choice is made once. Our accessibility guide for small businesses covers what to check.
Questions to ask your developer
- Will the site use a page builder? If so, which one, and why?
- How will I edit the homepage, services and articles?
- What happens if I stop paying for any licence?
- How will you keep pages fast as content grows?
- Could another developer pick up the code easily?
For more questions, see 15 questions to ask before hiring a WordPress developer.
Bottom line
Page builders trade speed and long-term simplicity for layout flexibility. For many business websites, the layouts are known in advance, and hand-built templates win on speed, consistency, cost over time and ownership. If you are weighing up the options, our custom WordPress theme service explains what is involved, and our packages show where to start.
Sources and further reading
- WordPress Theme Handbook — the official guide to how themes are built.
- web.dev: Interaction to Next Paint — why heavy JavaScript hurts responsiveness.
Questions about this topic.
Are page builders bad for SEO?
Not inherently. Search engines can read builder pages. The problems are indirect: extra code can slow pages down, and some layouts encourage thin text and heavy images. A carefully built builder site can perform well; it simply takes more discipline.
Can I still edit my site without a page builder?
Yes. A custom theme gives you editable homepage sections, structured fields for services or products and the standard WordPress block editor for articles. What you cannot do is drag any element anywhere, which is usually a benefit for brand consistency.
What if I want to switch away from a page builder later?
It is possible but takes work, because content is often stored in builder-specific markup. Plan a rebuild with content migration and redirects rather than simply deactivating the plugin.
