Why Is My Website So Slow? The Usual Suspects

Most slow websites are slow for the same few reasons: oversized images, a heavy theme or too many plugins, hosting that responds sluggishly, and third-party scripts that block the page from showing. Run your page through PageSpeed Insights, find which of those is costing you the most time, and fix that one first.

Quick links

• How do I find out why my website is slow?
• Are images the problem?
• Is my theme or plugin stack to blame?
• Does my hosting make the site slow?
• Which scripts slow a page down?
• Which fixes are quick and which are structural?
• Why does a slow site cost rankings, citations and leads?
• When is a lighter stack the answer?
• FAQ

How do I find out why my website is slow?

Measure before you touch anything. Guessing is how people end up compressing images on a site whose real problem is a server that takes two seconds to reply.

Put your homepage and one inner page into PageSpeed Insights and test on mobile. Ignore the headline score for a minute. Read the three numbers Google treats as the standard for page experience. According to web.dev’s Core Web Vitals guidance, a good result is:

• Largest Contentful Paint (LCP): 2.5 seconds or less
• Interaction to Next Paint (INP): 200 milliseconds or less
• Cumulative Layout Shift (CLS): 0.1 or less

These are assessed at the 75th percentile of real visits, so one fast test on your office wifi proves very little. Google’s guide to optimising LCP is useful here because it splits load time into four parts: the wait for the server’s first byte, the delay before the main element starts loading, the time it takes to download, and the delay before it paints. Whichever part is fattest is where you start.

Are images the problem?

Very often, yes. The biggest thing on most pages is a photo, and photos are the easiest thing to get wrong.

The usual faults are an enormous file dropped straight from a camera, a JPEG where a modern format would be a fraction of the size, and one image served at full width to a phone. Then there is the sneakier one. Google’s guidance notes that if your main image is lazy-loaded, or only added to the page by JavaScript, the browser discovers it late and your LCP suffers for it.

What to do:

1. Convert to WebP or AVIF and resize to the largest width the layout actually uses.
2. Serve responsive sizes so phones do not download desktop files.
3. Lazy-load images below the fold, but never the main image at the top of the page.
4. Set width and height on every image so the layout does not jump as it loads.

That last one is the fix for most layout shift complaints, and it takes minutes.

Is my theme or plugin stack to blame?

If you are on WordPress, this is the second place to look. A multipurpose theme and a dozen plugins is the classic recipe for a slow site.

Here is the mechanism. Many themes and plugins load their own CSS and JavaScript on every page, whether that page uses them or not. A slider plugin that appears on one page still ships its code to all of them. A page builder wraps your content in several layers of markup. Add a contact form plugin, an SEO plugin, a popup plugin, an analytics plugin, and the browser is working through a lot of code before it can show a headline.

Check this with a ruthless audit:

• List every active plugin and write down what it is for. If you cannot say, it is a candidate for removal.
• Deactivate one at a time on a staging copy and retest. The ones that move the numbers are your offenders.
• Look for overlapping plugins doing the same job twice.
• Ask whether the theme’s built-in features, which you are not using, are still loading.

WordPress was a reasonable choice for a lot of sites. It becomes a less reasonable one when the site’s speed depends on how many plugins you resisted installing. We cover that trade-off properly in Astro vs WordPress for SEO and whether WordPress is good for SEO at all.

Does my hosting make the site slow?

It can, and no amount of image compression will fix it. If the server is slow to answer, every other step starts late.

Google’s LCP guidance puts a sizeable share of the ideal load time on that first wait, the time to first byte. Causes it lists include redirect chains, visitors a long way from the server, slow server processing and pages that cannot be cached. Cheap shared hosting tends to hit the third one. Your site sits on a server with hundreds of others, and when one gets busy, everyone queues.

Signs it is the host:

• PageSpeed reports a slow server response even on a nearly empty page.
• The site is fast at 3am and sluggish at 11am.
• Your admin area is slow as well as the public pages.

Fixes range from adding page caching and a content delivery network, which serves copies from servers near the visitor, to moving to a better plan. If you are weighing that up, our guide to what website hosting costs explains the tiers without the sales patter.

Which scripts slow a page down?

Third-party scripts. Chat widgets, tag managers, heatmaps, ad pixels, review badges and embedded videos each add a request, and often add work on the browser’s main thread.

This hits two things. Scripts in the head of the page that must run before anything renders hold up the whole paint. And scripts that run long tasks make the page feel frozen when someone taps a button, which is what INP measures.

You rarely need all of them. A sensible way through:

• Inventory what is firing. Open your tag manager and your page source. Most sites find tools nobody remembers adding.
• Remove what nobody reads. A heatmap report no one has opened since 2023 is costing you speed for nothing.
• Load the rest late. Defer anything that is not needed for the first view, and load chat widgets on interaction rather than on page load.
• Replace embeds with a facade. A video thumbnail that loads the player on click is much lighter than a live embed.

Which fixes are quick and which are structural?

Two groups. Quick fixes are things you can do in a day or two without changing the site’s foundations. Structural fixes change what the site is built on.

Quick fixes

• Compress and resize images, and fix the lazy-loading on the top image.
• Remove unused plugins, scripts and fonts.
• Turn on page caching and a content delivery network.
• Defer non-essential JavaScript.
• Set image dimensions to stop layout shift.

These typically move a poor score to a reasonable one. They are also where most agencies stop, because it is billable and it looks like progress.

Structural fixes

• Change the rendering approach. A site that builds every page in the browser from JavaScript will always be slower to show content than one that sends finished HTML.
• Replace the theme or page builder with something that outputs lean markup and loads only the code each page needs.
• Move off shared hosting onto infrastructure designed for static or server-rendered pages.
• Rebuild on a lighter framework. This is the biggest step and the one with the biggest ceiling.

If quick fixes get you to green and keep you there, stop. If you have done them all and the site is still sluggish, the problem is the foundation.

Why does a slow site cost rankings, citations and leads?

Because speed sits underneath everything else you pay for. A good page that loads badly wastes the effort that went into it.

On rankings, Google says it highly recommends good Core Web Vitals for success in Search, and that they align with what its core ranking systems seek to reward. It does not publish a weighting, and I would not oversell it. A fast page with nothing useful on it will not rank. But between two pages of similar quality, the one that behaves better has the edge.

On leads, the logic is plain. People leave pages that do not respond. You paid for the click, the ranking or the referral, and the visitor never saw the offer.

On AI citations, I will be careful, because I cannot point you to a published study showing speed alone earns a citation. What I can say is that answer engines pull from pages they can fetch and read quickly, and a site that stalls on the server or hides its content behind JavaScript is harder for them to read. If you want the wider picture, our AI search audit checklist covers crawler access in detail.

When is a lighter stack the answer?

When you have done the quick fixes and the site is still slow, or when staying fast means constantly fighting your own platform.

A heavy stack is slow by default and fast only with effort. A light one is the other way round. Static and server-rendered frameworks such as Astro ship finished HTML with very little JavaScript, which is why a decent build passes Core Web Vitals without heroics. It is the main reason we build the way we do, and why most B2B marketing sites we see would be better served by a leaner foundation than by another round of plugin tuning.

It is not always the answer. A small site that is slow because of three huge images does not need rebuilding, it needs an afternoon. The honest way to tell the difference is a proper diagnosis, which is what the audit below is for. If a rebuild does turn out to make sense, the website cost calculator gives you a realistic number before you speak to anyone.