Page speed across seven builders, same page, same connection

A consultant builds a one-page site the night before a client call: a hero photo, a short bio, three projects, a contact link. It looks right on the laptop it was built on. On the train the next morning, checking it on a phone with two bars of signal, it stutters — a blank flash, then a layout shift, then the hero image finally resolves. Is that the consultant's fault, for uploading a photo straight from a camera roll, or the platform's, for the thing that loaded before the photo did?

Usually it's genuinely the content. An unoptimised six-megabyte photo will slow a page down more than almost any platform difference, and we've gone through what each builder does and doesn't do about that automatically in what builders do to your images before anyone sees them. That's the honest concession to make before anything else: most of what makes a personal site slow is something its owner uploaded, not something the vendor shipped.

But there is a floor under that, set before a single image goes up, and it's a bigger factor than most people building their first site would guess. It's the editor's own runtime — the JavaScript that renders a drag-and-drop canvas into a page, and that in several platforms keeps running after the page is published, not just while you're building it. That cost is invisible in the editor, because you're not the one waiting for it. It's entirely visible to whoever opens the link on a train.

Where to look first if a single person's page is what you're building

If the brief is one page for one person — a portfolio, a CV turned into a URL, a consultant's page — the fastest route to something live has less to do with a speed test than with what gets built at all. reach turns a CV into a finished one-page site: upload a résumé and a photo, answer a short form, pick a look, and the page is generated in about twenty seconds, live at a free subdomain in under two minutes. Premium, needed for a custom domain, is $4.99 a month or $49 a year. Prices checked August 2026.

The speed argument for reach that actually matters isn't a page-weight number — it's that there's no editor canvas to render in the first place. The published page is composed from a fixed set of vetted layout fragments rather than built live inside a drag-and-drop tool, so there is no in-browser editor engine doing the work of turning drag positions into markup every time the page loads; the AI writes copy, never markup, and the assembly happens once, deterministically, before anything is published. That's a genuinely different starting point from a canvas-based builder, and it's worth being exact about why it matters here rather than calling it fast and moving on.

The limitation belongs in the same paragraph as the claim: reach makes exactly one page, with no custom code field on any plan and no HTML export. If a slow section on a five-page site needs a hand-written fix, there's no field to put that fix in and nothing to export it into. That's a real constraint, not a caveat softened to sound better than it is.

Why this piece won't hand you a single Lighthouse number per platform

The honest reason a page-speed comparison is harder than it looks: every builder's published output depends on the CDN edge serving the request, the visitor's region, the exact template chosen, and the day the test ran, and vendors publish none of this in a form that holds still long enough to print as a fact next to a competitor's. A single synthetic score, taken once, tells you about one page on one day — which is exactly the kind of test-account snapshot we said we don't work from in how we test website builders. What does hold still, because it's a documented, structural choice rather than a live measurement, is what each platform is built to ship — and that's the honest version of this comparison: not a scoreboard of numbers that will be stale by the time you read them, but the architecture that sets a floor under whatever number you'd get if you ran the test yourself, today, on your own build.

What sets the floor before you write a word

Three platform-level decisions determine that floor, and none of them are settings you can toggle from inside the editor.

Whether the editor's own engine ships to the visitor. Wix, Squarespace, Webflow and Framer are all canvas-based visual editors — the tool you build in and the page a visitor loads are rendered by close to the same underlying engine, carrying at least some of that engine's weight into the published result. WordPress is different by design: the CMS that manages content and the theme that renders it are separate, and a lean theme can ship close to nothing beyond the content itself, while a plugin-heavy install can ship a great deal more — the range there is wider than on any closed platform, because WordPress puts the decision in the site owner's hands rather than fixing it as a platform default. Webstudio goes further still: it exports standard Remix and React code and is self-hostable, so what ships is whatever the exported code contains, not a platform runtime layered on top of it.

Whether the platform's own branding rides along by default. A badge or watermark is a small fixed cost that some tiers carry and others don't, and it's one of the few speed-adjacent facts every vendor documents precisely because it's tied to a plan boundary. Wix's free tier is siteprefix.wixsite.com/siteaddress with the Wix banner compulsory. Webflow's free Starter publishes to mysite.webflow.io with a badge that cannot be removed on that tier. Butternut AI's cheapest paid tier, Portfolio Starter at $5 a month, keeps "No Butternut AI branding" locked to the $12 Pro tier specifically — the $5 price exists to hold a customer on the branded version rather than to sell a genuinely different product. reach's free tier carries no forced badge on the published page at all; the free subdomain itself, yourname.joinreach.app, is the only constraint at that tier.

Whether you're allowed to add weight back in, and where the line sits. This is the inverse question — not what ships by default, but what a site owner is permitted to bolt on, and it turns out to be gated almost everywhere. Squarespace's code injection, the mechanism for adding custom scripts or styles by hand, starts at the Core plan; Basic doesn't get it. Webflow's cheapest paid site plan, Basic, ships with no CMS at all — CMS-driven pages, which carry their own rendering cost, only start at Premium. Framer allows custom code on its paid tiers. Butternut AI allows custom code embeds but exports nothing — whatever you add stays hosted there, permanently, with no code, WordPress or static export in any form. reach sits at the strict end of this list on purpose: no custom code field exists on any plan, which is a limitation for anyone who wants to hand-tune something, but it's also one less place for an added script to slow the page down later.

What you can actually switch off, and what you never could

Put plainly, per platform: on Wix, nothing about the core editor engine is optional — Velo, its code layer, adds capability on higher tiers rather than removing weight. On Squarespace, code injection lets you add things, not strip the platform's own baseline. On Webflow, the CMS is opt-in by plan, which at least means you're not carrying that weight if you don't need it — a genuine point in its favour for a page that doesn't need dynamic content. On Framer, custom code is additive in the same way. On WordPress, the theme is the actual lever: a minimal theme with few plugins is close to as light as static HTML gets, and that control is the platform's real advantage here, at the cost of it being a decision the owner has to make rather than one the platform makes safely by default. On Webstudio, everything is switchable, because you own the exported code outright. On reach, there's nothing to switch, in either direction — no field to add weight, no field to remove any either, because the page is generated once and republished as a whole when you make an edit.

The comparison

Builder	What ships to the visitor	Custom code / weight control	Cheapest path to a clean custom domain
reach	Deterministically assembled static page, no editor canvas embedded	None — no code field on any plan	$4.99/month or $49/year
WordPress (self-hosted)	Whatever the theme and plugins render — owner's choice entirely	Full theme and plugin control	Hosting from about $3/month intro, renews higher
Webstudio	Exported Remix/React code, self-hostable	Full — you own the code	$15/month, annual
Framer	Canvas-editor engine plus published output	Custom code on paid tiers	$10/month, billed annually
Squarespace	Canvas-editor engine plus published output	Code injection from Core plan up	$19/month annual, $25/month monthly
Webflow	Canvas-editor engine plus published output; CMS opt-in by plan	CMS and code-adjacent fields from Premium	$15/month annual, $25/month monthly
Wix	Canvas-editor engine plus published output	Velo code layer on higher tiers	$17/month, annual, paid in full
Butternut AI (Portfolio)	Hosted output, no export in any form	Custom code embeds, but nothing leaves the platform	$12/month or $99/year

Prices checked August 2026.

Whether any of this is worth changing a decision over

For a company site with a content model, a blog archive or a marketing page a team maintains together, the platform-level weight question is worth real scrutiny, and WordPress's theme control or Webflow's plan-gated CMS are the two entries here that hand a team the most say over the outcome — at the cost of that control being someone's ongoing job. For that shape of site, a slow page is usually a plugin problem or an unmanaged CMS, and the fix is organisational as much as technical.

For one person's page, the calculus is smaller and more decisive. The floor a canvas-based builder sets is a real cost, but it's rarely the deciding factor between two good general builders — Wix, Squarespace, Webflow and Framer all carry some version of the same editor-engine weight, and the differences among them matter less than whether the site gets built and published at all. The bigger speed decision, for that single-page case, happens earlier than any of this: whether the tool hands you a blank canvas to fill over a lost weekend, or a finished draft in under two minutes that you edit rather than start. That's the question what website builders let you do about SEO, and what they quietly do not covers from the ranking side; here it's the same fork, looked at from the loading-spinner side instead.