The real cost of a page builder, measured

Page builders are not a scam and the people who use them are not lazy. They solve a real problem — letting someone who does not write code lay out a page — and for a lot of sites that trade is correct. What is usually missing from the decision is the size of the bill, because it does not arrive until the site is live.

So here is a measured one. These are the numbers from our own previous site, built in Elementor, taken before we rebuilt it in 2026, next to what the rebuild targets:

Asset     Page-builder build            Rebuild target
CSS       1.00 MB across 33 files       ~25 KB, one file
JS        1.38 MB across 24 files       ~190 KB framework + ~20 KB ours
Fonts     1.49 MB (20 separate woff2)   ~55 KB (2 subset variable faces)
Images    7.07 MB                       ~400 KB above the fold (AVIF/WebP)

To render that static marketing page, the browser was also asked to execute jQuery, jquery-migrate, SmartMenus, a sticky-header script, a number animator, Swiper, particles.js, two separate Elementor webpack runtimes and the Facebook events pixel. None of that is unusual. It is close to the default.

Where each megabyte comes from

CSS: a stylesheet for every possibility

A builder cannot know which of its features a page will use, so it ships the ones it might need. In practice that means a base stylesheet, a stylesheet per widget family, a stylesheet per theme component, and a generated file of per-element overrides for the inline styling the editor produces.

Every one of those files in the <head> is render-blocking: the browser will not paint until it has fetched and parsed all of them. Thirty-three render-blocking files on a high-latency mobile connection is not a byte problem, it is a round-trip problem, and it lands squarely on LCP.

It also makes the cascade unpredictable. Builder output leans on high-specificity selectors and inline styles because it has to win against a theme it did not write, which is why small visual changes often need !important and why nobody wants to touch the stylesheet later.

JavaScript: the same job done four times

The 1.38 MB above is not one large application. It is a dozen independent libraries, several of which overlap: a slider library and a separate lightbox with its own gesture handling, an animation library plus a second one bundled inside a widget, a menu script that could be a <details> element.

The cost is not mainly transfer. It is parse, compile and execute on the main thread, which is where INP failures come from — Google's threshold is 200 milliseconds at the 75th percentile, and a main thread still working through a megabyte of library code when someone taps the menu will not meet it. Compressed transfer size flatters this badly: gzip shrinks the download, not the work.

Fonts: twenty files for one typeface

Twenty woff2 files for a single family means every weight and style loaded as a separate static face, unsubset, with the full character set. The modern equivalent is two variable faces, subset to the characters you actually use, which covers every weight in the design at a fraction of the size.

Unsubset fonts also tend to arrive late, and a late font with different metrics from the fallback reflows every line of text when it swaps. That is a CLS failure with a visible cause.

DOM weight: the cost nobody looks at

This is the structural one. To make arbitrary drag-and-drop layout possible, builders wrap content in nested containers — section, inner section, column, widget wrapper, widget container, then the element. A heading that should be one node becomes six.

Node count has a direct cost. Style recalculation and layout scale with the number of elements the engine has to consider, so every interaction that triggers a reflow — opening a menu, expanding an accordion, resizing — gets more expensive as the tree grows. Lighthouse flags excessive DOM size for exactly this reason. A deep tree also makes CSS matching slower and memory use higher, which hits the low-end devices hardest.

If you are staying — the five things that pay

1. Turn off the widgets you do not use. Most builders have an experiments or feature-management panel that stops the matching assets being enqueued. Free, and it is usually the biggest single cut available.
2. Fix the hero image properly. Explicit dimensions, modern format, correct sizes, eagerly loaded. Builders lazy-load everything by default, including the LCP element, which is the most common self-inflicted wound we see.
3. Move third parties out of the head. Tag managers, chat widgets, heatmap recorders and consent banners are reliably the top long-task sources. Load them on idle or on first interaction.
4. Self-host and subset the fonts. Two variable faces, font-display: swap, metric overrides on the fallback. This is an afternoon and it fixes a chunk of both LCP and CLS.
5. Rebuild the heaviest template by hand. You do not have to leave the platform to stop using the builder on your highest-traffic template. A hand-written template in the theme, with the builder assets dequeued for that route, is a surprisingly cheap intervention.

Together those routinely take a page from poor to acceptable. What they will not do is get you to a fast baseline, because the baseline is set by what the platform emits before your content exists.

Measure your own floor

One test settles the repair-or-replace argument. Create a page in the builder containing a single heading and nothing else. Publish it, load it uncached, and record three numbers: total CSS, total JavaScript, and DOM node count.

That is your floor. Every real page is that plus your content. If the floor is already most of your performance budget, no amount of tuning will get you under it, and you are choosing between living with the number and changing the platform. There is no third option, whatever the plugin marketplace suggests.

The honest version of the trade

A builder buys editing freedom for non-technical staff and costs you a performance ceiling, a stylesheet nobody can reason about, and a DOM that makes interaction slow on cheap phones. For a site that is edited constantly by people who will never see a code editor, that can still be the right call.

It is the wrong call when the site is a handful of templates filled with structured content, because that is precisely the case where a proper content model gives editors the same freedom without the weight. We go through that trade-off in WordPress versus Webflow, and the symptoms of having outgrown the choice in signs you have outgrown your website.