Why your website is slow — and what it's costing you

Nobody complains that your website is slow. They just leave, and you never find out. That is what makes speed such an easy problem to ignore — there is no angry email, no bad review, just a conversion rate that is quietly lower than it should be and no obvious reason why.

So let’s be specific about what “slow” means, which numbers actually matter, and what usually causes it.

The three numbers Google cares about

Google measures real visits to your site through what it calls Core Web Vitals. There are three, and they measure genuinely different things.

LCP — Largest Contentful Paint. How long until the biggest thing on screen finishes loading. Usually your hero image or headline. This is the closest thing to “how long until the page looks ready”. Under 2.5 seconds is good.

INP — Interaction to Next Paint. When someone taps a button, how long before anything visibly happens. This is the one that makes a site feel broken rather than just slow — the page looks finished, you tap, nothing responds. Under 200 milliseconds is good.

CLS — Cumulative Layout Shift. How much the page jumps around as it loads. Everyone has tapped the wrong thing because an ad or a font loaded late and shoved the button down. Under 0.1 is good.

You can see your own numbers in Google Search Console under Core Web Vitals. That report uses data from real Chrome users on your site, which matters — more on that below.

The number that usually explains a slow site

There is a fourth number, and in our experience it is the one that explains most bad scores: Total Blocking Time. It measures how long the browser’s main thread was stuck doing JavaScript work and unable to respond to the person using the page.

High blocking time is what makes a phone feel like it is chewing on your site. It is also the most common thing we find on sites built with heavy page builders, because a builder ships the JavaScript for every feature it could render, not just the ones you used.

What we found on our own site

This site is not a rebuilt template — we wrote it, so we can be specific.

When we ran a mobile performance pass, the obvious suspect was the 3D animation on the homepage. It felt heavy, so it must be the problem. We profiled it before touching anything, and the trace said otherwise: the WebGL work never appeared in the top scripts at all. The real cost was the scroll-animation library and, worse, two animation triggers that ran a calculation on every single scroll tick and created a new animation each time.

If we had trusted the hunch instead of the measurement, we would have stripped out the design for almost no gain and left the actual problem untouched.

What we changed:

• Phones skip the 3D layers entirely — a CSS gradient stands in, and on a small screen almost nobody can tell.
• The two per-scroll-tick animation triggers are disabled on phones.
• Touch devices skip the magnetic buttons and the 3D card tilt, both of which are mouse-only anyway and each force the browser to keep an extra compositing layer alive.
• The intro animation runs at half length on phones, since nothing paints until it lifts.

The result, measured on real PageSpeed Insights and not a local tool: Total Blocking Time fell from 550ms to 180ms and Speed Index from 5.3s to 3.6s. Desktop was left completely untouched.

An honest warning about the score

Here is the part most agencies leave out: the PageSpeed score is noisy. On the same unchanged build, minutes apart, we have recorded 86, 88, 95 and 97 on mobile. Same code, same site, nine-point spread.

So if someone shows you a single screenshot of a 98 and calls it proof, that is a screenshot, not evidence. Judge a performance change by the specific metric it targeted, measured several times — and ultimately by the Core Web Vitals field data in Search Console, which comes from real visitors rather than one simulated phone in a data centre.

The usual causes, roughly in order

Most slow sites we are handed are slow for the same handful of reasons:

1. A page builder doing too much. The convenience is real, but so is the JavaScript and CSS shipped for features you never used.
2. Images straight from the camera. A 4MB photo scaled down in the browser is still a 4MB download. Correct dimensions, modern format, lazy loading below the fold.
3. Plugin sprawl. Every plugin adds requests and queries. Sites routinely run twenty when they need six.
4. Cheap shared hosting. If the server takes 1.5 seconds to send the first byte, nothing you do in the browser can win that back.
5. No caching or CDN. Regenerating the same page for every visitor, served from one location to a global audience.
6. Render-blocking fonts and scripts in the head. The browser stops and waits. Fonts especially — they can be loaded without blocking the first paint.

What to do about it, in order

Start by measuring, not guessing. Run PageSpeed Insights on your most important page, on mobile, a few times. Then check Search Console’s Core Web Vitals report for what real visitors experience.

Then fix in this order, because it is roughly the order of impact per hour spent: hosting and caching first, then images, then JavaScript, then fonts and the rest. Re-measure after each one, so you know which change did what.

If the site is built on something that fundamentally cannot get fast — a builder that emits unusable markup, for instance — no amount of tuning will fix it, and it is cheaper to be told that honestly than to pay for six months of optimisation retainer against a losing position.

We do this as part of every web development build, and as the first step of any SEO engagement, because publishing content onto a slow site is spending money to be ignored.