Autopsy #2: the page builder weighed more than the entire site

Back to the operating room. If in the first autopsy the villain was the plugin graveyard, today the suspect is a single one, but a fat one: the page builder. The same one that was sold to the client "so you can edit it yourself". Spoiler: they didn't edit anything, and it cost them half of their site's speed.

The patient: a clinic's website, eight pages, no blog, built with one of the most popular visual builders for WordPress. Pretty on the outside. On the inside, a different story.

Data sheet · before / after

• Builder CSS + JS per page · WordPress (before): ~900 KB · Next.js (after): 0 KB
• DOM nodes on the home page · WordPress (before): 3,100 · Next.js (after): 640
• Time to interactive (mobile) · WordPress (before): 5.1 s · Next.js (after): 0.7 s
• Lighthouse (mobile) · WordPress (before): 36 · Next.js (after): 98
• Was the client editing? · WordPress (before): No, not for 2 years · Next.js (after): —

A builder is not "a plugin"

Here's the key almost nobody explains. A normal plugin adds one feature. A page builder adds a whole layer between you and your site: its own column system, its own CSS, its own JavaScript, its own "widgets". And it loads it on every page, whether you use it or not. To render three columns with a text and a button, this site was downloading 900 KB of builder code. Almost a megabyte for something that is four lines of HTML.

It's not the client's fault. They were sold autonomy —"edit it yourself"— and in practice they didn't touch the site in two years, because editing in a builder is more scary than useful. They paid the builder's weight forever in exchange for a promise they never used. It's the most common pattern we see.

How we spotted it

No magic required: the builder leaves fingerprints everywhere. In the HTML, classes with its prefix on every node; on the network, a handful of CSS and JS files bearing its name loading on every page; in the DOM, a nesting of div inside div inside div to build a grid the browser does natively in three lines. When you see 3,100 nodes on a home page with eight blocks, the diagnosis is clear before opening anything.

The operation

We rebuilt the eight pages in Next.js with the same design —pixel by pixel where it mattered— but with clean HTML and our own CSS, no builder. The result: the site weighs a fraction, the DOM fits on one screen and mobile stops sweating. And the design isn't just preserved: with the noise gone, it loads sooner and looks sharper.

From 36 to 98 in Lighthouse. But, as always, the interesting part isn't the number: it's that 62% of the slowness lived in a tool the client didn't even use.

What if they want to keep editing?

Good question, and an honest one: if you really need to edit often, we don't leave you stranded. We connect a modern (headless) content editor for the parts that change, without dragging the builder's weight onto the public site. But for an eight-page site that gets touched twice a year, the honest thing is to say it: you don't need a builder, you need a fast site.

Is your site slow and you suspect the builder? In the free audit we tell you how much yours weighs and what you'd gain by removing it. And if you want the full picture, start with the migration guide.