Why your Wix site is slow, and what a rebuild actually changes.
Where the weight in a builder site comes from, why it costs you on phones and in search, and how to check your own site without asking us.
Websites
You built the site yourself, or someone built it for you in an afternoon, and for a while it did the job. Then you opened it on your phone in a car park and watched it load. The text jumped about. The menu arrived late. Somewhere in that wait, a customer decided to ring someone else.
This is not a Wix problem in particular. Squarespace, GoDaddy's builder and most of their cousins produce sites of the same shape, and the shape is what makes them slow. The causes have names, and a rebuild changes some of them and keeps others. This is what we tell people who ask.
Where the weight comes from.
A web page is a pile of files your visitor's phone has to download and work through before it can show anything. The slowness you feel is mostly the size of that pile and the order it arrives in. On a builder site the pile is large for four reasons.
- The builder's own runtime. A builder site is not really a page. It is a small application that draws the page after it loads, and that application ships on every visit whether your page needs it or not. It is often the single largest thing your visitor downloads, and it has to run before your content appears.
- Images that were never resized. Builders let you drop in a photo straight from your camera roll. Many will then serve a version far larger than the space it fills, so a phone downloads a poster to show a thumbnail.
- Third-party widgets. The booking button, the chat bubble, the Instagram feed, the review carousel, the map. Each one loads code from someone else's server, and each one is allowed to slow your page down as much as it likes.
- Template styling for everything you did not use. The template carries the styling for every layout the designer offered, including the twenty you never picked. Your visitor downloads all of it.
None of these are mistakes on your part. They are the cost of a tool that has to work for everyone, on every page, without anyone looking at the code.
Why it hurts more on phones.
Most of your visitors are on phones, and a phone is a hard place to be a heavy page. The connection is slower and less steady than the office wifi you tested on. The processor is weaker, so a script that runs in a blink on your laptop takes a real fraction of a second on a three-year-old handset. And the screen is small, so a layout that shuffles while it loads is not a flicker. It is the button moving away from someone's thumb.
Google measures the things you feel. Its Core Web Vitals come down to three plain questions: how long until the main content appears, how quickly the page responds when someone taps, and how much the layout jumps about while it loads. Google uses them as one ranking signal among many, and it looks at the mobile version of your site rather than the desktop one. A slow page is not the only reason a site ranks poorly, but it is the reason you can measure yourself, today, without a consultant.
The slowness is not a mood. It is a pile of files, and every one of them has a name.
What hand-written HTML means.
When we say we build sites in hand-written HTML and CSS, we mean the page is written directly, as a document, rather than generated by an application at the moment someone visits. HTML is the structure: this is a heading, this is a paragraph, this is a link. CSS is the appearance. Browsers have read both for thirty years and are very good at it.
For a non-technical reader, the practical difference is this. There is no runtime to download before anything shows. There is no styling for features you did not use. Every image is sized for the space it fills. The page arrives as a page, and the browser starts drawing it as soon as the first bytes land. The result is a site that is usually a fraction of the size, costs almost nothing to host, and still works in five years because there is nothing underneath it to go out of date.
It also means the site is a folder of files you own. You can move it to any host, hand it to another developer, or keep a copy on a USB stick. Nothing about it is rented.
What a rebuild keeps.
People worry that a rebuild means starting again, and a builder's cancellation page will happily encourage that worry. It does not have to be that way. A careful rebuild keeps:
- Your content. The words, the photos, the services, the prices. We carry them across and tidy them. We do not throw them away.
- Your addresses. Every page on the old site has a URL, and some of those are known to Google and linked from elsewhere. We keep the ones that make sense. For the ones that change, we set up permanent redirects so the old address lands on the new page. That is how rankings survive a move.
- Your domain and your email. The domain comes with you. Nothing about your email changes.
- Whatever is working. If a page is bringing in enquiries, we do not redesign it for the sake of it.
What changes is underneath: the structure, the weight, the titles and descriptions that search engines read, how images are delivered, and where the site is hosted. From the outside it should feel like the same business with the fog lifted.
How to check your own site.
You do not need us to find out whether any of this applies to you. Two checks take about ten minutes and cost nothing.
- Run PageSpeed Insights. Google offers it free at pagespeed.web.dev. Paste your address and look at the mobile result first. You get a performance score and, underneath, a list of the biggest opportunities. If that list is led by unused JavaScript, unused CSS and images that could be smaller, you are looking at the four causes above.
- Look at the page weight yourself. In Chrome, open your site, right-click the page and choose Inspect, then pick the Network tab and reload. The bar at the bottom shows how many requests the page made and how much data it transferred. Sort by size and see what is at the top. A brochure site that transfers several megabytes, or makes well over a hundred requests, is carrying weight it does not need.
The same Lighthouse audit that powers PageSpeed Insights is built into Chrome's developer tools, so you can rerun it on any page whenever you like. Write the scores down now, so you have a before.
If the numbers look fine, they probably are, and you do not need a rebuild. If they do not, and you would like a second opinion, send us the address of your current site and we will tell you honestly what it would take and what it would cost. If the answer is to leave it alone, that is what we will say.