Why Is My Website So Slow (And How to Fix It)

Speed is the least visible thing about a website and one of the most expensive to get wrong. Nobody emails to say your site was slow — they just leave, and you never find out they were there.

Google’s research found that 53% of mobile visitors abandon a page taking longer than three seconds. For a business paying for ads or working hard for search traffic, that’s budget draining through a hole you can’t see.

The good news: slow websites are slow for a short list of predictable reasons, and most are fixable without rebuilding anything.

First, measure — don’t guess

Before changing anything, get numbers. Your own impression of your site’s speed is unreliable: your browser has cached it, you’re probably on good wifi, and you’re not seeing what a first-time mobile visitor sees.

PageSpeed Insights — paste your URL and get a mobile score out of 100 plus a specific list of problems. Use the mobile tab; that’s where most of your visitors are and where problems show up. Under 50 is a genuine problem. 90+ is the target.

Search Console → Core Web Vitals — this shows data from real visitors over the past 28 days rather than a single lab test. It’s the truest picture, and it’s what Google actually uses.

Test a few pages, not just the homepage. Homepages are often the most optimised page on a site. Test a service page and a blog post too.

Note the difference between the two sources: PageSpeed runs a simulated test right now, Search Console reports what real people experienced. When they disagree, believe Search Console.

What the scores are measuring

Three metrics carry most of the weight — Google’s Core Web Vitals:

LCP (Largest Contentful Paint) — how long until the biggest visible thing finishes loading, usually your hero image or headline. Target: under 2.5 seconds. This is the one that most often fails, and images are usually why.

INP (Interaction to Next Paint) — how quickly the page responds when someone taps. Target: under 200ms. Heavy JavaScript is the usual cause.

CLS (Cumulative Layout Shift) — how much the page jumps around while loading. Target: under 0.1. Almost always images or ads without reserved space.

Knowing which one fails tells you where to look, which saves you from optimising the wrong thing.

The usual causes, in order

1. Huge, unoptimised images

The number one culprit by a wide margin, and the easiest to fix.

A photo straight from a phone is often 4–12 megabytes and 4000 pixels wide. Displayed in a 600-pixel-wide slot, every one of those extra pixels is downloaded and thrown away. Put four on a page and you’ve built something that takes twenty seconds on mobile data.

The fix:

• Resize to the size actually displayed. A full-width hero rarely needs more than 1800px wide; a thumbnail needs 400px.
• Use modern formats. WebP is typically 25–35% smaller than JPEG at the same quality, and is supported everywhere that matters.
• Compress. Quality 80 is visually indistinguishable from 100 for photographs and roughly half the size.
• Lazy-load anything below the fold, so images further down don’t compete with what’s visible.
• Set width and height on every image. Costs nothing and eliminates most layout shift.

Getting images right alone frequently takes a page from 6MB to under 800KB. Nothing else on this list comes close for effort-to-result.

2. Too many plugins and scripts

Every plugin, tracking pixel, chat widget, review carousel, and font is code the visitor’s phone must download, parse, and execute.

WordPress sites accumulate these over years. A site with 30 plugins is running 30 sets of code on every page load, including ones only used on a single page.

Third-party scripts are especially costly because you don’t control them. A chat widget that loads slowly blocks your page while you wait on someone else’s server.

The fix:

• Audit what’s installed. Deactivate anything unused, then delete it — inactive plugins are still a security and maintenance burden.
• Keep one plugin per job. Three plugins overlapping on SEO is three times the weight for no extra benefit.
• Question every third-party script. Does the chat widget produce more leads than the speed costs you? Sometimes yes. Measure rather than assume.
• Load non-critical scripts after the page renders.

3. Cheap or overloaded hosting

Budget shared hosting puts hundreds or thousands of sites on one server. When a neighbour gets busy, you slow down, and you have no visibility into it.

The symptom is a slow time to first byte: a delay before anything happens at all, before any image or script is even requested.

The fix: move to hosting with reserved resources, or better, to static/edge hosting that serves pre-built files from a location near each visitor. Our guide to choosing web hosting covers the options honestly.

4. Bloated page builders and themes

Drag-and-drop builders are flexible because they ship code for every layout you might use. Your visitor downloads all of it regardless.

This is the structural reason so many template sites can’t break 50 on mobile no matter how much you optimise. You’re not fixing a mistake; you’re fighting the platform’s design. It’s one of the real tradeoffs covered in website builders vs custom.

5. No caching

Without caching, a database-driven site rebuilds every page from scratch for every visitor — running queries and assembling HTML that’s identical to what it produced a second ago.

Caching stores the finished page and serves it instantly. On a WordPress site it’s frequently the single biggest improvement available.

Static sites sidestep this entirely: pages are already built, so there’s nothing to assemble.

6. No CDN

If your server sits in one city, visitors far away wait for data to physically travel. A CDN keeps copies worldwide and serves from whichever is closest.

Free tiers exist and are genuinely good. For a business serving one metro it matters less, but it still helps, and it costs nothing.

7. Web fonts

Each custom font weight is a separate file, and text is often invisible until it loads. Four fonts in three weights is twelve files before a word appears.

The fix: two font families maximum, only the weights you use, font-display: swap so text shows immediately, and preload the one your headline uses.

8. Render-blocking resources

CSS and JavaScript in the page head must download and execute before anything renders. A large blocking file means a blank screen while it loads. PageSpeed Insights flags these specifically.

The fix list, ranked by impact

1. Compress and resize every image — biggest win, least effort, works on any platform
2. Remove unused plugins and third-party scripts — be ruthless
3. Add caching — via a plugin, or a host that handles it properly
4. Upgrade hosting if time-to-first-byte is slow
5. Add a CDN — free tiers are fine
6. Trim fonts to two families and only the weights you use
7. Defer non-critical JavaScript
8. Set dimensions on images and ad slots to kill layout shift
9. Consider a faster foundation if the platform itself is the ceiling

Work down that list and stop when you hit your target. Most sites are fixed by items one through three.

Fixable, or structural?

This is the question worth answering before spending money.

Fixable looks like: good bones, but 8MB of images, fourteen plugins, and no caching. A day of work gets you from 35 to 85.

Structural looks like: images already optimised, few plugins, decent hosting, and still scoring 40, because the theme ships 900KB of JavaScript before your content. No amount of optimisation fixes that ceiling.

An honest audit tells you which you’re facing. Spending three months optimising a site that can’t get there is a waste; rebuilding a site that just needed image compression is worse.

What “fast enough” means

Chasing 100 isn’t the goal — it’s diminishing returns, and the last ten points rarely change visitor behaviour.

Sensible targets:

• Mobile PageSpeed 90+ — achievable for a marketing site
• LCP under 2.5s, INP under 200ms, CLS under 0.1
• Total page weight under 1MB for a typical page

Past that, spend your effort on what the page actually says. A fast page that doesn’t persuade anyone is still a failure — see what makes a website convert.

A 90-minute speed fix, step by step

If you want to do this yourself today, here’s a sequence that gets most sites a long way without touching code.

Minutes 0–10 — Baseline. Run PageSpeed Insights on your homepage and two inner pages, mobile tab. Screenshot the scores. Write down which of LCP, INP, and CLS are failing. You need this to know whether anything you do next helps.

Minutes 10–40 — Images. Open each key page and list every image. For each: is it larger than the space it occupies? Export a resized copy at the displayed width, convert to WebP, compress at quality 80, and replace. On most sites this is where the page weight collapses.

Minutes 40–55 — Plugin audit. List everything installed. For each one ask: do I know what this does, and did I use it this year? Deactivate everything that fails both. Retest the site to confirm nothing broke, then delete rather than leaving them dormant.

Minutes 55–70 — Caching and CDN. Enable caching if your host offers it, or install one reputable caching plugin — one, not three. Point your domain through a CDN’s free tier if you aren’t already.

Minutes 70–80 — Fonts and scripts. Count your font files. Remove weights you don’t use. Look for chat widgets, popups, and tracking scripts you forgot were there, and remove anything that isn’t earning its place.

Minutes 80–90 — Retest and record. Run PageSpeed again on the same three pages. Compare against your screenshots.

If you’ve gone from 40 to 80, the remaining gap is usually structural, and that’s a different conversation. If nothing moved at all, the platform is your ceiling.

Keeping it fast

Speed decays. Sites get slower over time as photos are uploaded straight from a phone, plugins accumulate, and someone adds a tracking pixel for a campaign that ended a year ago.

A light routine prevents it:

• Every new image gets resized and compressed before upload. Make this a habit, not a project.
• Monthly, run PageSpeed on your two most important pages
• Quarterly, review installed plugins and scripts and remove what’s no longer used
• After any redesign or major change, retest before assuming it’s fine

Five minutes a month protects work that took a day. It also means you notice a regression when it happens rather than six months later when you wonder why enquiries dropped.

Common questions

Does site speed really affect Google rankings? Yes, though it’s one signal among many. Core Web Vitals are a confirmed ranking factor. Realistically, speed’s larger effect is on conversion — visitors who leave never convert regardless of where you rank.

My desktop score is 95 but mobile is 40. Why? Mobile tests simulate a slower processor and network. That’s closer to reality for most visitors, which is why mobile is the score that matters.

Will a faster host fix everything? No. Hosting affects time-to-first-byte. If your problem is 8MB of images, the fastest host in the world still has to send 8MB.

How often should I check? Monthly, and after any significant change. Speed regresses quietly — a new plugin or a page of uncompressed photos undoes months of work.

Is it worth paying someone? If your site is under 50 and you’re spending on ads or relying on search, yes. You’re already paying for the traffic; losing half of it to load time is the expensive option.

---

If your site scores under 50 and you’d rather have someone diagnose it properly, we offer a free speed audit — your scores, the actual causes, and what fixing them involves, in plain English. Or see how we approach speed on every build.