How fast does your website actually need to be

Nobody asks me “how fast is my site”. They ask “is it fast enough?”. That's the better question, except the answer depends on what you're comparing it against.

So I'll start with numbers I measured myself, on real sites, the same afternoon, with the same tools. The official thresholds come right after. On its own, a threshold tells you nothing. You need both to know where you stand.

Three sites, the same measurement

Site C isn't badly made. It's a serious company site, good content, five languages, the SEO side sorted. I maintain it myself and I have no intention of rebuilding it. It's just built on a stack of plugins, and the stack gets paid for on every single visit.

The gap between 286 and 1,007 milliseconds isn't a technical subtlety. It's three and a half times.

What the thresholds actually are

Google looks at three things and calls them Core Web Vitals. These are the values it uses to sort sites into good, needs work and poor.

Two things the table doesn't show.

The threshold has to be met by 75% of visits, not on average. If three quarters of people get the page under 2.5 seconds, you're good. An average can fool you, because a handful of visitors on fibre with a good computer make it look better than it is.

The second: INP replaced FID in March 2024. If you're reading an older guide that talks about First Input Delay, the guide is out of date. INP is stricter, because it measures every interaction in the visit, not just the first.

The score you see isn't the score that counts

This is where people waste the most time, and it's the tool's fault, not theirs.

Put an address into PageSpeed Insights and you get two sets of numbers that look almost identical. At the top, field data: what your site's real visitors actually got over the last 28 days, collected by Chrome. Below it, lab data: one simulated load, on a mid-range phone, with the connection artificially slowed down.

Google uses the field data. The lab is for diagnosis, so you can see what is slowing the page down.

Three confusions come out of this, and I see all three often:

A new site, or one with little traffic, showing no field data at all. That isn't an error. You simply don't have enough visitors for a statistic, so Google shows you the lab only.

You fixed it yesterday and the score is the same. Of course it is. The window is 28 days and it rolls, so yesterday's fix goes in with the weight of one day out of 28. It takes a few weeks to see the full move.

You tested on a computer and it came out green. Test on mobile. That's where the traffic is, that's where the bad connection is, and that's where it breaks.

Why my site is slow when the hosting is good

Here's what surprised me about site C. Time to the server's first response: 14 milliseconds. The best of all three. Web.dev puts the boundary at 800 milliseconds, so there is no room to do better there.

And still the page isn't fully visible until three seconds in.

This is the situation most slow sites in Romania are in. The owner complains about speed, somebody sells him more expensive hosting, nothing changes, and he's left with the impression that “that's just how the internet is”. The hosting was never the problem. It was the 59 stylesheets and the 711 KB of JavaScript the browser has to download, read and execute before it shows you anything.

The good part is that this gets solved without moving the site and without rebuilding it. The less good part is that there's barely anyone out there selling it to you, because it looks bad on a quote. “Premium SSD hosting” sells itself. “I took out 40 pointless requests” doesn't.

Where the 59 stylesheets come from

Visual builders of the Elementor kind work in modules. You drop in a button, the button styles load. You drop in a carousel, the carousel styles arrive. Each piece is small. The problem is that the browser has to ask for them one at a time, and every request has its own fixed cost, however small the file is.

Same with plugins. A contact form plugin usually loads all of its code on every page of the site, including the ones with no form on them. It isn't bad faith. It's how they're written so they work anywhere straight away, with no configuration.

Install ten plugins and you have a site carrying the code of ten different products, of which you use a fraction.

What it costs, in money

I can't tell you what you're losing. I can tell you what other people have measured at scale.

Google and Deloitte published a study in 2020 called “Milliseconds Make Millions”, on data from close to 40 brands. An improvement of one tenth of a second in mobile load time brought on average 8.4% more conversions in retail and an average basket 9.2% larger.

Earlier, in 2017, Google published the number that gets quoted most: when load time goes from one second to three, the probability that the person leaves without doing anything rises by 32%. From one second to five, by 90%.

Treat those as averages across thousands of sites, not as a promise for yours. If you sell a product nobody else has, people will wait for you. If you sell something available in ten other places, they won't.

And if you run an online store, the cost adds up at every step. Category, product, basket, checkout. You're not losing a curious visitor, you're losing someone who had already decided to buy.

How you check your own site in five minutes

No paid tools, and no need to know how to code.

Open PageSpeed Insights, put in the address, choose Mobile. If the field data section appears, that's your real mark. If it doesn't, you don't have enough visitors and you're left with the lab.

Then open the site in Chrome, press F12 and go to the Network tab. Reload with Ctrl and Shift and R, so it doesn't pull from the browser's memory. At the bottom, in the status bar, it says how many requests were made and how many kilobytes were transferred.

What you compare that against: a marketing site built cleanly stays under 40 requests and under a megabyte transferred. Over 100 requests, you have a real problem, not a theoretical one. These aren't official thresholds, they're my own benchmarks, from the sites I've measured.

What you fix, in order

Measure before you buy anything. A website audit tells you whether the problem is the server, the images or the code. With no measurement, optimisation is a lottery and you're paying for luck.

Fix what the measurement turned up, in order of impact. Usually it's three or four things that make 80% of the difference, not thirty. That's what I do in speed optimisation: I take the list, work through it in order, and measure again, so you see the difference in numbers.

And then keep it that way. A site optimised today gets heavy on its own within six months, as you add content, plugins and tracking scripts. That's why maintenance includes performance checks, not only security updates.

What not to do

Don't chase 100 out of 100. The score is a diagnostic instrument, not a target. I've seen sites at 98 that feel slow and sites at 76 that fly. What counts is how long it takes until the person sees what they came to see.

Don't rebuild the site for speed alone. If you have good content, good rankings and customers coming in, starting over from scratch is an expensive decision with real risk. Most of the time, optimising what you already have recovers the greater part of the difference. Site C in the table is exactly that case, and that's why I'm leaving it on WordPress.

But if you are starting from scratch anyway, do it properly the first time. A new site on clean code starts at 29 requests and a single stylesheet, and stays there. That's far cheaper than repairing in two years what you break now.

Two questions I get a lot

Does speed matter for ranking in Google?

Yes, but less than you think. Core Web Vitals is a ranking signal, not the main one. Between two pages with equally good content, the fast one wins. A fast page with weak content doesn't beat a slow page with better content. What speed gives you on top is something more direct: the people who stay on the page instead of going back to the results.

How long should a company site take to load?

Under 2.5 seconds until the main content appears, on a phone, for three quarters of visitors. That's the threshold Google goes by. If you want a more ambitious target, under a second is achievable for a marketing site and it feels instant.

The numbers can be checked

I'm not asking you to take my word for it. Site A in the table is the EGEA steel scaffolding catalogue. Open it, press F12, look at the Network tab and count for yourself. That's why I put the numbers on the work page, because they can be checked.

If you don't know where yours stands, write to me and I'll look. I'll tell you what I found even if the answer is “there's nothing to fix, leave it alone”.