DeepCurrent
Why builder sites are slow
Why website builder sites load slowly, and what it costs you
Drag-and-drop builders made it easy for anyone to put a website up. The price of that ease is usually paid in code your visitors download and never see — and in the seconds they spend waiting for it.
How block building works
Every block arrives with everything it might ever need
Most website builders work in blocks. A header block, a gallery block, a slider, a price table, a contact form. You drag them onto the page, pick a few settings, and the builder does the rest.
To make that work for millions of different sites, each block has to be ready for anything. A gallery block carries the code for every layout it offers, not just the one you chose. A button carries the styling for every colour, size and hover effect in its settings panel. Each block is wrapped in several layers of boxes so it can be dragged, nested and resized in the editor — and those boxes usually stay in the finished page.
Then the site as a whole tends to load the style rules for every kind of block the builder offers, on every page, whether that page uses them or not. Add the builder's own scripts, the animation library behind a single fade-in, three or four font files, and a photo uploaded straight from a phone at full size, and an ordinary five-section page can weigh several times what it needs to.
None of this is carelessness. It is the cost of flexibility: a builder can't know in advance what you'll put on the page, so it sends the lot.
“Historically, many page builders were associated with heavy markup and large CSS and JavaScript payloads, which often led to slower loads and weaker Core Web Vitals.”
The same chapter is fair about it: newer builders load more selectively, which helps — but it says those efforts “do not completely erase the performance gap between builder-heavy sites and more tightly controlled builds.”
What the extra code does
A heavier page costs time in three places
More to download
Every kilobyte has to travel to the visitor's phone before the page can finish. On a patchy mobile signal, that is often where most of the wait goes.
More for the phone to work out
The browser checks every style rule against the page and runs every script before it can draw and respond. Unused rules still have to be read; unused scripts still run.
Things jump as they arrive
When pictures and blocks load late, the page shifts under the reader's thumb — the classic tap on the wrong button. Google measures that too.
The size of the median mobile home page in 2025, across millions of sites HTTP Archive measures — and it grew 8.4% in a year.7
Of the style code on a real 12-page insurance agency site we moved came out — rules no page used, plus builder leftovers — and the site still looked identical. See that move.
How fast people leave
Every second of waiting loses visitors
Google and SOASTA studied mobile visits to find out what happens as a page gets slower. Scroll down, and the clock runs.
- From 1 to 3 seconds +32%chance they bounce
- From 1 to 5 seconds +90%chance they bounce
- From 1 to 6 seconds +106%chance they bounce
- From 1 to 10 seconds +123%chance they bounce
“Bounce” means leaving after one page. Source: Google/SOASTA Research, 2017, published by Think with Google in “Find out how you stack up to new industry benchmarks for mobile page speed.”2
of mobile site visits are abandoned if the page takes longer than three seconds to load. Google data from March 2016, published by Think with Google.1
How Google thinks about it
Google measures how your page feels to real visitors
Google calls it page experience, and the part it measures with numbers is a set of three checks called Core Web Vitals. They're taken from real Chrome visitors to your site, not a lab test, and Google is plain that they count: “Core Web Vitals are used by our ranking systems.”3
Largest Contentful Paint
How long until the biggest thing on the first screen — usually the main photo or headline — has appeared.
Interaction to Next Paint
How quickly the page reacts when someone taps or clicks. Heavy scripts are the usual reason it lags.
Cumulative Layout Shift
How much the page jumps around while it loads. Late-arriving pictures and blocks push it up.
Thresholds for a “good” score, measured at the 75th percentile of page loads, on mobile and desktop separately.5 4
Being honest about it: speed does not beat relevance. Google says so directly —
“Google Search always seeks to show the most relevant content, even if the page experience is sub-par. But for many queries, there is lots of helpful content available. Having a great page experience can contribute to success in Search, in such cases.”
For a local business, “lots of helpful content available” is exactly the situation: a dozen plumbers or salons in town, all with a decent page. When the pages are close, the one that loads fast and doesn't jump around can have the edge — and it keeps more of the visitors it does get.
Most sites aren't there yet. In 2025, 48% of mobile websites had good Core Web Vitals, up from 44% the year before — which means more than half still didn't.6
In fairness to builders
Builders are good at getting you started
Website builders put millions of small businesses online that otherwise wouldn't be, and many are getting faster every year. We're not here to knock them. Some well-built builder sites load quickly, and some hand-coded sites are slow.
The difference is what happens after the site exists. A builder keeps every option on hand forever, because you might come back and drag in a new block tomorrow. Once a site is finished, most of those options are dead weight — and that's the part we can take away.
The other half of the problem is the reason people stay on a builder: they need to be able to change their own site. In Deep Current you still can, without the builder — you ask for the change in plain English and it's made. How that works.
What we do about it
We move your site over and take out what it doesn't use
We copy every page from wherever it lives now, remove style rules and builder leftovers that no page uses, re-save oversized pictures in modern formats, and let pictures further down the page wait until they're needed. Then we check every page side by side against the original, at desktop and phone width, so nothing you can see has changed.
On a 12-page insurance agency site, that took the page code from 1,855 KB to 717 KB and the style code from 3,180 KB to 784 KB, and the pages we compared scored identical. Less to download usually means a faster page — but every site starts somewhere different, so results vary.
We’ll move it for you, free. The move costs nothing. To put the new site live on your own domain you pick a plan — from $29 a month, no contract.
Sources
Where every figure on this page comes from
- 53% of mobile visits abandoned past 3 seconds. Think with Google, “Mobile site load time statistics” — Google Data, Global, n=3,700 aggregated, anonymized Google Analytics data from a sample of mobile web sites opted into sharing benchmark data, March 2016. Think with Google has since moved; archived copy: web.archive.org › thinkwithgoogle.com › mobile-site-load-time-statistics
- Bounce probability rising 32% / 90% / 106% / 123% as load time goes from 1 second to 3, 5, 6 and 10 seconds. Google/SOASTA Research, 2017, in Think with Google, “Find out how you stack up to new industry benchmarks for mobile page speed” (February 2018). Archived copy: web.archive.org › thinkwithgoogle.com › mobile-page-speed-new-industry-benchmarks
- “Core Web Vitals are used by our ranking systems”, and relevance coming first. Google Search Central, “Understanding page experience in Google Search results”: developers.google.com/search/docs/appearance/page-experience
- What each Core Web Vital measures. Google Search Central, “Understanding Core Web Vitals and Google search results”: developers.google.com/search/docs/appearance/core-web-vitals
- Good thresholds (2.5 s, 200 ms, 0.1) at the 75th percentile. web.dev, “Web Vitals”: web.dev/articles/vitals
- 48% of mobile websites with good Core Web Vitals in 2025 (44% in 2024). HTTP Archive, Web Almanac 2025, Performance chapter: almanac.httparchive.org/en/2025/performance
- Median mobile home page 2.6 MB, up 8.4% from 2.4 MB in 2024. HTTP Archive, Web Almanac 2025, Page Weight chapter: almanac.httparchive.org/en/2025/page-weight
- Page builders, heavy markup and the remaining performance gap. HTTP Archive, Web Almanac 2025, CMS chapter: almanac.httparchive.org/en/2025/cms
- The 12-page site figures (1,855 KB → 717 KB page code, 3,180 KB → 784 KB style code, scored identical side by side) are from our own move of a real insurance agency's site in October 2026, measured by our copy tool. One site's result; yours will differ.
We’ll move it for you, free
Send us your address. We copy every page, tidy away the code it doesn’t need, check it side by side against the original, and show you before anything changes.