The Parts of Page Speed You Can Actually Change on a Builder

Page speed on a hosted website builder is a shared budget you did not negotiate. The platform's own JavaScript, its stylesheet, its font loading strategy and its image pipeline are all spent before you have added a word, and none of them are yours to change. What is left is a smaller allocation than most advice assumes, and the honest way to work on performance here is to know exactly which parts of it you hold.

That framing matters because the alternative — treating builder performance as a thing you can optimise the way you would optimise a codebase — leads people either to despair or to a migration. Neither is warranted, and Google's own documentation is the reason why.

What Google actually says this is worth

Straight from the page experience documentation, because the quote does more work than any summary of it: "There is no single signal. Our core ranking systems look at a variety of signals that align with overall page experience." The same page states that Search "always seeks to show the most relevant content, even if the page experience is sub-par," and that beyond Core Web Vitals, other page experience aspects "don't directly help your website rank higher in search results."

Read that as a brake in both directions. Speed is not nothing — it is in the mix, and it is a real quality of a real page that real people wait for. And speed does not substitute for relevance. A fast page about the wrong thing stays the wrong thing.

Which means the productive framing for a builder site is not how do I rank better but how do I stop making the platform's baseline worse, because making it worse is the part you are fully capable of.

The levers that are genuinely yours

Images, and it is not close. On nearly every slow builder page this desk has looked at, the single largest cost is an image uploaded at whatever size the camera or stock library produced. Builders resize and serve modern formats on your behalf, and that pipeline is one of the real benefits of a hosted platform — but it is working from what you gave it, and a hero image at five times the width it will ever display is five times the decode cost for no visible gain. Resize before uploading. It is the highest-yield thing on this list by an order of magnitude.

Third-party embeds. A chat widget, a booking calendar, an analytics tag, a social feed, a review carousel, a cookie banner. Each one is somebody else's JavaScript executing on your page, loaded on every page whether or not the page needs it. Four of these turn a fast platform into a slow site, and the platform gets blamed. Audit what is installed and remove what nobody uses.

Video. Self-hosted or auto-playing video in a hero section is the second-largest cost after images and the easiest to avoid. A poster image that loads a video on click costs almost nothing until somebody wants it.

Page length and section count. Builder pages are assembled from sections and it is easy to keep adding them. Every section is markup, usually an image, often an animation. Long pages are not a sin, but a fourteen-section homepage is a performance decision whether or not it was taken as one.

Custom fonts you added yourself. The platform already loads at least one font family. Adding two more, each with several weights, is straightforwardly additive and rarely worth what it costs.

The levers that are not yours, and pretending otherwise wastes time

The platform's framework JavaScript. Its CSS delivery. Its server response time. Its CDN configuration and cache headers. Whether it defers its own scripts. Whether it inlines critical styles. On a hosted builder, none of these are settings, and no amount of configuration reaches them.

This is the real performance difference between platforms, and it is decided when you choose one rather than after. It is also why this site does not publish benchmark numbers for other people's sites: the measurement that would matter is a measurement of the platform's code under your specific content, and a number from somebody else's site tells you nothing reliable about yours.

Measure your own site, not somebody's average

If you want to know how a platform performs, the only defensible answer is to look at data about that platform rather than at a review's anecdote. Google publishes field data collected from real Chrome users, and there are public datasets built on it that break performance down by the technology a site is built with. That data is checkable, it is not anybody's opinion, and it is the appropriate thing to consult before choosing a platform on performance grounds.

For a site that already exists, the tools are Search Console's Core Web Vitals report, which uses field data from your actual visitors, and a lab test on an individual page to identify what is heavy. Use the field report to decide whether there is a problem and the lab test to find it. Doing it the other way round produces a lot of work aimed at a page nobody visits.

A realistic sequence

Start by cutting the largest image on the slowest page and re-measuring. This one change accounts for most of the available gain on most builder sites, and doing it first stops you attributing its effect to something else.

Then remove every third-party embed nobody can name a use for. Then reconsider any auto-playing media. Then look at the number of sections on your heaviest page.

At that point you have spent the whole of the budget that is actually yours, and whatever remains belongs to the platform. If what remains is genuinely unacceptable, that is a platform decision and it belongs in the same conversation as every other capability — which is what the seven-builder control audit is for.

The thing worth remembering

Nobody has ever recovered a site's traffic purely by making it faster. Plenty of sites have wasted a quarter trying. Speed is a hygiene factor: past a certain point, more of it stops helping, and below that point it is a genuine problem for the people waiting.

Get the images right, keep other people's scripts off the page, and spend the rest of the effort on whether the page answers the question it was written for. That ordering is not a rhetorical flourish — it follows directly from Google's own statement that the most relevant content is shown even where the page experience is sub-par.

What to ignore entirely

Two things absorb an enormous amount of attention on builder sites and deserve none of it.

The first is a performance score out of a hundred from a lab tool. That number is a simulation run on one machine on one connection, it moves several points between runs of the same page, and it is not what Google uses. Field data from real visitors is, and it is available free in Search Console. Chasing a lab score on a builder site means chasing a number you cannot move, because most of what the number measures belongs to the platform.

The second is minification, script deferral and critical-CSS advice written for hand-built sites. On a hosted builder those decisions were made by somebody else and there is no setting that reaches them. Reading that advice produces the feeling of having a problem you cannot solve, which is worse than not having read it.

What replaces both is narrower and duller: resize your images, remove the embeds nobody uses, and check the field data every few months to confirm nothing has regressed. That is the whole practical programme, and it takes an afternoon rather than a quarter.