Run a Wix or Squarespace site through Google PageSpeed Insights and the mobile score tends to land somewhere between 40 and 65. Run a hand-coded site built carefully from scratch and the same test returns 90 to 100. The gap is not a coincidence, and it is not something you can fix from inside the builder's settings panel. It is structural.
Understanding why requires knowing what PageSpeed actually measures, and what website builders are doing behind the scenes that custom code is not.
What Google PageSpeed is actually testing
Google PageSpeed Insights measures your site against a set of performance metrics called Core Web Vitals. The three that carry the most weight for rankings are:
- Largest Contentful Paint (LCP) — how long it takes for the main visible content to load. Google's threshold for "good" is under 2.5 seconds.
- Cumulative Layout Shift (CLS) — how much the page visually jumps around as it loads. Unexpected shifts frustrate users and hurt scores.
- Interaction to Next Paint (INP) — how quickly the page responds when a user clicks or taps something.
Google has used Core Web Vitals as a ranking factor since May 2021. A poor score is not just an audit finding. It is a signal Google uses when deciding where to rank your page against a competitor's.
The editor runtime that ships to every visitor
When you build a site on Wix, you are working inside a visual editor. Drag elements, resize columns, adjust fonts. It is intuitive and that is the point. The problem is that a significant portion of the JavaScript that powers that editor gets shipped to your visitors' browsers even though they have no need for it.
Wix's rendering architecture has improved over the years, but the platform still loads a JavaScript bundle in the background that reflects its editor-based origins. That bundle has to be downloaded, parsed, and executed by the browser before the page finishes loading. On a mobile device on a standard 4G connection, that parsing time is measurable and it shows up directly in LCP scores.
Squarespace follows a similar pattern. It loads its own front-end framework, jQuery as a dependency, and a collection of scripts that support features many sites do not use at all. The browser does not know which features your site actually needs. It loads everything on offer.
Unused CSS and the render-blocking problem
A hand-coded site ships only the CSS it uses. A website builder ships the CSS for every layout, component, and feature the platform offers, because it has no way of knowing in advance which ones a given site will need. On Squarespace, audits routinely flag hundreds of kilobytes of CSS that a specific site never references.
Render-blocking resources are files the browser must fully download and process before it can display anything on the page. CSS is render-blocking by default. The more unused CSS a page carries, the longer that blocking period lasts, and the longer a visitor stares at a blank screen before content appears.
Google's Lighthouse tool, which powers PageSpeed Insights, flags render-blocking resources as a primary cause of poor LCP. On builder-based sites, this is almost always in the report.
Fonts, images, and the layout shift problem
CLS, the metric that captures layout instability, is another area where builders consistently struggle. The issue is usually fonts and images loading in after the initial render.
When a browser loads a page, it renders text in a fallback system font first, then swaps it out once the custom web font has downloaded. If the fallback and the custom font have different dimensions, text reflows and elements shift. Visitors see the page jump. That shift is recorded as CLS.
Builders load fonts generically because they need to support every possible font combination a user might choose. A custom site can preload the exact fonts it uses, specify fallback metrics that minimise shift, and use font-display: swap correctly. The result is a stable layout from the first render.
Images are handled similarly. Builder platforms often do not enforce lazy loading, correct dimension declarations, or modern image formats like WebP by default across all templates. Each of these omissions adds to the payload the browser has to process before the page is usable.
Third-party scripts pile on
Most builder sites accumulate third-party scripts over time. A chat widget. An analytics snippet. A cookie consent banner. A social media pixel. Each of these is an additional network request, and each blocks or competes with the page's own resources for bandwidth.
This is not exclusive to builders. Custom sites can suffer from the same problem if scripts are added carelessly. The difference is that custom code gives you precise control over when scripts load. You can defer non-essential scripts until after the page is interactive, load them on user interaction rather than on page load, or replace heavy third-party widgets with lightweight alternatives. In a builder, you add the integration the platform supports and accept whatever loading behaviour it ships with.
What these scores mean in practice
A PageSpeed score in the 40–65 range on mobile means Google's crawler is observing a slow, potentially unstable page experience. That observation feeds directly into how the page ranks against competitors with faster sites on the same queries.
Google's own research found that the probability of a user bouncing increases by 32% when page load time goes from one second to three seconds, and by 90% when it goes from one second to five seconds. Slower pages do not just rank lower. They convert less of the traffic they do receive.
Every site I have built from scratch has scored between 97 and 100 on PageSpeed Insights, with all three Core Web Vitals green on mobile. That is not a difficult number to hit when you are writing clean HTML, shipping only the CSS you need, preloading fonts, and deferring scripts. It is difficult to hit when the platform you are building on was not architected with those constraints in mind.
Can you fix a builder site's PageSpeed score?
To a limited degree. You can compress images before uploading, reduce the number of third-party integrations, and choose a faster template if the platform offers one. Some platforms have made genuine progress on performance through server-side rendering improvements.
But you cannot remove the platform's own JavaScript runtime. You cannot eliminate unused CSS that comes from the builder's framework. You cannot control how the platform loads its own dependencies. The ceiling on what is achievable from inside the builder's interface is set by decisions made in the platform's architecture, not by anything you can adjust in the settings panel.
If a fast, high-scoring site matters to you, whether for search rankings, user experience, or simply because your clients deserve it, the structural solution is a site that was never built inside a builder in the first place.
