Every website is a set of instructions a browser has to carry out before a visitor sees anything. The question that decides how fast your site feels is simple: how many of those instructions are about your content, and how many are about the tool that made it.
On a hand-coded site, close to all of them are about your content. On a page builder, a large share are about the builder.
What does a page builder actually send to the browser?
A page builder is a program that lets you drag blocks around, then reconstructs those blocks in the visitor's browser. To do that it has to ship the reconstruction machinery with every page. In practice that means a general-purpose stylesheet written to cover every layout the tool can produce, a JavaScript runtime that reassembles the blocks, and a stack of plugin scripts for the forms, the sliders and the cookie banner.
None of that is your text or your photographs. It all downloads, parses and executes before your headline is painted. You can see it on your own site in 2 minutes: open PageSpeed Insights, run your homepage, and read the lines called "Reduce unused JavaScript" and "Reduce unused CSS". Those two numbers are the tax.
A page builder ships its layout engine to every visitor because it rebuilds the page in the browser. A hand-coded site ships the finished page, so the browser has nothing to reassemble. That is why the same design, built both ways, produces two very different Largest Contentful Paint times.
What does hand-coded mean, exactly?
Hand-coded means a person wrote the HTML, the CSS and the small amount of JavaScript the page needs, and nothing else is in the file. There is no builder runtime, because there is no builder. The markup you inspect in the browser is the markup someone typed.
It does not mean primitive, and it does not mean you cannot edit it. Our builds are hand-written and still ship with a CMS, so the text, the images and the pages are yours to change from a browser login. What a CMS gives you is a separate article. The hand-coding is about what the visitor downloads. The CMS is about what you control. They are separate questions, and most people are told they have to choose.
How much does the difference actually matter?
Google publishes three thresholds, together called Core Web Vitals, and they are the fairest scoreboard available because they are the same for everyone:
| Metric | Good | What it measures |
|---|---|---|
| Largest Contentful Paint | under 2.5 s | When the main thing on screen finishes drawing |
| Interaction to Next Paint | under 200 ms | How long the page takes to respond when tapped |
| Cumulative Layout Shift | under 0.1 | How much the page jumps around while loading |
Interaction to Next Paint replaced First Input Delay as a Core Web Vital in March 2024, and it is the one page builders find hardest, because it measures the main thread being busy. A browser executing a layout engine is a browser that cannot answer a tap.
Layout shift is the other honest tell. A builder that measures elements in JavaScript after the CSS has loaded will move things a moment after you start reading. Hand-written CSS sets the size before the first paint, so there is nothing to move.
Is speed the only reason?
No. Speed is the measurable one, so it gets the attention, but two others cost more over 3 years.
Maintenance surface. A typical page builder site runs a theme plus 15 to 25 plugins, each on its own release schedule, each able to break the others. Every update is a small gamble you have to take, because skipping updates is how sites get compromised. A hand-coded site has no plugin list, so there is nothing to reconcile on a Tuesday morning.
Portability. Content locked in a builder's proprietary block format is content that only that builder can render. When you want to move, you rebuild. A hand-coded site is HTML, CSS and JavaScript in a repository, which any developer on earth can open and continue. That is what we mean when we say the code is yours: not that you get a login, but that you get something another person can actually work on.
Ask any agency one question: if we stop paying you tomorrow, what do we still have? The answer separates a website from a rental.
When is a page builder the right answer?
When nobody is going to write code for you, ever. A page builder is genuinely better than no website, and better than a hand-coded site that goes stale because no one can touch it. If your plan is to build it yourself over a weekend and change it constantly, use a builder and do not feel bad about it.
The moment it stops being the right answer is when the site starts carrying real money. Once search traffic, bookings or sales depend on the page, the 1 to 2 seconds you give away to the builder's runtime, and the plugin stack you inherit, become a running cost rather than a convenience.
What should you ask before you sign?
- What exactly do I own at the end, and where does it live?
- Can I edit the text and images myself without calling you? Show me the login.
- What are the Core Web Vitals of the last 3 sites you shipped? Ask for the URLs and check them yourself.
- How many plugins or extensions will this site depend on?
- If I hire a different developer next year, what do I hand them?
Any builder who cannot answer those 5 questions in one email is answering a different question than the one you asked.
