The received wisdom is that page builders make slow sites. It is close enough to true that it is not worth arguing with, and specific enough to be misleading.
A builder does not make a site slow. It makes it very easy to do four or five things that make a site slow, and it does not warn you about any of them. Knowing which four is most of the work.
The hero image is usually the whole score
On a page-builder site, Largest Contentful Paint is nearly always the top image or the first heading, and nearly always the image.
The pattern is predictable: a full-width background image exported at 2400 pixels, set as a container background, lazy-loaded because a plugin lazy-loads everything, and therefore not requested until the layout has already been calculated. That single sequence accounts for more failing scores than every script on the page combined.
The fix is unglamorous. Size the image to the container rather than the screen. Serve it as a modern format. Exclude the above-the-fold image from lazy loading, because lazy-loading the thing the visitor is waiting for is precisely backwards. Preload it if the layout allows.
Doing only that, and nothing else, moves most page-builder sites from failing to passing on the metric people actually notice.
Layout shift comes from three places
Cumulative Layout Shift is the metric that most annoys real users and gets the least attention, because it does not show up when you are testing on a fast connection with a warm cache.
It comes from images without dimensions, web fonts swapping after first paint, and anything injected above existing content — a cookie bar, a promo strip, an announcement bar that appears half a second late.
Images are the easy one: explicit width and height, or an aspect-ratio box, so the space is reserved before the file arrives. Fonts need a considered font-display and, ideally, self-hosting so there is no third-party round trip. The injected elements need to occupy their space from the first render rather than pushing the page down when they arrive.
Widget sprawl is a real cost
A typical builder install accumulates three or four addon packs, each loading its own CSS and JavaScript. Most of them load on every page whether or not the page uses a single widget from that pack.
Two habits keep it under control. First, audit which packs are genuinely used — not installed, used — and remove the rest, because an addon pack contributing one widget to one page is not a good trade. Second, use the builder’s own element manager to disable the widgets that will never be used, which trims what gets registered and loaded.
It is also worth being honest about what the site actually needs. A counter that animates on scroll, a particle background, an entrance animation on every section — each is a small cost, and together they are the difference between a site that feels immediate and one that feels like it is thinking.
Caching hides problems as well as solving them
- Page caching is the largest single win and should be on before any other optimisation is attempted.
- CSS and JS combination helps, and is the single most common cause of a site breaking after “we turned on optimisation.” Change one setting at a time and check the pages that use unusual widgets.
- Critical CSS genuinely improves perceived speed and genuinely breaks layouts on templates it has not generated for. Check every template type, not just the homepage.
- Test logged out. An administrator bypasses the cache, which means the site is always slower for you than for anyone else, and always faster in a report than in reality.
Measure the thing users experience
Lab scores are a diagnostic tool and a poor scoreboard. They tell you what to fix; they do not tell you whether anyone was affected.
Field data is the honest number, and on a small site it takes a while to accumulate, which is inconvenient but does not make it optional. The useful discipline is to fix what the lab test identifies, then wait and confirm the field data moved. Chasing the lab score past that point is optimisation for a robot.
What this is really about
A page builder is a maintainability trade. It buys the ability for somebody non-technical to change a page, and it charges for that in page weight and in the ease of making expensive mistakes.
That trade is usually worth it — a site nobody can update is a different and worse problem, which is the argument in builds that survive the handoff. But it is only worth it if somebody knows the four or five specific ways a builder gets slow, and checks them before launch rather than after the client sends a screenshot of a score.
