Why is my website slow? Ten causes, from oversized images to cheap hosting.

What counts as a slow website?

If you have ever typed "why is my website slow" into a search box, you already know the honest answer: slower than your visitors will tolerate. The objective version comes from Google's Core Web Vitals, which say the main content of a page should appear within 2.5 seconds on a real visit. Past that, patience drains fast, and pages taking four seconds or more sit in Google's poor category.

The good news is that slowness is rarely mysterious. In the sites we audit, the same ten causes appear again and again, usually three or four together. Each one is described below, along with how to spot it and how hard it is to fix. We have written a plain-English guide to what Core Web Vitals actually measure if you want the metrics themselves unpacked first.

Cause 1: Oversized images doing most of the damage

Images are the heaviest thing on most pages, and the most common speed problem we see is photographs uploaded straight from a camera or stock library at 4,000 pixels wide, then displayed at 800. The browser downloads the full four-megabyte file either way. Three or four of those on one page and you have a site that crawls on any mobile connection.

The fix is mechanical rather than clever: resize images to roughly the size they are displayed at, convert them to a modern format such as WebP, and compress them. Most platforms have plugins or built-in settings that do this automatically for every future upload. Of everything on this list, this is the fix with the best ratio of effort to result.

Cause 2: Too many plugins and scripts competing for the browser

Every plugin, tracking pixel, chat widget, and analytics tag adds JavaScript that the browser must download and run before or while it builds your page. Individually each one looks harmless. Collectively, twenty of them can add seconds of load time and make the page feel sticky even after it appears, because the processor is still busy behind the scenes.

Audit ruthlessly. List every plugin and script, ask what each one earns, and remove the ones nobody can defend. Sites accumulate these the way drawers accumulate cables: a tool trialled in 2022, a pixel for a campaign that ended, a pop-up plugin nobody switched off. Removal is free, quick, and entirely reversible if you genuinely miss something.

Cause 3: Cheap hosting with slow server response times

Before your page can even start loading, the server has to respond. On budget shared hosting, your site queues alongside hundreds of others on the same machine, and response times stretch, especially at busy hours. No amount of image compression fixes a server that takes over a second to answer at all.

The symptom to look for is a high time to first byte, which PageSpeed Insights reports as initial server response time. If it regularly exceeds 600 milliseconds, hosting is part of your problem. The fix is a better plan or a better host, typically a modest monthly increase for a UK small business site, and it lifts every page at once.

Cause 4: No caching, so every visit starts from scratch

Caching means storing ready-made copies of your pages so the server does not rebuild them, and the browser does not re-download them, on every single visit. Without it, a returning visitor is treated like a stranger: every image, stylesheet, and script fetched again, every page assembled from a standing start.

Most platforms make this a settings job rather than a coding job. A caching plugin on WordPress, or the built-in caching on managed platforms, can cut repeat load times dramatically in an afternoon. The one caution is configuration: aggressive caching set up carelessly can serve stale content, so change one setting at a time and check the site after each.

Cause 5: Render-blocking resources holding the page hostage

Browsers read a page from the top, and when they meet a stylesheet or script marked as essential, they stop drawing anything until it has downloaded and run. These are render-blocking resources, and they explain the classic symptom of staring at a blank white screen while the spinner turns, then having the whole page appear at once.

The fix is to load only truly critical styles up front and defer everything else until after the first paint. This one usually does need a developer, because deciding what is safe to defer requires understanding what each resource does. Done wrong, it breaks the layout. Done right, the page appears to load in half the time even when total weight has barely changed.

Cause 6: A bloated theme carrying features you never use

Multipurpose themes and page builders sell on flexibility: sliders, portfolios, shop layouts, animation libraries, all ready to switch on. The cost is that much of that machinery loads on every page whether you use it or not. We regularly audit sites where the theme alone ships more code than the entire rest of the page.

You cannot easily trim a theme from its settings screen; the bloat is structural. Child-theme surgery helps at the margins, but if a heavy theme is your main problem, the honest answer is often a leaner rebuild, which is exactly the situation our website rebuild service exists for. Sites rebuilt on a lean foundation typically carry a fraction of the code weight.

Cause 7: Third-party embeds you forgot were there

An embedded map, a video player, a social feed, a review widget: each one pulls in code from another company's servers, on their schedule, at their size. A single embedded map can weigh more than the rest of your contact page combined. And because embeds are pasted in once and forgotten, nobody ever goes back to question them.

Walk through your key pages and list every embedded element. For each, ask whether a lighter substitute would do: a static image of the map that links out, a video thumbnail that only loads the player on click, review scores quoted as text with a link to the source. Visitors get the same information; the page stops paying rent to third parties on every load.

Cause 8: No CDN, so distance slows every request

If your site is hosted on one server in one location, every visitor's requests travel to that machine and back, however far away they are. A content delivery network, or CDN, stores copies of your files in data centres around the world so each visitor is served from somewhere nearby. Without one, distance quietly taxes every file on every page.

For a UK service business with purely local customers, this cause matters less than the others, but it still helps because CDNs also handle traffic spikes and compress files in transit. Entry-level CDN plans are free or cheap, and many hosts now include one. Switching one on is usually an afternoon of DNS settings rather than a development project.

Cause 9: Unoptimised fonts that hide your text

Custom fonts are downloaded files like any other, and handled carelessly they cause two problems: invisible text while the font loads, and a visible jolt when the fallback font is swapped out. Sites loading five weights of two typefaces, plus an icon font used for three icons, are paying a heavy price for a subtle design decision.

The fixes are well documented and mostly mechanical: limit yourself to the weights you actually use, host the font files yourself, preload the most important one, and tell the browser to show fallback text immediately while the real font arrives. A developer can typically sort a site's font loading in a day or less, and the result is text that simply appears, instantly.

Cause 10: Redirect chains adding a toll at every step

A redirect is an instruction saying "the page you want has moved, look here instead". One is fine. The problem is chains: the old address redirects to the new address, which redirects to the secure version, which redirects to the version with a trailing slash. Each hop is a full round trip to the server before any content loads, and on mobile connections each hop can cost hundreds of milliseconds.

Chains accumulate through history: a domain change here, a restructure there, an HTTPS migration on top. You can spot them with any free redirect-checker tool by testing your most-visited addresses. The fix is pointing every old address directly at its final destination in one hop, which is fiddly but well within a competent developer's routine work.

How to test your website speed properly

Do not diagnose from your own browser. Your machine has the site cached, your connection is probably better than your average visitor's, and your impression is biased by familiarity. Use PageSpeed Insights, Google's free tool, which tests any address you give it and reports two kinds of evidence.

The first is field data: measurements from real Chrome users who visited your site over the last 28 days. This is the truth, because it reflects actual devices and connections. The second is lab data: a fresh test run on a simulated mid-range phone, which comes with a diagnostic list of specific problems found, mapping closely onto the ten causes above. Field data tells you whether you have a problem; lab data tells you what is causing it. Test your three most-visited pages, not just the homepage, and test the mobile results first.

Which speed fixes are an afternoon, and which are structural?

Not all ten causes cost the same to fix. This is how they break down across the sites we audit:

Cause	How to spot it	Difficulty of fix
Oversized images	PageSpeed flags "properly size images" or "serve images in next-gen formats"	Easy: an afternoon with a compression tool or plugin
Too many plugins and scripts	Long "reduce unused JavaScript" list; plugin count above 20	Easy to moderate: an audit and a cull
Cheap hosting	Initial server response time above 600 milliseconds	Moderate: a plan upgrade or migration
No caching	Repeat visits load as slowly as first visits	Easy: settings or a plugin, configured carefully
Render-blocking resources	Blank screen, then the page appears all at once	Hard: developer work on load order
Bloated theme	Slow everywhere despite other fixes; heavy page builder in use	Hard: often a rebuild decision
Third-party embeds	Maps, feeds, and widgets dominate the network waterfall	Easy: replace with lighter substitutes
No CDN	Visitors far from your server report worse speeds	Easy to moderate: DNS settings, often free
Unoptimised fonts	Invisible text or a visible font swap while loading	Moderate: a day of developer time
Redirect chains	Redirect checker shows multiple hops to the final page	Moderate: fiddly but routine

Start with the easy column. Images, embeds, caching, and a plugin cull can usually ship inside a week without a developer, and together they often move the numbers visibly. Then look at hosting, fonts, and redirects. Only after that should you weigh the structural pair, render-blocking resources and theme bloat, because those are decisions about the build itself rather than tweaks to it.

Speed is worth this effort for a blunt commercial reason: a slow site loses visitors before it gets the chance to persuade them, which is why slowness sits high on our list of reasons websites fail to convert. If you want a scored starting point that covers speed alongside clarity, trust, and everything else, run the free audit and see where your site stands in about a minute.

Frequently asked questions