A lot of people who think their website is slow assume they need a new one. Sometimes they do. But slowness is rarely a mystery, and it’s rarely the whole site’s fault. The same six causes turn up again and again, and most of them can be fixed on the site you already have.
It’s worth taking seriously. Google’s own research found that the chance of someone leaving a page rises sharply as load time goes from one second to three. Google also uses speed as a ranking signal through its Core Web Vitals, though it’s a fairly light one. So a slow site can cost you visitors in search results and again once they’ve clicked through.
The six usual culprits
1. Your images are too big
This is the most common cause, so start here. A photo straight off a phone or a stock site is often 4–10 MB. Shown in a card on your homepage, it only needs to be around 150 KB, dozens of times smaller, and nobody will see the difference at that size. A hero section with three uncompressed photos can weigh more than the rest of the site put together.
To fix it, resize images to roughly the size they’re shown at, and export them as WebP or AVIF instead of JPEG or PNG. Use responsive image sizes (srcset) so phones get smaller files than desktops. Lazy-load anything below the first screen so it only downloads when someone scrolls towards it.
Don’t lazy-load the main image at the top of the page, though. That image is usually what Google measures for loading speed, and lazy-loading it makes things worse. If anything, give it fetchpriority="high".
Most modern platforms (Shopify, Webflow, Framer, and WordPress with the right plugin) handle the format conversion for you. Resizing is still down to whoever uploads the images.
2. Too much JavaScript
Images make a page heavy. JavaScript makes it busy. Every script has to be downloaded, read and run before parts of the page will respond, and on a mid-range phone the running time is often the biggest part of the wait. Sites built by stacking plugins, page-builder widgets and animation libraries collect scripts the way a drawer collects old cables.
Google measures the effect with Interaction to Next Paint (INP), which tracks how quickly the page responds when someone taps or clicks. Under 200 milliseconds is good.
To fix it, remove what you’re not using: old plugins, sliders nobody scrolls through, chat widgets nobody opens. Defer whatever’s left so it loads after the content. This usually takes a developer an afternoon, and it’s time well spent.
3. Cheap hosting and no CDN
Before the browser can show anything, it has to get the first response back from your server. On oversold £3-a-month shared hosting, that alone can take more than a second, before a single image, font or script has loaded. And if your server’s in London and your visitor’s in Sydney, the distance adds a delay to every request.
Good hosting doesn’t have to be expensive. Static sites can often be hosted free on platforms like Netlify, Vercel or Cloudflare Pages, and decent hosting for most other sites costs tens of pounds a month. A content delivery network (CDN) keeps copies of your site close to your visitors, and Cloudflare’s free plan is genuinely fine for most small businesses. For the money, this is the biggest improvement on the list.
4. Fonts loaded carelessly
Custom type is worth having. As a design studio, we would say that. But every weight is a separate file, and a site pulling in eight weights across three families is downloading type it mostly never uses, while the visitor waits for text that’s invisible or jumping around.
To fix it, stick to two families and three or four weights in total, and host them yourself as WOFF2 files. Preload the main text font. Use font-display: swap so text shows straight away in a fallback font and switches when the real one arrives.
To stop the page jumping when that switch happens, match the fallback font’s size and spacing to your brand font using size-adjust and the other font metric overrides. Google measures that jumping as Cumulative Layout Shift (CLS), and anything under 0.1 is good.
5. Third-party trackers and embeds
Analytics, ad pixels, heat maps, social embeds, review widgets and video players each take one line of code to add, so they pile up without anyone noticing. Every one of them contacts another company’s server before your page settles. It’s not unusual for the marketing scripts on a page to weigh several times more than the actual content.
To fix it, list every third-party script and make each one justify its place. Whatever survives should load after the page is usable. An embedded YouTube video can show a thumbnail and only load the player when someone clicks it. That one change often saves more than a megabyte.
6. Nothing is cached
A returning visitor shouldn’t have to download your logo, fonts and stylesheets all over again. Without caching headers, every visit starts from scratch. The people most interested in you, the ones who came back, get the slowest experience.
This is a settings change rather than a redesign. Give images, fonts, stylesheets and scripts long cache lifetimes, and give the pages themselves short ones.
There’s one catch. Long cache lifetimes only work safely if a file’s name changes whenever its contents do. Most build tools handle this by adding a unique code (a hash) to filenames automatically. Without that, returning visitors can get stuck with old versions of your site. A CDN like Cloudflare can set up much of the caching for you.
How to find out which one is yours
Run your homepage through Google’s PageSpeed Insights. It’s free and takes about thirty seconds. If your site gets enough traffic, the top section shows how real visitors experienced it, which matters more than the lab test underneath.
Ignore the score and read the list of issues. The wording changes as Google updates the tool, but look for items about:
- image delivery (point one)
- unused or render-blocking JavaScript (point two)
- server response time or document request latency (point three)
The report shows which problems matter most on your site, and this article explains what they mean.
Pay most attention to Largest Contentful Paint (LCP), which is when the main image or headline appears. Google rates anything under 2.5 seconds as good and anything over 4 seconds as poor.
When it’s time to rebuild
All of this assumes the site is worth tuning. Sometimes it isn’t. It might be a theme carrying a decade of plugins, a page builder producing code nobody can untangle, or a platform that fights you on every change. The clearest sign is when the fixes don’t stick, and every new page arrives slow again because the system is heavy by default. At that point, speed comes down to how the site is built. It belongs in the brief for your next site rather than on the maintenance list for this one.
That’s why we build sites to be light from the start. We use system fonts or two self-hosted families, process images when the site is built, and only use as much JavaScript as the design actually needs. It’s much easier to keep a site fast if it never gets heavy in the first place.
Frequently asked questions
Why is my website so slow?
Usually it’s oversized images, too much JavaScript, slow hosting, too many font files, third-party scripts like trackers and embeds, or missing caching. Most sites have two or three of these at once, and most can be fixed without a rebuild.
How do I check my website’s speed?
Run your homepage through Google’s PageSpeed Insights, which is free. Focus on Largest Contentful Paint: under 2.5 seconds is good. Then work through the list of issues it flags.
Do I need a new website to make it faster?
Usually not. Compressing images, removing unused scripts and adding a CDN often make a big difference on an existing site. A rebuild makes sense when the platform itself is the problem and speed fixes keep getting undone.
