Why is my website
so slow?
Almost always one of six things. Here is how to work out which one you have, and what fixing it is actually worth.
Test it on a phone, not your desk
Your site is not slow on your laptop. It is cached, you are on office wifi, and you already know where everything is. Your visitor is on a phone, on mobile data, on a page they have never seen, deciding in a couple of seconds whether to stay.
That is the only test that counts. Open your site on your phone with wifi turned off, from a cold start, and watch how long it takes before the main heading and image are readable. If you are counting past three or four seconds, you have a problem worth money.
The measurement everyone quotes is the PageSpeed score out of 100. It is a useful signal and a terrible target. Chasing 100 can send you optimising things nobody notices while the actual problem, a 4MB hero image, sits there untouched. Look at Largest Contentful Paint instead: how long until the biggest thing on screen has loaded.
What is usually to blame
Roughly in the order we find them when we look at a site that is struggling.
1. Images straight off the camera
The single most common cause, and the easiest to fix. A photographer sends 6000px JPEGs, someone uploads them to the gallery, and the browser downloads several megabytes to display them at 400px wide on a phone. Resize to the size they are actually displayed at, save as WebP, set width and height attributes so the layout does not jump, and lazy-load anything below the fold.
2. Page builders and plugin stacks
Drag-and-drop builders buy you convenience and charge for it in weight. They ship their own CSS and JavaScript on every page whether that page uses it or not, and they nest markup deeply enough that the browser has real work to do before it paints anything. Add twenty plugins, each loading its own stylesheet and script sitewide, and you are downloading a small application to show a page of text.
3. Third-party scripts you forgot about
The chat widget, the review carousel, the booking embed, two analytics tags, a heatmap tool, a pixel from an ad campaign that ended last year. Each one is a request to somebody else's server, and your page waits on servers you do not control. This is usually the biggest quick win after images: audit what is loading, delete what is not earning its place, and load what remains after the page is usable rather than before.
4. Fonts that block the first paint
A font loaded from a third-party stylesheet blocks rendering while the browser fetches the stylesheet, then fetches the font files it names. Self-host your fonts, load only the weights you actually use, and set font-display so text appears immediately in a fallback rather than leaving a blank page while a font downloads.
5. Sliders, video backgrounds and animation libraries
A hero slider is a JavaScript library plus every image in the rotation, downloaded so a visitor can see the first one. An autoplaying background video is tens of megabytes for decoration. Both are usually inherited from a theme demo rather than chosen. A single well-chosen image outperforms a five-slide carousel almost every time, and it loads in a fraction of the weight.
6. Slow hosting, no CDN, no caching
Time to First Byte is the wait before the server sends anything at all. On budget shared hosting, with a database query per page load and no caching layer, that can be most of a second before the browser has learned there is an image to fetch. Nothing you do to the page wins that time back. Static pages served from a CDN close to the visitor remove the problem instead of optimising around it.
Ten minutes, three tools
PageSpeed Insights, mobile tab only
Run your homepage and one service page. Ignore the desktop tab. Two things matter on the report. If there is a field data section at the top, that is real Chrome users on your actual site and it is the honest number. Below it, the lab test lists your largest image, your heaviest scripts and your render-blocking resources by name. That list is your to-do list, in order.
Chrome DevTools, network throttled
Open your site, open DevTools, go to the Network tab, set throttling to Slow 4G, tick disable cache and reload. Sort by size. The offenders identify themselves. Look at the total transferred at the bottom: for a normal brochure page there is no good reason to be over a megabyte or two.
Search Console, Core Web Vitals report
This tells you whether the problem is one page or the whole site, grouped by URL pattern, using data from real visits. A single slow template affecting forty pages is a different job from one bloated homepage, and this is where you find out which one you are dealing with.
One caveat worth knowing before you panic at a bad score: a lab test runs on a simulated slow device with a cold cache, which is deliberately harsher than most real visits. If your field data looks fine and your lab score looks alarming, trust the field data.
In the order worth doing them
- →Resize and convert every image to WebP at the size it is displayed, then set explicit width and height
- →Lazy-load everything below the fold, and never lazy-load the hero image
- →Delete third-party scripts you cannot name a purpose for, and defer the ones that survive
- →Self-host fonts, two weights maximum, with font-display set
- →Replace the slider with one image and the background video with a still
- →Turn on page caching, and put a CDN in front of the site
- →Remove plugins that are inactive, duplicated, or doing something the theme already does
- →Re-measure after each change, so you know what worked rather than guessing
The first three usually account for most of the improvement. If you do nothing else, do those.
When a rebuild is the cheaper answer
Most slow sites can be made fast without starting again, and if that is your situation you should do that. Paying for a rebuild to solve a problem that three hours of image compression would fix is a bad trade, and anyone telling you otherwise is selling.
It changes when the weight is structural. If the page builder ships its runtime on every page, if the plugin stack is load-bearing and nobody dares touch it, or if the theme loads its whole library to render a paragraph, then you are optimising around a decision rather than fixing it. At that point the work never finishes, and each round of tuning buys less than the last.
The tell is simple. If you have done the images, cut the scripts, fixed the fonts and the site is still slow, the platform is the problem. That is the point where rebuilding costs less than continuing to pay for the workaround.
Speed removes a barrier. It does not create demand.
A fast site that never asks for the enquiry is still a fast site with no enquiries. If people are arriving and not getting in touch, speed is one candidate among several, and often not the main one. We wrote a separate guide on the rest of them: how to get more enquiries from your website.
Common questions
How fast should my website be?
Judge it on a phone, on mobile data, not on your office wifi. Google publishes thresholds for Core Web Vitals, and the one that matters most for a business site is Largest Contentful Paint: the main thing on screen should finish loading within 2.5 seconds for most visitors. Interaction to Next Paint and Cumulative Layout Shift cover how quickly the page responds and whether it jumps around while loading. Those three are the target, not a single overall score out of 100.
Does site speed affect Google rankings?
Yes, but less than most people assume. Google has confirmed Core Web Vitals are part of its page experience signals, so speed is a genuine ranking factor. It is a tiebreaker rather than a trump card: a fast page with weak content will not outrank a slow page that answers the question better. The bigger effect is on the visitor, who leaves before they ever see your booking form.
Will making my site faster get me more enquiries?
Only if speed is what was stopping them. A slow site loses people before they read anything, so fixing it removes a barrier. It does not create demand, make your offer clearer, or shorten a fourteen-field contact form. Fix the speed, then look at whether the page actually asks for the enquiry.
Can a slow website be fixed without a full rebuild?
Often, yes. Oversized images, an unused slider, four tracking scripts and a chat widget are the usual culprits, and all of them can be dealt with on the existing site. A rebuild only becomes the cheaper option when the slowness is structural: a page builder shipping a heavy runtime on every page, a plugin stack nobody can safely remove, or a theme that loads its entire library to render a text block.
Does hosting make a difference to site speed?
It sets your floor. Time to First Byte is how long the server takes to start answering, and on cheap shared hosting that can be most of a second before a single image is requested. Nothing you do on the page recovers that time. Static hosting on a CDN serves the page from a location near the visitor and removes the problem rather than optimising around it.
Want us to look at yours?
Fifteen minutes, no deck. We will tell you whether it is a fix or a rebuild, and we will say fix if it is a fix.
Book a 15-min call →