Google measures your site's speed with three numbers. Those numbers influence both your position in search results and how many visitors abandon the page before it appears — and the link between the two is more direct than most businesses assume.
Short answer: what are Core Web Vitals?
Core Web Vitals are the metrics Google uses to assess real user experience through three measures: LCP (how long the main content takes to appear), INP (the delay before the page responds to an interaction) and CLS (unexpected shifting of the layout). They are collected from the browsers of real visitors, not from laboratory tests. They are not decisive on their own in ranking, but they are a distinguishing signal between closely matched results — and their effect on conversion is larger than their effect on ranking.
The three numbers in plain language
The metric names look technical, but each measures a single user complaint:
| Metric | What it measures | The user's words | "Good" threshold |
|---|---|---|---|
| LCP Largest Contentful Paint | Time until the main content appears | "The page just won't load." | Under 2.5 seconds |
| INP Interaction to Next Paint | Delay before the page responds to a click | "I pressed the button and nothing happened." | Under 200 milliseconds |
| CLS Cumulative Layout Shift | Unexpected movement of the layout | "I clicked the wrong thing — it moved." | Under 0.1 |
To count as "good", a metric must stay under its threshold for 75% of visits. The assessment looks at the experience of three-quarters of users, not at the average. That distinction matters: your average can look healthy while most of your mobile visitors sit above the threshold.
Field data versus lab data
Measurement tools show two different kinds of data, and confusing them leads to poor decisions:
- Field data (real users): Collected from visitors' own devices over the previous 28 days. This is what search engines consider. It includes the real customer on a modest phone and a mobile connection.
- Lab data (simulation): Produced by a testing tool under controlled conditions. It is valuable for diagnosis because it is repeatable — but basing a "my site is fast" conclusion on it is misleading.
The practical rule: decide with field data, fix with lab data. Field data says "there is a problem"; lab data says "the problem is here".
A further common confusion is the absence of field data on newly launched sites. With too few visits, the report appears empty — which does not mean the site is fast.
The six most common causes of slowness
- Unoptimised images. The number one cause of poor LCP. The largest image is usually in the hero area and is often served far larger than it is displayed. Modern formats and correct sizing alone can recover several seconds.
- Too many blocking third-party scripts. Analytics, chat, heatmaps, ad pixels — each looks small; together they degrade INP directly. Non-critical scripts should be deferred.
- Server response time. The browser draws nothing until the server sends the first byte. Insufficient resources, an uncached application or a slow database query stretch this and delay the whole chain.
- Images and ad slots without declared dimensions. The classic cause of CLS: with no space reserved, the page jumps as content loads. Declaring width and height usually ends the problem.
- Font loading behaviour. Hiding text until custom fonts arrive both lowers perceived speed and causes layout shift. Showing text immediately in a fallback font is the better choice.
- Heavy templates and plugin accumulation. On WordPress especially, plugins added over the years but no longer used still load their own files on every page. Regular cleanup delivers faster gains than code optimisation.
How speed connects to business results
Ranking is not the only reason to invest in these three numbers. A slow page loses the visitor before any content appears, and a lost visitor never enters any funnel. Speed improvement therefore means more customers from the same advertising budget — it also directly affects quality score on the paid side.
The effect is most visible in mobile traffic. A delay unnoticed on a desktop multiplies on an average phone over a mobile connection. If most of your visitors are on mobile, both measurement and decisions should be based on mobile data.
Measurement and improvement checklist
- Start with field data. Search Console's experience report shows which page groups fall below threshold.
- Measure your five highest-traffic pages separately. A site-wide average can hide a problem on your most valuable pages.
- Assess mobile and desktop separately. They usually point to different problems.
- Prioritise the hero image and reduce it to the size actually displayed.
- Inventory third-party scripts. Record who added each one and why; remove the orphans.
- Verify server-side caching. Test whether dynamic pages are actually being cached.
- Declare dimensions for every image and iframe.
- Wait 28 days after changes. Field data updates on a rolling window; seeing no immediate result is not failure.
- Make measurement repeatable. Same page, same tool, same conditions — otherwise improvement cannot be measured.
The infrastructure share
Some of these metrics are governed by code, others directly by hosting infrastructure. Time to first byte, disk speed, PHP version and the caching layer set the floor for LCP; no amount of front-end work goes below that floor. If your audience is geographically spread, a content delivery network shortens the physical distance to the user and opens the same page far faster.
So the correct order for a speed project is: server and caching first, then images, then scripts, and code-level tuning last. Projects that start at the other end spend the most effort where the return is smallest.
Netişlem expert view: the goal is not a score of 100, it is staying under the threshold
Businesses lose most energy chasing a perfect score in a testing tool. What search engines look at is not the score but whether the three metrics sit under their thresholds. The difference between 92 and 99 is meaningless to users and to search engines alike; bringing LCP from 4.1 seconds down to 2.4 produces measurable change on both sides.
Our second observation: speed work is usually treated as a one-off project. But a website is a living system; a new campaign image, an added tracking tag or an updated plugin can undo the gains within weeks. A short quarterly check protects better than a large optimisation every six months.
Third, measurement is rarely done on real devices. On a developer's powerful machine and fast connection, the problem is invisible. Deciding on the basis of the average phone your customers actually use is the shortest route to understanding these three metrics.
Frequently asked questions
How much do Core Web Vitals affect ranking?
They are not a decisive factor on their own; content quality and relevance come first. But they distinguish between results of similar quality. Their real impact shows on conversion: a slow page loses visitors regardless of rank.
My PageSpeed score is 90 but my metrics are red — why?
The score comes from a lab simulation; the metric status comes from real user data. The tool's controlled environment may not reflect your customers' devices and connections. Decide on field data.
What is INP, and how does it differ from the old FID metric?
FID measured only the delay of the first interaction. INP evaluates every interaction during a visit and represents the worst experience. It is therefore stricter; sites that looked fine on FID may struggle on INP.
Will changing hosting fix these numbers?
If server-side delay is the dominant problem, it makes a clear difference, because time to first byte delays the whole chain. If heavy images or third-party scripts are the cause, migration alone will not suffice. The right order is to measure first and identify the bottleneck.
How do I find a CLS problem quickly?
Open the page with a slow-connection simulation and watch which elements move during loading. The culprit is usually an image without declared dimensions, a late-loading ad slot or a notice bar that appears afterwards.
How often should I check?
A quarterly check suffices for most businesses. Beyond that, run a short verification after theme updates, new plugin installations or campaign page launches.
Conclusion
Treating Core Web Vitals as a technical agenda item is precisely what keeps them postponed. These three numbers answer one question: what does your customer experience when your page opens? Every business that makes that question measurable sees the return in search and in sales alike.
If you would like us to measure where your site really stands on these three metrics, get in touch. You can review our fast hosting, WordPress speed and CDN solutions, and see our related articles on capacity testing and hosting terminology.