Why Is My Website Slow? Causes and Fixes for a Slow Website

"Why is my website slow?" is a question business owners usually ask after someone has already complained. A customer says the site won't open on their phone, or PageSpeed Insights shows a red number. This guide covers what usually makes a business website slow, how to measure it properly, what you can fix yourself, and when a new site makes more sense.

If Core Web Vitals are new to you, start with the short introduction in our article on custom websites versus templates. Here we go deeper.

Measure properly first

Before fixing anything, you need to know what exactly is slow. The simplest tool is Google's PageSpeed Insights. Enter a URL and you get two very different results, which people often mix up.

Field data and lab data

Field data comes from real visitors. Google collects it from Chrome users who have opted in and publishes it through the Chrome UX Report (CrUX). PageSpeed Insights shows the last 28 days. It tells you how your site actually performs on your visitors' phones and networks.

Lab data comes from Lighthouse. It loads the page once on a simulated slower phone and network. That's where the familiar 0–100 score comes from.

Both have their place:

	Field data (CrUX)	Lab data (Lighthouse)
Source	real visitors, 28 days	one simulated load
Shows	whether the problem is real	why the problem happens
Use it for	deciding whether to fix	fixing and checking the fix
Limitation	may be missing on low-traffic sites	may not match real users

On a small business site, field data is often missing because there aren't enough visitors. Then all you have is the lab. That's normal; just remember that the lab score is an estimate, not your users' real experience.

If your site is in Google Search Console, you'll also find a Core Web Vitals report there, which groups similar pages and shows which ones have problems.

What good numbers look like

According to Google's guidance, 75% of visits should fall within these limits:

Metric	Good	Needs improvement	Poor
LCP	up to 2.5 s	2.5–4 s	over 4 s
INP	up to 200 ms	200–500 ms	over 500 ms
CLS	up to 0.1	0.1–0.25	over 0.25

The 75th percentile means visitors on slower phones count too. A site being fast on your laptop tells you very little.

Each metric points to a different cause. A slow LCP usually means the main image or heading reaches the screen late. A poor INP means too much JavaScript is keeping the browser busy. A high CLS means content jumps because images, ads or fonts had no space reserved.

The seven most common causes, and how to fix them

1. Unoptimised images

This is the most common cause and, luckily, the easiest to fix. The typical case: a photographer's full-size photo goes straight onto the page and the browser shrinks it to 400 pixels wide on a phone. The visitor downloads many times more than needed.

What to do:

• save images in a modern format (WebP or AVIF);
• serve the right size for each screen (srcset and sizes);
• give every image a width and height so the browser reserves space and content doesn't jump;
• lazy-load images below the fold (loading="lazy");
• don't lazy-load the page's main image. It should load first, with fetchpriority="high" if needed.

2. Page builders and plugins

WordPress page builders and many plugins load their own CSS and JavaScript on every page, including pages that don't use them. Each plugin looks harmless on its own; together they add hundreds of kilobytes.

What to do:

• go through your plugins and remove the ones nobody uses any more;
• check whether two plugins do the same job (two caching or two SEO plugins, for example);
• look at Lighthouse's "Reduce unused JavaScript" and "Reduce unused CSS" suggestions. They show where the extra code comes from.

If the whole site is built with a page builder, your options here are limited. More on that below.

3. Third-party scripts

Chat widget, analytics, ad pixels, cookie banner, social widgets, maps, YouTube embeds. Each loads code from another company's server, and that code runs on your page. They're a frequent cause of poor INP.

What to do:

• list every script on the site and ask of each one: does anyone actually use this data?
• remove old pixels from campaigns that ended long ago;
• load the chat widget only when a visitor clicks it. Until then, show a simple button that looks like the widget;
• the same goes for YouTube videos and maps: show an image and load the real thing on click;
• load analytics with async or defer so it doesn't block rendering.

4. Web fonts

Three font families, four weights each, plus an icon font is common. Every file is a separate request, and until the font arrives, text can be invisible or jump.

What to do:

• use fewer fonts and weights. Two families are usually enough;
• use WOFF2 and variable fonts where possible;
• host font files on your own server rather than a third party's;
• add font-display: swap so text is readable straight away;
• preload the main font.

5. Cheap hosting and no CDN

If the server responds slowly, nothing else helps. Google's guidance on TTFB treats 0.8 seconds or less as good, and that's before the browser can do anything at all.

What to do:

• turn on page caching so the server doesn't rebuild every page on every request;
• use a CDN that keeps files closer to the visitor;
• if the site is on shared hosting where one server runs hundreds of other sites, better hosting may be the cheapest fix.

6. Render-blocking JavaScript and CSS

When the page head has large scripts without defer or async, the browser waits for them to download and run before showing anything. The same applies to large CSS files.

What to do:

• add defer to scripts that don't need to run immediately;
• split large JavaScript into smaller pieces and load them only when needed;
• break up long JavaScript tasks (over 50 ms) so the browser can respond to clicks in between. This improves INP.

7. Video in the hero

A big background video on the first screen looks great, but it can weigh several megabytes and is often the LCP element itself.

What to do:

• show a lightweight poster image first and load the video after;
• compress the video properly and make a smaller version for phones;
• consider whether the video is needed on phones at all;
• respect the visitor's settings: people who have reduced motion turned on should see an image instead.

Quick checklist

You can run through this yourself before calling anyone:

• I ran PageSpeed Insights in mobile view and looked at field and lab data separately.
• I know which element is the LCP on my page (PageSpeed Insights shows it).
• The main image is WebP or AVIF and isn't lazy-loaded.
• Every image has a width and height.
• I removed plugins and scripts nobody uses.
• The chat widget and videos load only on click.
• I use no more than two font families.
• The site has caching and serves files from a CDN.

Fix or rebuild?

Fixing is almost always the first step. Cleaning up images, plugins and scripts often gets most of the gain and costs less than a new site.

A rebuild makes sense when:

• the platform itself caps the speed. For example, a page builder whose code you can't change, or a closed platform where you don't control the scripts;
• every fix breaks something else. Plugins depend on each other and nobody dares update any more;
• the site needs new content or design anyway. Then there's little point investing heavily in optimising old code;
• speed is tied directly to sales, such as a shop where much of the traffic comes from phones.

A new site isn't automatically fast. A custom site can be slow too if too much goes into it. Our concept site Lõke, a made-up restaurant built as a demo rather than for a real client, has plenty of motion and WebGL. Lighthouse still scores it 98 to 100, because the heavy parts load only when needed. Speed comes from what you leave out, not from the tool.

If you're weighing a template against a custom build, we've covered that choice in a separate article on custom websites versus templates.

Summary

A slow website is rarely the result of one big mistake. Usually it's the sum of many small ones: oversized images, forgotten plugins, third-party scripts and fonts. Measure properly first, separate real-user data from lab results, and fix the highest-impact items first. A rebuild makes sense when the platform itself is the obstacle.

You can check our own work on your phone and in PageSpeed Insights in our work. If your website is slow and you're not sure where to start, get in touch. We'll look at the site and tell you honestly whether fixing it is enough or it's time for a new one.