The lab runs on a good connection
A test fired from a data centre on fibre is not the visitor standing in a shop with two bars of signal. Both numbers are real; only one of them is about your customers.
Sit and watch six seconds go past
You have read that a website should load in under three seconds. So has everybody. What almost nobody has done is stop and experience the difference, because on your own site you already know what is coming and you wait patiently for it. Press start below. Both timers run on the real clock, so the slow one genuinely takes as long as it says.
- Runs on the real clock
- No shortened counter
- A duration, not a case study
- Roughly 7 seconds of your life
What the difference actually feels like
Everyone nods along at “a few seconds slower”. Almost nobody has sat and watched it. These bars run on the real clock, so the slow one genuinely takes 6.2 seconds. Roughly what a bloated WordPress homepage does on 4G, and two and a half times Google’s threshold.
6.2 seconds0.0s
Blank screen
By four seconds a good share of visitors have gone. They do not tell you, and they do not come back.
0.9 seconds0.0s
Blank screen
Inside Google's 2.5 second threshold with room to spare. The panel at the foot of this page shows the real figure for the page you are on.
Two durations, not a case study. I am demonstrating six seconds, not claiming a particular client result. Your own numbers come from the £650 audit.
Why watching it matters more than reading the number
Because you are the worst possible judge of your own site’s speed. You visit it constantly, so it is cached in your browser and loads in a fraction of the time a stranger experiences. You also know exactly what is about to appear, which makes waiting for it feel like anticipation rather than friction. A first-time visitor has neither advantage and no reason to be patient.
The two figures above are chosen to sit either side of the threshold rather than taken from any particular website. That is worth being explicit about: this demonstrates what a duration feels like, and it is not a before-and-after from a client. I do not publish conversion uplift figures either, for the same reason. The link between speed and revenue is real at scale, and the number for your specific site is not knowable in advance.
What Google actually measures
Three metrics, specific thresholds, assessed on real visits rather than on a test you run when you are curious.
- LCP, largest contentful paint
- How long until the biggest thing on screen has actually rendered. Good is 2.5 seconds or under, and anything past 4 seconds is classed as poor. This is the one most sites fail and the one the comparison above is dramatising.
- INP, interaction to next paint
- How long the page takes to visibly respond when somebody taps or clicks. Good is 200 milliseconds or under, poor is past 500. It replaced first input delay in 2024 and it is stricter, because it measures every interaction rather than only the first.
- CLS, cumulative layout shift
- How much the page jumps about while it loads. Good is 0.1 or under. This is the one that makes somebody tap the wrong link because an advert loaded above the thing they were aiming at.
- What counts as passing
- All three at the good threshold, at the 75th percentile of real visits, on mobile. That last part is where most reassuring reports quietly fall apart: passing for three quarters of real phones is a different test from passing once on a fast laptop.
Why your report says you are fine when you are not
A score of 100 is not the goal
PageSpeed Insights gives a lab score out of 100 and it is genuinely useful for finding causes. It is not the thing Google uses to assess your site, and chasing the last few points is where speed budgets go to die.
Real visitor data lags
Field data in Search Console is a rolling window of real visits, so a fix you deploy today does not show up for weeks. That gap is why people conclude the work did nothing and stop.
How I test, and why it looks pessimistic
On a mid-range Android on a throttled connection, because that is the visitor who decides whether your Core Web Vitals pass. Not the newest iPhone on office wifi. The numbers this produces are worse than the ones you will get from a casual test, and they are the ones that match what Search Console eventually reports, which makes them the useful ones even though they are less pleasant to read.
An honest limit on all of this, including my own measurements: consecutive runs against an identical build on the same machine have varied by around a second on this site. So a single number is weak evidence and a difference of two hundred milliseconds between two runs means nothing at all. If somebody shows you a chart of daily speed scores wobbling about and calls it progress, that is mostly noise.
What to do if that felt uncomfortably familiar
Start by finding out where you actually stand, free. PageSpeed Insights will show both the lab score and, if you have enough traffic, the real visitor data. Look at the field data first and at mobile before desktop. Then work out which of the three metrics is failing, because the fixes have nothing in common with each other.
If you would rather have that written up properly, the Core Web Vitals audit is £650 fixed, in five working days, and it is yours to keep and hand to whoever maintains your site. Plenty of people take the report and do the work themselves, which is a perfectly good outcome. On a closed platform I will tell you where the ceiling is instead of billing you to hit it.
What to read next
The site scorer covers speed as one of twelve weighted questions, so it is the wider check. What a rebuild rather than a repair involves is on website design and build, and if the slowness is a WordPress theme with forty plugins behind it, that specific situation is on WordPress and WooCommerce. The other free tools are listed together.
Questions people actually ask
Are those two numbers from a real website?
No, and it matters that I say so. They are chosen to sit either side of the threshold so the difference is possible to feel. This demonstrates what a duration is like; it is not a before-and-after from a client. I do not publish conversion uplift figures either, because the link between speed and revenue is real at scale and the number for your specific site is not knowable in advance.
Why does my site feel fast to me when the report says otherwise?
Because you are the worst available judge of it. Your browser has the whole thing cached, so you get a version no stranger ever sees, and you know exactly what is about to appear, which turns waiting into anticipation rather than friction. A first-time visitor has neither advantage and no reason to be patient with you.
How do I find out my real numbers without paying anyone?
PageSpeed Insights, free, and look at the field data rather than the lab score if you have enough traffic for it to appear. Check mobile before desktop. Search Console has the same data across your whole site under Core Web Vitals, which is more useful because it tells you which templates are failing rather than which single page you happened to test.
Which of the three should I fix first?
Whichever one is actually failing, and they have almost nothing in common. Layout shift is usually the cheapest win and often an afternoon: images without dimensions, fonts swapping, something injected above the fold. Largest contentful paint is normally a hosting, image or render-blocking problem. Interaction delay is nearly always too much JavaScript, which is the expensive one.
Does speed actually affect rankings, or is that overstated?
It is a real but modest factor and it is routinely oversold. Core Web Vitals are a genuine ranking signal, and they are a tiebreaker rather than a lever: a fast page about nothing will not outrank a slow page that answers the question. The stronger argument for fixing it is that people leave, which costs you enquiries whatever Google thinks.
How long before a fix shows up in Search Console?
Weeks, because the field data is a rolling window of real visits rather than a live reading. That lag is why people deploy a genuine improvement, check two days later, see nothing, and conclude the work was pointless. Verify the fix in the lab immediately and then wait for the field data to catch up.
Can Squarespace or Wix sites be made fast?
Partly, and I would rather tell you where the ceiling is than bill you for hitting it. Images, fonts, how much you have loaded into the page and any third-party embeds are all yours to fix and often account for most of the problem. What the platform does with its own JavaScript is not available to either of us, and on a closed platform that sets a floor no developer can get under.
Find out what your real numbers are.
Get a quote in four questions
hello@madebykestrel.co.uk · replies inside one working day
This page, measured in your browser
Your deviceLCPMeasuring…
–
How long until the main content appears. Google wants under 2.5 seconds.
INPMeasuring…
–
How quickly the page answers when you tap. Under 200ms is the target.
CLSMeasuring…
–
How much the layout moves while loading. Under 0.1, ideally zero.
Real numbers from your device and connection, not a screenshot of a score I chose. Nothing is sent anywhere. The measurement happens in your browser and stays there. If one of these ever reads amber on my own site, you will see it, which is rather the point. I audit these for £650.