What a page builder costs, measured on a real restaurant site
We rebuilt a client's WordPress site and measured both versions the same way. The old menu page sent 4.36 MB of HTML before a single photograph loaded, and 94% of that was CSS the page builder pasted into the page — the same rules copied out 115 times, once per dish. The rebuilt menu page sends 114 KB and its performance score went from 41 to 94 out of 100. Nobody chose the 4.36 MB. It was the default.
We have written this article once before, about our own old site, because the slowest site we had ever measured belonged to us. Fair enough, said a reader: you would say that.
So here is a second one, on somebody else’s site, with a difference that matters. You can check the second half yourself. The Paanwalla is an Indian street-food business in Naperville. Their site ran on WordPress with the Divi page builder. We rebuilt it, and the rebuilt version is the one live at that address today. Open it, run the measurements below, and see whether our numbers hold.
The half you cannot check is the old site, because it no longer exists. Every figure for it came out of the audit we ran before the rebuild, and the method for each is written down here so you can run the same thing on your own site and see where you land.
What we measured, and how
Three tools, nothing exotic.
curl, to fetch the raw HTML document and count what is inside it. This is what a browser receives first, before it fetches a single image.- Headless Chromium, on an iPhone user agent at a 390-pixel viewport, cold cache, waiting for the page to finish loading. This gives the real request count and the real bytes on the wire.
- Lighthouse, mobile preset, simulated slow connection.
Every number below is one of those three. Where a figure moves between runs, we give the range rather than the flattering end of it.
The home page
The old home page was a 441 KB HTML document. For scale, a normal HTML document is 15 to 50 KB. This one was ten times that before it had fetched a logo.
Three quarters of it was CSS, pasted directly into the page across twelve separate blocks, the largest of them 126 KB on its own. On top of that sat 17 more stylesheets and 42 scripts as separate files, plus calls out to Google Fonts, Google Tag Manager and Google Analytics before anything could render.
The rebuilt page is 35.6 KB, which is 8 KB compressed on the wire. It carries 595 bytes of inline CSS, two stylesheets and one script. It contacts nobody.
The menu page, where it stops being ordinary
This is the number that made us write the article. The menu page was a 4.36 MB HTML document. Not the page with its images and fonts and scripts — the text file itself, before any of that.
94% of it was CSS, in 129 separate inline blocks. The reason is worth understanding, because it is not a mistake anybody made. The page builder writes a style block for each element you place on a page. The menu has 115 dishes. Each dish is an element. So the same preset rules — the same fonts, the same spacing, the same colours — were written out 115 times, once per dish, into the page every visitor downloads.
Nobody chose that. Nobody could have chosen it: the setting does not exist. It is what the tool does, and it gets worse every time you add a dish.
The rebuilt menu page is 114 KB, of which 4.5 KB is inline CSS. The menu is rendered from a list of dishes against one stylesheet that the browser fetches once and then reuses on every other page of the site.
Why inline CSS is the worst place to put CSS
A stylesheet in its own file gets downloaded once and cached. Visit a second page and the browser already has it. Come back tomorrow and it still does.
CSS pasted into the HTML cannot be cached, because it is not a file. It is part of the page. Every page carries its own copy, every visit re-downloads it, and the browser cannot start rendering anything until it has read through all of it, because any of those rules might change how the first paragraph looks.
That is the mechanism behind a number Lighthouse reported on the old home page: an estimated 2,100 milliseconds of render-blocking resources. Two seconds of a visitor looking at nothing, caused by CSS that had already been downloaded on the previous page and thrown away.
The code nobody chose
We crawled the old site with Chromium’s coverage tool, which records which lines of CSS and JavaScript actually execute. It loaded 3.4 megabytes of CSS and JavaScript per visit and used roughly a fifth of it. The main stylesheet was 9% used. The per-page stylesheets ran between 10% and 15%.
The specifics are the part worth reading, because each one is the same shape: something switched on by default, for a feature the business does not have.
- 33 page-builder JavaScript libraries on every page — sliders, counters, an audio player, a contact form module. The site has no sliders, no counters, no audio and does not use that form.
- 300 KB of form JavaScript across 11 files, on every page. Two pages have a form.
- 157 KB of JavaScript whose only job was to re-skin the video player the browser already has.
- Four Google Fonts families in 49 weight and style variants, producing 261 font-face declarations and 39 font files, for a site whose text is entirely Latin. There were 58 font files in the folder. Fourteen were needed.
- A 2 MB PNG as the social sharing image, sent to every preview card on every platform.
None of that is negligence. Each item arrived switched on, and switching it off is either buried in a settings panel or not offered at all.
What a visitor on a phone actually downloaded
The document is only the beginning. Here is the whole page load, on a phone, cold cache.
| Home page | Page builder | Rebuilt |
|---|---|---|
| Requests | 106 | 38 |
| Bytes on the wire | 1.33 MB | 0.75 MB |
| Scripts | 42 requests, 272 KB | 2 requests, 2 KB |
| Stylesheets and what they pull in | 14 requests, 708 KB | 11 requests, 282 KB |
| Separate hosts contacted | 4 | 2 |
| Menu page | Page builder | Rebuilt |
|---|---|---|
| Requests | 83 | 34 |
| Bytes on the wire | 0.74 MB, plus 796 KB for the document itself | 0.33 MB in total |
The scripts row is the one to look at. Forty-two requests became two, and 272 KB became 2 KB, because the rebuilt site ships about four kilobytes of hand-written JavaScript for the things that genuinely need it: the menu drawer, the sticky header, the lightbox, the form.
Speed, and the caveat that makes it honest
The old site was not slow on every request, and we are not going to pretend otherwise. With a warm cache it answered in 0.14 to 0.22 seconds, which is genuinely quick.
Request the same page with a query string on the end, so the cache cannot serve it and WordPress has to build the page, and it took 2.97 seconds. That is the true cost of the page, and it is paid by the first visitor after any edit, by anyone arriving on a link with a tracking parameter, by logged-in users, and by most search engine crawlers.
The rebuilt site answers in 0.10 to 0.17 seconds, measured today. There is no warm and no cold, because there is no server building anything. The pages were built once, when the site was, and the network hands them over.
Lighthouse, the score people quote at you
Out of 100, and higher is better. The old home page scored 39. The rebuild roughly doubles that, and the menu page goes from 41 to 94.
This is worth pausing on, because it is the one number a business owner is usually shown, generally by somebody selling them something. So here is what it is: a weighted summary of six measurements, taken in a simulated browser on a simulated slow connection. It is not what your visitors experienced, and it moves a few points between runs on the same page, which is why the rebuilt home page is quoted as a range rather than a figure.
What it is good for is direction, and the direction here is not subtle. The measurements underneath it are the part that matters.
| Home, builder | Home, rebuilt | Menu, builder | Menu, rebuilt | |
|---|---|---|---|---|
| Largest Contentful Paint | 10.5 s | 4.1 – 5.2 s | 9.4 s | 2.5 s |
| Cumulative Layout Shift | 1.04 | 0 | 0.40 | 0 |
| Total byte weight | 2,678 KB | 812 – 947 KB | 1,681 KB | 405 KB |
| Elements on the page | 914 | 318 | 2,367 | 898 |
The layout shift figure is the one a visitor can feel without knowing the word. A score of 1.04 means the page visibly jumps as it loads, so the thing somebody was about to tap moves out from under their thumb. The usual cause on a builder site is a stylesheet arriving after the first paint and fonts arriving after that. On the menu page, fifteen images had no width or height set, so the browser could not reserve space for them until each one arrived.
What the rebuild is, and what it is not
Same pages, same sections, same words, same photographs, same videos, same behaviour. Built as components against hand-written CSS, self-hosted font subsets cut to the Latin characters actually used, images generated at the sizes they display in, and about four kilobytes of JavaScript. One hundred and twenty-three pages. It runs on a content delivery network with no origin server behind it.
Two things we should say plainly.
The rebuilt home page is still 0.75 MB in total, because it kept the original’s five hero photographs, four video poster frames and pattern backgrounds. It is lighter because of how the code is built, not because we took content away. If we had deleted half the photographs we could quote a prettier number, and it would mean nothing.
And this is one site. One site is an illustration, not evidence. We also measured 300 independent Chicago-area small business sites at random, which is the part of our work that is actually evidence. This article is the worked example that sits underneath it.
Run this on your own site in ten minutes
You need no tools beyond the browser you already have.
- Open your home page, then view source. Search the page for
<style. Count the hits. One or two is normal. Twelve is a page builder writing your CSS into the page. A hundred and twenty-nine is the menu page above. - Open the developer tools, go to the Network tab, tick “disable cache”, and reload. Sort by size. The first row is your HTML document. Under 50 KB is healthy. Over 200 KB, something is pasting things into it.
- Read the request count at the bottom of that panel. Forty is ordinary. A hundred means most of the page is things you did not ask for.
- Add
?x=1to the end of your home page address and load it. If it takes noticeably longer than the plain address, you have just measured what your site costs when the cache does not save you.
If those four checks look fine, your site is fine and you can stop reading articles like this one.
What we would have fixed first, without rebuilding
A rebuild is not the first answer, and it was not our first suggestion here either. In order of return for effort:
- Turn off the scripts for features you do not use. Most builders have a setting for loading assets only where they are needed. On this site that alone would have removed roughly half of the 42 scripts without changing a pixel.
- Set width and height on every image. This costs nothing and removes most of the layout shift, which is the part visitors actually feel.
- Cut the fonts. Four families in 49 variants is a decision nobody made. Two families in four variants covers almost every site.
- Replace the 2 MB sharing image with a 100 KB one.
What none of that fixes is the inline CSS, because the tool cannot be told to stop writing it. That was the one that needed the rebuild, and it is the reason the menu page was 4.36 MB. If your own count in step one comes back in the dozens, you are looking at the same wall.