Most people find out their website is slow from a customer. Somebody mentions it took a while to load on their phone in the parking lot, and that is the first anyone has heard of it.
The usual next step is to go looking for a setting to change. There generally isn’t one. Speed is not a switch on a website, it is a consequence of how much work the page asks a phone to do before anything useful appears.
Here is what that work actually is, and where custom code changes it.
What actually makes a page slow
A browser cannot show your page until it has downloaded the files the page depends on, worked out what they mean, and run them. Three things drive that.
How much code arrives. Every stylesheet, script, and font is a separate thing to fetch. Size matters, but so does the number of files.
How much of it blocks. Some files stop the page rendering until they finish. One render-blocking script in the wrong place can hold up everything behind it, even on a small page.
How much work happens after it arrives. Downloading is only half of it. The phone still has to parse and run all that JavaScript, and a mid-range phone is a lot slower at this than the laptop the site was built on.
That last one is the one that surprises people. A site can look fine on the machine it was designed on and be genuinely painful on a four-year-old Android.
Where page builders spend the budget
A page builder has a hard job. It has to be ready for whatever you might drag onto the page, which means the code for all of it has to be available. So the builder ships a broad set of styles and scripts, and your page uses some fraction of it.
Then plugins add to it. Most plugins load their own CSS and JavaScript on every page of the site, not just the page where they do something. A booking form on your contact page can be loading its scripts on your homepage too.
None of this is anybody behaving badly. It is the cost of a system that has to work for everyone without knowing anything about your site in particular. It is just that you pay that cost on every page load, forever.
What custom code changes, and what it doesn’t
A custom build starts from the other end. The page ships the code that page uses, and not the rest. There is no general-purpose layout engine to load, because the layout was written once, for that page.
That usually shows up as fewer files, less JavaScript, and less work for the phone. The improvement tends to be biggest on mobile, which is also where most local business traffic actually is.
What it does not do is make speed automatic. A custom site with four unoptimized hero images and three tracking scripts will be slow, and I have seen that. The real difference is not that custom is fast by nature. It is that on a custom build, when something is slow, you can go find it and remove it. On a hosted builder you often cannot, and that is the part that matters over a few years.
How to check your own site, in about two minutes
You do not have to take anyone’s word for this, including mine.
Put your homepage into Google PageSpeed Insights, then do it again with your busiest interior page, which for most local businesses is a service page rather than the homepage. Look at the field data section, because that is measured from real visitors rather than from a test.
Three numbers matter, and Google publishes the targets:
- Largest Contentful Paint: 2.5 seconds or less. How long until the main thing on the page appears.
- Interaction to Next Paint: 200 milliseconds or less. How long the page takes to respond when somebody taps something.
- Cumulative Layout Shift: 0.1 or less. How much the page jumps around while it loads, which is the one that makes people tap the wrong button.
Those are assessed at the 75th percentile of real page loads, so a quarter of your visitors can be having a worse time than the number suggests. Check mobile and desktop separately, because Google scores them separately.
If you are inside all three, your site is not your problem and you should spend the money somewhere else. That is a real outcome and it happens more than you would think.
When it is worth rebuilding for speed
Being honest about this: speed alone is rarely a good enough reason to rebuild a site. It is a good enough reason when it comes with something else.
It is usually worth it when the site is slow and you cannot change it yourself, or when it is slow and you are already planning a redesign, or when the slow pages are the ones people actually buy from. If it is slow and you are happy with everything else, the cheaper move is often to fix the images, cut the plugins you stopped using, and measure again.
One thing I will say plainly, because it is the part people get talked out of: whatever you do next, make sure you end up owning the result. A site you cannot move, cannot export, and cannot hand to somebody else is a site whose speed is somebody else’s decision. That is not a technical problem you can fix later, and it is worth knowing before you sign.