Why is my website slow? Why speed matters, how to measure it, how to fix it
A slow website drives visitors away and weakens its search visibility. We measure speed with Google’s Core Web Vitals: the main content should load (LCP) within 2.5 seconds, the page should respond to interaction (INP) within 200 milliseconds, and layout shift (CLS) should stay at or below 0.1. PageSpeed Insights and Search Console are enough to measure them. The usual culprits are large images, heavy themes and plugins, third-party scripts or a slow server. Below we take each in turn, with its fix.
Why website speed matters
Visitors do not wait. On a phone, on a weak connection, if the page stays blank for a few seconds, they press the back button. That person might have been your client.
Speed is also a sign of care. A menu that sticks, a button that jumps as the page loads, a form that appears late — each quietly raises the question: does this business take care over its work?
Speed matters in search too. Google uses page experience as one of its ranking signals. On its own it will not lift a page to the top; content always comes first. But amongst pages with similar content, a slow one can fall behind. Speed is only one item on our technical SEO checklist — but it is the one people feel most easily.
What are Core Web Vitals, and what are the thresholds?
Core Web Vitals are the three core metrics Google uses to measure page experience. The thresholds are published in Google’s documentation on web.dev. For a page to count as “good”, at least 75 per cent of visits must stay within these limits.
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP — Largest Contentful Paint | How long the largest element on the page (often the main image or headline) takes to appear | 2.5 s or less | 2.5–4 s | Over 4 s |
| INP — Interaction to Next Paint | How long the page takes to respond visually to a click or tap | 200 ms or less | 200–500 ms | Over 500 ms |
| CLS — Cumulative Layout Shift | How much elements move unexpectedly whilst the page loads | 0.1 or less | 0.1–0.25 | Over 0.25 |
INP replaced FID in 2024. FID looked only at the delay of the first interaction; INP takes every interaction during the visit into account. That is why sites with a heavy script load stumble on INP more easily.
How to measure speed
Lab data and field data
There are two kinds of measurement, and they tell you different things.
Lab data is the page loaded in a controlled environment, assuming a particular device and connection. Lighthouse measures this way. It is quick, repeatable and shows the cause of a problem — but it is not a real visitor’s experience.
Field data is collected from real visitors’ Chrome browsers. This is the data Google uses in its assessment. Sites without enough traffic may have no field data at all.
The two can disagree. A page that looks fine in the lab can be slow for visitors on older phones. We look at field data to decide, and at lab data to find the cause.
PageSpeed Insights
PageSpeed Insights is a free tool: you enter an address. At the top it shows field data, if there is any; below, a lab measurement made with Lighthouse. Look at the mobile and desktop results separately — most problems show up on mobile.
The suggestions at the bottom of the report list, one by one, which images or scripts are adding weight. Starting there is usually enough.
The Core Web Vitals report in Search Console
The Core Web Vitals report in Search Console looks not at individual pages but at groups of similar pages. It shows which group of addresses is weak on which metric. After a fix, “Validate fix” lets you follow the result. Because field data accumulates over time, an improvement takes a few weeks to show in the report.
What to watch when measuring
Do not trust a single measurement. Lighthouse results vary with network conditions and the server’s load at that moment. Measuring the same page several times and looking at the average is sounder.
Do not measure only the home page. Most visitors arrive from search directly on a service page or an article. Measure your most-visited pages one by one.
Write the measurements down. The date, the page, the device type and the three metrics are enough. Only then can you see what improved or broke after a change. We repeat measurements on the same pages before and after launch, and share the results with you.
Why does a site slow down?
Slowness rarely has a single cause. But the causes we meet most often are well known.
- Large images. A photograph that will appear a few hundred pixels wide on a phone is uploaded at the size it came out of the camera. This is the most common problem, and the easiest to fix.
- Heavy themes and plugins. Off-the-shelf themes load the code for dozens of features you do not use, on every page. Every plugin adds its own scripts and styles. We discuss this in detail in WordPress or a custom-built website?
- Third-party scripts. Chat bubbles, ad and tracking code, embedded videos, social media feeds. Each loads from someone else’s server and sits outside your control. They are the leading source of INP problems.
- A slow server. If the server takes a long time to answer before the page even starts loading, other improvements can only go so far.
- No caching. If the page is generated from scratch on every visit, and the browser downloads the same files again and again, the site is slower than it needs to be.
- Fonts. Many typefaces or weights, fonts loaded from another server, and text that stays invisible until the font arrives all affect both LCP and CLS.
How to fix each problem
The table below sets out the most common problems with their symptoms and fixes.
| Problem | Symptom | Fix |
|---|---|---|
| Large images | High LCP; page weight measured in megabytes | Resize images to screen size, use WebP or AVIF, lazy-load those below the fold |
| Images without set dimensions | High CLS; text slides down as the page loads | Give images a width and height, reserve their space |
| Heavy themes and plugins | ”Unused code” warnings; many files on every page | Remove unnecessary plugins, strip unused styles and scripts |
| Third-party scripts | High INP; slow response to clicks | Remove those not truly needed; delay the rest or load them on interaction |
| Slow server | Long time to first byte; every page starts late | Improve the server, generate static pages, use a CDN |
| No caching | Pages slow even on repeat visits | Set up page and file caching, send correct cache headers |
| Font load | Text appears late, or shifts once loaded | Use fewer fonts, serve them from your own server, preload the key font |
Working in order pays off: images first, then third-party scripts, then theme and server. On most sites, the first two steps make the biggest difference.
When is rebuilding wiser than patching?
Not every slow site needs rebuilding. Compressing images and removing a few plugins is often enough.
But sometimes the patches pile on top of one another and the problem keeps coming back. These signs suggest that a rebuild may make more sense:
- The source of the speed problem is the theme itself; it will not improve without changing the theme.
- Removing one plugin breaks something else; nobody is sure which part depends on what.
- Speed drops again after every update.
- The site is already dated in design and content; fixing speed would not fix what is really missing.
If you do decide to rebuild, protecting the old site’s search visibility is a separate job: old addresses have to be redirected correctly to the new ones. We go through it step by step in redesigning a website without losing SEO.
We build our own sites, and the sites we make for clients, as light static pages. We do not use off-the-shelf themes. Before launch we measure every page with Lighthouse, aiming for pages that open quickly. If you are considering a new site, we describe our approach on our web design and development page.
Does speed stay fixed once it is fixed?
No. Speed wears away over time.
An uncompressed image is added to a new page. A tracking code goes in for a campaign and stays after the campaign ends. A plugin updates and grows heavier. A few months later, the repaired site is slow again.
That is why we treat speed as part of maintenance: measuring at regular intervals, watching the Search Console reports, checking newly added images and scripts. We describe what maintenance involves in why website maintenance matters.
Frequently asked questions
My PageSpeed score is low, but the site feels fast to me. Which should I believe?
Both, for different purposes. You probably open the site on a fast connection and a capable device; some of your visitors do not. The lab score shows the causes; for the real verdict, look at the field data in Search Console.
Does the speed score decide rankings directly?
No. The Lighthouse score is not a ranking signal. What Google uses is Core Web Vitals data from real visitors — and even that does not replace content quality. But amongst similar pages, it can make a difference.
Is installing a speed plugin enough?
Sometimes it helps in the short term, by taking on jobs such as caching and file minification. But if the cause is large images or heavy scripts, a plugin will not remove them. And it is a plugin itself, which can clash with others.
How long does a speed fix take?
It depends on the scope. Optimising images and removing unnecessary scripts is often quick. Problems rooted in the theme or the server need more work. We measure first, rank the causes, and then share a written plan.
If you would like to measure your site’s speed together and decide what to fix first, see our SEO and maintenance page or write to us. We reply within two working days.