Why We Build Static HTML Sites Instead of Bloated Page Builders

By Brian Hunter · Founder, Hunter Creative Media & Design

We tell prospective clients this regularly and it catches them off guard: for most small business websites, we write HTML and CSS by hand. No WordPress. No Elementor. No Divi. No Squarespace. Just clean, hand-coded markup and stylesheets deployed as static files.

The typical reaction is some version of “why would you do that when drag-and-drop builders exist?” Page builders are popular because they promise anyone can build a website without writing code. And they deliver on that promise to a point. The problem is what they cost you in performance, reliability, and long-term maintainability once that initial convenience wears off. If you want the whole picture, we put together a practical guide to Core Web Vitals and page speed.

We are not page builder haters. There are situations where WordPress with a builder makes sense. But for the majority of small business sites we build (five to thirty pages, primarily informational, designed to generate leads), hand-coded HTML delivers a measurably better result.

What Page Builders Actually Do to Your Website

When you use Elementor, Divi, Beaver Builder, or Squarespace’s visual editor, you are layering a massive abstraction on top of the underlying web technologies. That abstraction has a real cost.

The Bloat Problem

A typical WordPress page using Elementor loads between 1.5 MB and 4 MB of data for a simple informational page. A hand-coded version of the same page typically loads between 100 KB and 400 KB. That is a 5x to 15x difference in file size.

Where does the bloat come from?

• CSS files loaded on every page. Elementor loads its entire CSS framework even if a page only uses a fraction of the components. A page with a hero section and a contact form still loads CSS for sliders, tabs, accordions, galleries, pricing tables, and dozens of unused widgets.
• JavaScript files loaded on every page. Page builders load their entire scripting library globally. Elementor alone can inject 300 KB or more of JavaScript before you add a single interactive element.
• Render-blocking resources. Many of these files are render-blocking, meaning the browser cannot display content until it downloads and processes them. This directly increases the time visitors stare at a blank screen.
• Inline styles and excessive DOM elements. Page builders generate inline styles on individual elements rather than using efficient shared CSS classes. A simple two-column layout that a developer would build with 5 to 10 HTML elements becomes 30 to 50 nested divs.

To make that concrete, here is everything a simple hero section needs in hand-coded HTML:

<section class="hero">
  <h1>Your Business Deserves Better</h1>
  <p>Web design and development for local businesses.</p>
  <a href="/contact/" class="btn">Get Started</a>
</section>

That is roughly 180 bytes of markup: clean, semantic, accessible. The same visual result in Elementor generates a nested structure of wrapper divs, data attributes, and inline styles that typically spans 2 to 4 KB: 10 to 20 times more markup for the same outcome. This is not because page builders are poorly made. It is because they must accommodate every possible layout combination, responsive behavior, and styling override, and that flexibility requires complexity a purpose-built page simply does not need.

The DOM Size Problem

Google recommends keeping your DOM under 1,500 elements. A typical Elementor page contains between 2,000 and 4,000 DOM elements. We have seen pages exceed 6,000. A hand-coded equivalent typically contains 200 to 600 elements.

Every DOM element the browser processes adds time to rendering and layout calculations. On mobile devices with less processing power, this difference is pronounced. A page with 4,000 DOM elements that loads adequately on a new iPhone will crawl on a budget Android phone, the same phone a significant portion of your local customer base uses.

The Plugin Dependency Chain

WordPress page builder sites depend on a chain of plugins: SEO, caching, forms, security, image optimization, CSS minification. Each adds scripts, styles, database queries, and server-side processing. The caching plugin that is supposed to make your site fast is actually compensating for problems created by the other plugins.

The JavaScript Rendering Problem

Some hosted builders, Wix in particular, rely on JavaScript to construct the page itself. The HTML delivered from the server is essentially a shell, and nothing is visible until the JavaScript downloads, parses, and executes. That architectural choice makes a fast Largest Contentful Paint nearly impossible. And because you do not control the server on hosted platforms like Squarespace and Wix, you cannot implement advanced caching or rendering optimizations to compensate. You are limited to whatever the platform provides.

What Hand-Coded Static HTML Delivers

A static HTML site is pre-built HTML, CSS, and JavaScript files served directly to the browser. No database. No server-side processing. No CMS generating pages on the fly.

Real Performance Comparisons

Here are numbers from sites we have built versus page builder equivalents with the same visual complexity.

Small service business (8 pages, hero sections, service cards, contact form):

These are not cherry-picked outliers. This is the typical gap. The static site is in a fundamentally different performance tier.

And it is not just Elementor. We ran the same benchmark (identical design, content, and images) across five different approaches. Same story everywhere:

Every builder exceeded Google’s 1,500-element DOM warning threshold on a single homepage. Wix loaded over 100 times more JavaScript than the hand-coded version and blocked the main thread for nearly a second and a half: visually loaded, but unresponsive to clicks and taps for that entire duration. The hand-coded version’s content was fully visible (LCP of 0.8 seconds) before the builder versions had even finished downloading their CSS and JavaScript (LCP of 2.9 to 4.1 seconds).

Worth noting: WordPress with a well-built custom theme and no page builder lands close to hand-coded territory. The builder is the problem, not WordPress itself.

Why it matters: Google uses Core Web Vitals as a ranking signal. 53% of mobile users abandon sites that take longer than 3 seconds to load. And every 100 milliseconds of improvement increases conversion rates by roughly 1%.

Security

A static HTML site has no database to hack, no admin login to brute force, no plugins with vulnerabilities. The attack surface is essentially zero. WordPress sites face over 90,000 attacks per minute globally.

Hosting Cost

Static files can be served from a CDN for $0 to $20 per month regardless of traffic. WordPress hosting that performs acceptably starts at $20 to $30 per month, before premium plugin costs ($50 to $200 per year for Elementor Pro alone).

Reliability

A static site cannot crash from a plugin conflict, run out of PHP memory, or display a white screen of death. Static files just sit there and get served. We have sites that have run for years without a single outage.

Can You Just Optimize a Page Builder Site?

To a point. Image compression and WebP formats help on any platform. On WordPress builders, caching plugins like WP Rocket or LiteSpeed Cache can cache pages, minify assets, and defer scripts, typically worth 10 to 20 PageSpeed points. Unused-CSS removal tools and a ruthless plugin diet help too.

But some popular fixes do not help as much as people hope. Minifying a 400 KB CSS file saves maybe 15 to 20 percent. You still have a 320 KB CSS file. Many “speed optimization” plugins add their own JavaScript to defer other JavaScript, a net-zero or even net-negative trade. And upgrading hosting improves Time to First Byte but does nothing about the megabyte of CSS and JavaScript the browser still has to download and process.

In our experience, aggressive optimization can push a builder site from a 40-50 mobile PageSpeed score to 65-75. That is a meaningful improvement, but it is still below the 90-plus range that custom-coded sites achieve by default. The builder’s fundamental architecture (its DOM structure, its global asset loading, its JavaScript dependency) sets a ceiling that optimization cannot break through.

The Arguments for Page Builders

“Clients can edit their own content”

This is the strongest argument. If a client publishes blog posts weekly or updates product listings regularly, a CMS is justified.

But here is the reality for most small business websites: the content rarely changes. The services page gets updated maybe once a year. The about page stays the same for years. “I can edit it myself” is a feature most clients think they need but rarely use. When they do need a change, they either break something in the builder or contact us anyway.

For our static site clients, we offer a simple arrangement: send us what needs to change and we update it. Most clients need changes once or twice a quarter. That time is a fraction of what we would spend troubleshooting broken builder layouts and failed plugin updates.

For clients who genuinely need frequent updates, we pair a static site generator with a lightweight CMS for just the blog section. The same idea scales up into a full hybrid architecture: a custom-coded front end for the public pages Google ranks and visitors experience, with a headless CMS behind it for content management. It costs more than a pure builder site but keeps builder bloat off the front end entirely, often the sweet spot when performance and content independence both matter.

“Page builders are faster to develop”

For cookie-cutter sites built from templates, this is true. But the output reflects the process: it looks like every other site built with the same builder. Our hand-coded sites take more development time upfront, but the code is clean and optimized from day one. No technical debt. No performance problems to solve post-launch. Dramatically lower long-term maintenance cost.

“WordPress has better SEO plugins”

Everything Yoast and Rank Math do (meta tags, Open Graph tags, schema markup, sitemaps, canonical URLs) can be implemented directly in static HTML with zero overhead. We write the meta tags directly. The result is identical from Google’s perspective, but adds zero performance cost.

“Squarespace and Wix are good enough”

They are better than WordPress builders in some ways: more secure, simpler to use. But they bring ongoing subscription costs ($16 to $49 per month), platform lock-in, mediocre performance, and generic templates. Over five years, a Squarespace site costs $960 to $2,940 in subscriptions alone for a website you do not own. A custom static site costs more upfront but nothing in ongoing fees.

When Page Builders Do Make Sense

• Content-heavy sites with frequent updates. Multiple blog posts per week or large product catalogs justify a CMS.
• E-commerce. WooCommerce provides mature payment, shipping, and inventory integrations that are expensive to replicate custom.
• Non-technical teams without developer access. If no developer is available for updates and the team must manage content independently.
• Rapid prototyping. When speed to launch matters more than long-term performance.
• Hard budget constraints. If the choice is between a $2,000 builder site and no website at all, the builder site wins every time. A functioning website that is somewhat slow beats no website.
• Temporary or campaign sites. A site that exists for three months to support a marketing campaign does not need hand-coded optimization. Get it up, run the campaign, take it down.

Even in these cases, WordPress with the native block editor produces dramatically cleaner output than Elementor or Divi.

When Custom Code Is Non-Negotiable

The inverse list matters just as much. If your competitors have fast sites and you are fighting for Map Pack position and organic rankings, the performance gap between a builder site and a custom site translates directly into a ranking disadvantage. Core Web Vitals are a confirmed ranking factor. If your site generates revenue directly, the math gets stark: every 100 milliseconds of delay costs roughly 1 percent of e-commerce conversions, so a store doing $100,000 a month with a 2-second load-time disadvantage could be leaving $20,000 a month on the table. High-traffic sites feel it too, because performance problems compound under load. A lean site does dramatically less work per request, so it handles traffic spikes with far less server strain. And complex functionality like booking systems, client portals, and multi-step conditional forms can technically be assembled inside a page builder, but the result is inefficient and brittle compared to a custom implementation.

Questions That Settle the Decision

• How competitive is your market? In tight local SEO markets, every performance advantage matters.
• What is your budget? Custom development typically costs 2-5x more than a builder site upfront, and dramatically less to run.
• Who manages content? If non-technical staff need frequent updates, the editing experience matters.
• Does your site generate revenue directly? E-commerce and lead generation sites justify the investment in performance.
• What are your competitors doing? If they are on page builders too, custom code is an opportunity to leapfrog them.
• What is your timeline? Custom sites take longer to build. If you must launch next week, a builder is the practical choice.

Our Build Process

Design: We design in Figma, creating detailed mockups for every page on desktop and mobile. You approve the design before code is written.

Development: We hand-code HTML, write custom CSS, add JavaScript only where interactivity requires it, and optimize every image.

Optimization: We audit against PageSpeed Insights, verify Core Web Vitals, test across browsers and devices, implement schema markup, and generate a sitemap.

Deployment: We deploy to a CDN, configure the domain, set up SSL, and verify production.

Ongoing support: Content updates and design tweaks are handled by our team on request. No plugin updates, security patches, or database backups to manage.

The result is a website that loads in under one second, scores 95 or above on PageSpeed on both mobile and desktop, is essentially un-hackable, and costs almost nothing to host.

Keep Reading

• How to Dominate ‘Near Me’ Searches in Your Market
• Custom CRM Features Every Service Business Actually Needs
• The Real Cost of a Slow Website: Bounce Rates, Revenue, and Rankings

This philosophy isn’t theoretical. Our Hot Dog Business Growth case study documents swapping a bloated page-builder site for hand-coded HTML.