Slow website: what to check beyond your PageSpeed score

A score isn't a diagnosis. A site can have a mediocre score and be perfectly usable, and it can have a high one while staying slow at the exact moment that matters: when someone opens a product page from their phone, away from home, on a shaky connection. To know whether slowness is actually getting in visitors' way, you have to look at the pages they use, on the devices they use.

The useful question isn't "what score do we get," but "where and when are people waiting, and what are they waiting for."

Two different measures: the simulated test and real experience

Tools do two things that often get confused, and the confusion leads to working on the wrong problem.

The two measures are used together, in this order: real experience tells you whether it's worth addressing, the simulated test tells you where to start. Looking only at the second leads to chasing a score; looking only at the first leaves you without knowing what to touch.

What weighs it down: images, video, scripts, and third-party components

On most business websites, slowness doesn't come from badly written code, but from things added one at a time and never removed.

• Images uploaded at their original size and shrunk by the browser: the visitor downloads a print-sized photo to see it the size of a postage stamp.
• Embedded videos that start downloading when the page opens, even if no one will ever press play.
• Third-party components: chat, consent banner, analytics, maps, review widgets. Each one seems light, and together they decide when the page becomes usable.
• Fonts: if text waits for the font before appearing, you're looking at a blank page while the content has already arrived.
• Features installed for a past need and never removed, which keep loading on every page.

An exercise anyone can do: open a page and list everything that isn't your content. For each item, ask who wanted it and what happens if you remove it. Often the answer is: no one notices.

Three moments to look at, not one

"Slow" describes different experiences, and each is fixed in a different way.

1. Opening: how long before the main content appears — the thing the visitor came for. Not the first pixel, not the menu: the content.
2. Response: when you tap a button or open a menu, how long before something happens. A page that appears instantly but doesn't respond feels broken, not slow.
3. Stability: how much the content shifts while it finishes loading. It's what people describe as "the site jumps around": you go to tap one item and a different one lands under your finger.

The third is the most overlooked and often the most annoying, because it doesn't waste time: it causes mistakes.

A performance log across three pages

A measurement is only useful if it's repeatable. Choose three pages that represent different uses, state the conditions, and log before and after every change, with the date. Changing the conditions between the two readings makes the comparison useless.

Next to each row, log the measured value and the date. The numbers aren't compared against other sites, but against your own from the previous time: it's the only comparison that tells you whether the change worked.

Priorities: remove first, then defer, then reduce

1. Remove what's no longer needed. It costs little and carries no risk.
2. Defer what's needed but not right away: a component that loads only when someone uses it doesn't weigh down the opening.
3. Reduce the weight of what remains, starting with images, which are almost always the biggest part.
4. Change how the site is built. This comes last because it's the only one that requires a project, and the first three have already delivered most of the result.

When slowness isn't the problem to solve

• If it's only slow from your office, suspect the internal network or the secure connection, not the site.
• If the time is spent before the browser receives anything, the problem is in the server or the function that builds the page: a catalog with a heavy search doesn't get fixed by compressing images.
• If the slow page is one almost no one visits, the fix is real but pointless.
• If the wait comes from something that's actually working, like a calculation or a configurator, you work on the wait itself: say that something is happening and how far along it is.

What this guide doesn't cover

This guide covers the technical experience: what makes the site tiring to use and how to measure it repeatably. It doesn't promise that a better score brings higher rankings or more contacts, because that's not how it works. The full checklist of checks to run before publishing a new site is a separate matter, as is diagnosing why requests aren't coming in.