Why your website is slow

The three numbers

Everything else is commentary on these, so it is worth knowing what they are before anyone quotes you.

• LCP, how long until the largest thing on screen has drawn. Target under 2.5 seconds.
• INP, how long the page takes to respond after somebody interacts with it. Target under 200 milliseconds. It replaced FID in 2024 and is stricter, because it measures every interaction rather than only the first.
• CLS, how much the layout jumps while loading. Target under 0.1.

They matter for two different reasons and both are real. They are part of how a search engine assesses a page, and separately, they are a reasonable proxy for whether the thing is unpleasant to use.

Note what is not on the list: a score out of a hundred. Testing tools produce one and everybody fixates on it, but it is a summary of a simulated run on a simulated device. The numbers above, measured on your actual visitors, are the ones that describe your site. A tool showing 94 while real visitors experience something slow is not a contradiction; it means the simulation had a better connection than your customers do.

Where the weight actually is

In rough order of how often it turns out to be the answer.

Images. Almost always, and almost always by a wide margin. A photograph exported straight from a camera or a stock library, uploaded at full size and scaled down by the browser, is the single most common cause of a slow page on the web. The visitor downloads all of it and sees a fraction.

Third-party scripts. Analytics, chat widgets, heat maps, consent banners, tracking pixels, embedded video players, fonts fetched from somebody else's domain. Each was added by somebody with a good reason and none of them were removed. They also fail unpredictably, because you are waiting on servers you do not control.

The platform and its plugins. Every layer added has to load. A site with twenty plugins is running twenty other people's code on every page view, most of it for a feature used on one page.

Fonts. Frequently overlooked and easy to fix. Four weights of two families, fetched from an external host, is a lot of waiting for text that could have started rendering immediately.

The code itself. Genuinely the cause sometimes, and much rarer than the four above.

Why the site feels slow when the numbers look fine

This is the case that confuses people and it is worth naming, because it has a different cause and a different fix.

Download size is not the same as responsiveness. A page can arrive quickly and still feel stuck, because the browser is busy running code and cannot respond to a tap or a scroll. That is what INP measures and why it was introduced.

The usual sources are the same third-party scripts as above, all initialising at once, plus anything doing heavy work the moment the page loads rather than when it is needed.

The practical test costs nothing: open your site on a mid-range phone, on mobile data, and try to scroll while it is still loading. If scrolling stutters, you have an INP problem, and no amount of image compression will fix it.

Which fixes are worth the money

In order of return, which is not the order people usually attempt.

• Fix the images. Correct dimensions, modern format, and defer the ones below the fold. Cheap, mechanical, and usually the largest single improvement available.
• Audit the third-party scripts and remove what nobody uses. Costs an afternoon and a couple of awkward conversations about whose tool it is. Frequently the second biggest win.
• Serve the fonts from your own domain and load fewer weights. Small, permanent, and it removes a dependency on somebody else's uptime.
• Then look at the platform. If the site is carrying twenty plugins for three features, this is real work with a real return, and it is the point where the cost stops being trivial.
• A rebuild. Sometimes correct, and it should be the conclusion of a diagnosis rather than the opening proposal. If somebody suggests it before measuring, they are selling a project.

What we do on our own site, since it is checkable

It would be poor form to write this without publishing our own numbers.

This site runs a complete three-dimensional scene on its homepage: a modelled Earth, an orbit, an astronaut, type built as geometry. A first visit downloads 186 KB of compressed JavaScript across six files, plus 33 KB of HTML that travels as under 7 KB, plus 252 KB of typefaces served from our own domain rather than fetched from anyone else.

No third-party scripts on the critical path. No fonts from an external host. The scene stops rendering when nobody is looking at it.

You can check all of it in about thirty seconds with the developer tools in your browser. We would rather you did that than took the paragraph on trust, and the same test works on anyone else you are considering.

How to tell a diagnosis from a sales pitch

Four things a real answer contains.

It starts with field data if any exists — what your actual visitors experienced — rather than only a simulated test run.

It names which of the causes above applies to you, with sizes. "Your hero image is 4.2 MB" is a diagnosis. "Your site needs speeding up" is not.

It separates the cheap fixes from the expensive ones and tells you what each is worth, so you can stop after the cheap ones if the numbers land where you need them.

It is willing to conclude that the speed is fine and something else is the problem. Sites lose enquiries for reasons that have nothing to do with milliseconds, and a supplier who only sells speed will only ever find speed.

When speed is not your problem

Worth saying, because performance work is easy to sell and easy to over-buy.

If your site loads in reasonable time and enquiries are still not arriving, faster will not fix it. Visitors who understand what you do and want it will wait a second longer. Visitors who cannot tell what you do leave instantly on the fastest site ever built.

And if almost nobody is visiting at all, this is a demand problem wearing a performance costume. Different budget, different conversation.