Why is my website slow? 5 common causes and how to fix them

Site speed doesn’t just feel slow or fast; it measurably moves conversion rate. A study commissioned by Google and conducted by Deloitte and 55, covering over 30 million user sessions across 37 retail, travel, and lead-generation sites, found that a 0.1-second improvement in mobile load time lifted retail conversion rates by 8.4% and average order value by 9.2% (Deloitte/Google, “Milliseconds Make Millions”, 2020). Speed problems aren’t just an annoyance. They’re a measurable revenue leak.

Most “why is my site slow” articles list generic causes (bad hosting, too many plugins, unoptimized images) and leave you to guess which one is actually yours. That’s not enough to act on. This guide covers five real causes, a quick way to confirm each one is the culprit on your site, and what to do about it once you know.

Key Takeaways

• Five causes account for most slow small business websites: unoptimized images, underpowered hosting, a bloated theme or too many plugins, render-blocking scripts, and no caching or CDN.
• Each cause has a specific, quick way to confirm it’s actually yours before you spend time fixing it.
• Image compression and plugin audits are DIY-friendly; render-blocking fixes and hosting migrations usually need a developer.
• If you’ve fixed all five and the site is still slow, that’s a sign of a platform ceiling, not a missing setting.

Cause	Quick way to confirm it’s yours	Fix
Unoptimized images	Large image files near the top of a speed-test waterfall	Resize, compress, use a modern format (WebP/AVIF)
Underpowered hosting	High Time to First Byte even on a simple page	Move to hosting built for your platform
Bloated theme or too many plugins	Long list of active plugins/apps touching every page	Remove unused plugins, consolidate overlapping tools
Render-blocking scripts/CSS	Lighthouse flags “eliminate render-blocking resources”	Defer/async scripts, inline critical CSS (developer task)
No caching or CDN	Repeat visits aren’t faster; slow from distant locations	Enable page caching and a CDN

Unoptimized images

Oversized images are the single most common cause of a slow homepage, and usually the easiest to fix without touching any code.

How to confirm it’s yours: Run your homepage through a speed test tool such as PageSpeed Insights or GTmetrix and open the waterfall view. If you haven’t tested your site’s speed yet, here’s exactly how to run that test for free. If one or two image files near the top of the list are each several hundred kilobytes or more, images are a meaningful part of your load time.

It’s rarely the number of images that’s the problem: it’s their file size relative to how they’re displayed. A photo taken on a modern phone or downloaded straight from a stock library commonly runs several megabytes, uploaded at full camera resolution and then squeezed into a 400-pixel-wide thumbnail by CSS. The browser still downloads the whole file first, and it’s a widespread problem, not an edge case: in a sample of 11 million mobile pages, 79% weighed over 1MB, 53% over 2MB, and 23% over 4MB (Google Research / Webpagetest.org, January 2018, archived).

What to actually do:

• Resize before you upload. A hero image displayed at 1200px wide doesn’t need to be a 4000px source file. Resize to the actual display dimensions, not just the largest one on the page.
• Compress on top of resizing. Tools like Squoosh or TinyPNG, or your CMS’s built-in image optimizer, typically cut file size dramatically (often 60-80% as a rough rule of thumb) with no visible quality loss at web resolution.
• Use a modern format. WebP or AVIF files are routinely smaller than an equivalent JPEG at the same visual quality, and both now have broad browser support.
• Lazy-load everything below the fold. Images the visitor hasn’t scrolled to yet shouldn’t compete with above-the-fold content for bandwidth on page load.

The one exception: never lazy-load your hero or largest above-the-fold image. That delays the exact element your Largest Contentful Paint score is measuring, which actively hurts the metric it’s supposed to help.

Underpowered or oversold hosting

If your Time to First Byte (TTFB) is high even on a simple page with nothing else going on, the problem is likely your server, not your website’s code.

How to confirm it’s yours: Look at the TTFB figure in PageSpeed Insights or GTmetrix on a lightly-trafficked page. As a rough rule of thumb, a TTFB consistently above 600ms on a simple page is worth investigating; the further above that, the more likely the server itself (not the page) is the bottleneck, regardless of how fast the rest of the page is built.

Most small business sites launch on cheap shared hosting. One physical server splits its resources across hundreds or thousands of other websites. When traffic spikes on any of those neighboring sites, your server’s available capacity shrinks, and your TTFB rises with it, even though nothing about your own site changed.

When upgrading hosting genuinely fixes things:

• You’re on shared hosting and TTFB is consistently slow, even on cached, simple pages
• Traffic spikes correlate with your site slowing down
• You’re already on managed hosting built for your specific platform (managed WordPress hosting, for example) rather than generic shared hosting

When it doesn’t:

• Your TTFB is already fast but the page is still slow to fully load: that points to images, scripts, or render-blocking resources instead, not the server
• You’ve already upgraded once and speed didn’t meaningfully change: the bottleneck is somewhere else on this list, and a second hosting upgrade won’t touch it

Managed hosting built for your platform (managed WordPress hosting, for instance) is usually a better upgrade than a generic “more resources” shared hosting plan, because it’s tuned for the specific software stack your site runs on.

A bloated theme or too many plugins

Every plugin, app, or third-party script adds its own requests, database queries, and code (whether or not you notice it doing anything), and the effect is cumulative, not additive.

How to confirm it’s yours: Check your list of active plugins or apps. As a rough rule of thumb, more than around 15-20 on a standard business site, or several that touch every single page (a page builder, an SEO suite, a form plugin, an analytics script, a chat widget), is a reasonable trigger to investigate. If you can safely test in staging, disable plugins in batches and re-run a speed test after each batch to isolate which ones move the number.

Google’s own research on this makes the shape of the curve clear: as mobile page load time goes from 1 second to 10 seconds, the probability a visitor bounces rises 123% (Google/SOASTA Research, 2017, archived). Each additional plugin rarely adds a dramatic amount of load time on its own. It’s the accumulation across a dozen “just one more” additions that pushes a page from fast into this steepest part of the curve.

What to actually do:

• Remove plugins and apps you’re not actively using: an inactive plugin can still load assets on every page
• Consolidate overlapping tools (three plugins doing similar jobs) into one
• Check your theme or template for unused features that load assets sitewide regardless of whether a given page uses them
• Prioritize removing anything that loads its own JavaScript or CSS on every single page, not just the page it’s relevant to

Render-blocking scripts and CSS

If your page visibly “flashes” white or content pops in late after the layout has already appeared, resources are blocking the page from painting until they finish loading.

How to confirm it’s yours: Lighthouse and PageSpeed Insights flag this directly under “Eliminate render-blocking resources,” and will name the specific CSS or JavaScript files responsible.

By default, a browser stops rendering a page the moment it hits a <script> tag. It downloads and runs that script, then continues building the page. A stylesheet works the same way: the browser won’t paint anything until the CSS has finished downloading and parsing. Stack up a few of these in the wrong order, and the visitor stares at a blank or half-built page for longer than the content itself actually takes to prepare.

What a developer can do about it:

• Add defer or async to non-critical <script> tags so they load without blocking the initial render
• Inline the small amount of CSS needed for above-the-fold content, and load the rest of the stylesheet asynchronously
• Move non-essential scripts (chat widgets, marketing pixels, analytics) to load after the main content has rendered
• Combine and minify remaining CSS/JS files to reduce the number of blocking round-trips

This is the one cause on this list that’s rarely a good DIY project: moving a script tag without understanding what depends on load order can break functionality elsewhere on the page. It’s worth flagging to a developer specifically, by name, rather than asking for a generic “make it faster.” If you don’t already have a developer for this kind of fix, how you choose one matters more than it might seem.

No caching or CDN

Without caching, your server rebuilds the page from scratch for every single visitor. Without a content delivery network (CDN), every visitor is served from one physical server location, regardless of where they actually are.

How to confirm it’s yours: Load your homepage twice in a row and compare the load times. If the second (cached) load isn’t noticeably faster than the first, caching likely isn’t configured, or isn’t configured correctly. For the CDN half, check your load time from a location far from your server (a VPN, or a tool like GTmetrix’s multi-region test). A large gap between “nearby” and “far away” load times points to a missing or misconfigured CDN.

What each one actually does, in plain terms:

• Caching stores a ready-to-serve copy of a page after it’s built once, so the server can hand out that saved copy to the next visitor instead of rebuilding the entire page (including its database queries) from zero every time.
• A CDN keeps copies of your site’s static files (images, CSS, JavaScript) on servers spread across many physical locations, so a visitor in a different region from your host loads those files from a nearby copy instead of traveling the full distance to your original server.

Both are usually a configuration change rather than a rebuild: a caching plugin (for WordPress) or a platform-level caching setting, plus a CDN either bundled with your host or added separately (Cloudflare’s free tier covers most small business needs). Once set up correctly, both keep working in the background without ongoing maintenance.

When a fix isn’t enough

If you’ve addressed all five causes above and the site is still slow, or if the underlying platform itself is the constraint, incremental fixes have a ceiling, and that’s usually a sign the site needs a rebuild, not another patch.

This is the point most speed-focused content skips, because it’s not a satisfying answer to sell. But it’s an honest one. A site built on an outdated theme, a page builder generating bloated markup by design, or a platform that was never built for the scale you’re now asking of it will hit a point where compressing one more image or removing one more plugin stops moving the number. If you’ve worked through this guide in order and your load time hasn’t meaningfully improved, the constraint is architectural, not incremental.

That’s a different conversation than a speed audit, and a different budget question too: what a new website typically costs in the UK is worth knowing before you commit to either path.

The bottom line on a slow website

Five causes account for most slow small business websites: unoptimized images, underpowered hosting, a bloated theme or too many plugins, render-blocking scripts, and no caching or CDN. Each has its own quick confirmation test and its own fix. Incremental fixes have a ceiling: work through the causes above in order of ease, and if the site is still slow once you’ve addressed all five, that’s your signal a rebuild will do more than another patch.

If you haven’t already run a speed test, start there, then work through images and plugins first (they’re the fastest wins) before moving on to hosting and, if it comes to it, a rebuild.