There is a conversation that happens in almost every performance project. Someone runs PageSpeed Insights, gets a score in the nineties, and cannot understand why Search Console still reports the site as failing Core Web Vitals.
Both numbers are correct. They are measuring different things, and only one of them affects your ranking.
PageSpeed Insights gives you a lab score — a simulation on a throttled connection and a simulated device. It is useful for diagnosis and useless as a target.
Google ranks on field data. The Chrome User Experience Report collects what real users on real devices and real networks actually experienced, over a rolling 28-day window, evaluated at the 75th percentile. That means three-quarters of your visitors must have a good experience — including the ones on a mid-range Android phone on patchy mobile data.
A site can score 95 in the lab and fail in the field. This happens constantly, and it is the single most common reason performance work appears not to work.
Three metrics, all at the 75th percentile of field data: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1. Get them from Search Console's Core Web Vitals report or the CrUX API — not from a PageSpeed run. Use lab tools to find out why a metric is bad, and field data to know whether it is bad.
What Performance Is Actually Worth
Those are correlational figures, which is worth saying plainly — fast sites tend to be well-built sites, and well-built sites convert better for reasons beyond speed alone.
The more persuasive evidence comes from controlled tests published through Google's own case study programme, where performance was the only variable changed:
| Company | What they changed | Measured result |
|---|---|---|
| Rakuten 24 | LCP optimisation, run as an A/B test | +53.4% revenue per visitor, +33.1% conversion rate |
| Vodafone Italy | LCP improved 31% via server-side rendering and reduced render-blocking JavaScript | +8% sales |
| RedBus | INP optimisation — responsiveness, not load time | +7% sales |
| Ray-Ban | Speculation Rules API to prerender key pages | +101.5% mobile conversion on product pages |
The RedBus result is the one most teams overlook. They improved responsiveness after load, not load time — and it moved sales by 7%. INP is the metric most sites are quietly failing while they focus entirely on LCP.
The Lab-Versus-Field Trap
- · Simulated device and throttled network
- · Single run, controlled conditions
- · Results appear immediately
- · Excellent for diagnosis
- · Has no effect on ranking
- · Can pass while real users suffer
- · Real users, real devices, real networks
- · Rolling 28-day window, 75th percentile
- · Takes 4–8 weeks to reflect a fix
- · Tells you whether a problem exists
- · This is what Google ranks on
- · Cannot be gamed by a good test run
You deploy a fix. Lab scores improve within minutes. Search Console does not move for four to eight weeks, because the 28-day rolling window has to fill with post-fix data. Teams that do not know this conclude the work failed and revert it — or worse, keep optimising a metric that was already fixed. Set the expectation before the work starts, not when someone asks why the dashboard is unchanged.
Most LCP Problems Are Server Problems
The standard LCP advice is about images: compress them, use WebP, lazy-load below the fold. All correct, and for many sites it is not where the time is going.
LCP decomposes into four parts, and it is worth measuring each before optimising any:
This is the practical argument for treating performance as an application problem rather than a frontend one. If TTFB is the largest part of your LCP, the fix is a database index, a cache layer, a regional deployment — infrastructure work, not asset optimisation. Teams where frontend and infrastructure sit in separate silos frequently spend a quarter compressing images while the real cost sits in an unindexed query.
INP: The One Most Sites Are Failing
INP replaced First Input Delay in 2024 and is considerably harder to pass. FID measured only the delay before the browser could begin processing the first interaction. INP measures the full latency from input to visual response, across every interaction in the visit.
A site can load fast and still fail INP badly. The usual causes:
- Long tasks on the main thread — anything over 50ms blocks the browser from responding to input at all
- Heavy hydration — the page looks interactive several seconds before it actually is
- Third-party scripts — analytics, chat widgets, session recording and tag managers competing for the same single thread
- Unnecessary re-renders — a state change that re-renders half the component tree on every keystroke
- Synchronous work in event handlers — doing the expensive thing before yielding back to the browser
The fix is usually the same idea applied in different places: break long tasks up, yield to the main thread, and defer anything that does not need to run before the first interaction.
The Thresholds, and What Each One Really Means
| Metric | Good | Needs work | Poor | Usual root cause |
|---|---|---|---|---|
| LCP | under 2.5s | 2.5–4s | over 4s | Server response time, render-blocking resources |
| INP | under 200ms | 200–500ms | over 500ms | Long main-thread tasks, third-party scripts |
| CLS | under 0.1 | 0.1–0.25 | over 0.25 | Images without dimensions, injected banners, late fonts |
All three are evaluated at the 75th percentile of field data. Passing on your own laptop means nothing — your laptop is not the 75th percentile of your users.
A 90-Day Sequence
Get field data before touching anything
Search Console's Core Web Vitals report, segmented by mobile and desktop. Mobile is almost always worse and almost always where the revenue is. If you have no field data, install a real-user monitoring script and wait — optimising blind wastes the quarter.
Week 1Rank pages by traffic times revenue, not by score
A page scoring 40 that nobody visits is not the problem. Your highest-traffic conversion pages scoring 65 are. Sort by business impact and fix the top three templates — most sites have fewer distinct templates than they assume.
Week 1Decompose LCP before optimising it
Measure all four sub-parts. If TTFB is 800ms, start with the backend — caching, query optimisation, regional deployment. If the image is the bottleneck, then compress. Doing this in the wrong order is how performance projects deliver nothing.
Week 2–4Audit third-party scripts honestly
List every one, what it does, and who asked for it. Most sites carry several nobody can account for. Each is a main-thread competitor and an INP contributor. Removing two dead tags often beats a week of code splitting.
Week 3Fix INP with task breaking, not rewrites
Find long tasks in the Performance panel. Break them up, yield to the main thread, defer non-critical work past first interaction. This is usually a set of surgical changes rather than an architectural overhaul.
Week 4–8Set a performance budget and enforce it in CI
Performance regresses by default — every feature, script and font adds weight. A budget checked on every pull request is the only thing that holds the gain. Without it you will repeat this whole exercise in eighteen months.
Week 8+Frequently Asked Questions
Not Sure Where Your Time Is Going?
We do full-stack performance work — frontend, backend and AWS infrastructure. Book a free 30-minute call and we'll look at your field data and tell you honestly where the bottleneck actually is.