Short answer
What are Core Web Vitals, and which values count as good?
Site speed is judged on three metrics with thresholds Google publishes: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1. All three are measured at the 75th percentile of page loads, mobile and desktop separately. In practice what produces improvement is not plugin cleanup but image weight, font loading order and server response time.
Key takeaways
- Google's thresholds are explicit: LCP 2.5 seconds, INP 200 milliseconds, CLS 0.1 — all measured at the 75th percentile, not on an average.
- INP replaced FID as a stable Core Web Vital in 2024; a proposal still reporting on FID is out of date.
- Lab tests (the simulation in PageSpeed Insights) and field data are different things; decisions are made on field data, because that is what reflects real users' devices.
- The single most common problem is an unscaled image loading above the fold — on its own it can delay LCP by seconds.
- Speed is less a ranking factor than a conversion factor: getting under the threshold is enough, chasing a score of 100 is not the goal.
Which numbers are measured?
"The site is slow" is not a measurement. Google publishes three metrics and three thresholds, and those three — not the PageSpeed score — are what a speed engagement targets. The score is a summary of those metrics derived from a simulation; it is not the number to decide on.
Core Web Vitals thresholds and what each really measures
LCP
- Good threshold
- Under 2.5 seconds
- What it measures
- How long the largest content element takes to appear
- Most common cause
- An unscaled hero image, a slow server
INP
- Good threshold
- Under 200 milliseconds
- What it measures
- How long the screen takes to respond after an interaction
- Most common cause
- Scripts blocking the main thread
CLS
- Good threshold
- Under 0.1
- What it measures
- How much content shifts while the page loads
- Most common cause
- Images without dimensions, banners injected late
| Metric | Good threshold | What it measures | Most common cause |
|---|---|---|---|
| LCP | Under 2.5 seconds | How long the largest content element takes to appear | An unscaled hero image, a slow server |
| INP | Under 200 milliseconds | How long the screen takes to respond after an interaction | Scripts blocking the main thread |
| CLS | Under 0.1 | How much content shifts while the page loads | Images without dimensions, banners injected late |
All three are assessed at the 75th percentile: the value three quarters of users see. Averaging hides the experience on the slowest devices, which is why it is not used here.
Lab test or field data?
PageSpeed Insights shows two different things, and most arguments come from conflating them. The top section is real user data, collected from the devices of people who visited your site. The bottom section is a simulation: one load under an assumed device and connection. The score comes from the bottom; the decision should come from the top.
The practical consequence: a proposal promising "we will take your score to 95" is measuring the simulation. The right commitment is getting all three metrics under the threshold in field data — and doing it across the page group that receives the traffic, not on one page.
What actually fixes it?
- Images: the hero image above the fold needs to be correctly sized, in a modern format (AVIF/WebP) and carry width and height. The single biggest LCP gain comes from here, and the same fix improves CLS.
- Fonts: text kept invisible while a custom font loads delays LCP. Serving font files from your own domain and setting loading behaviour so the text stays visible is short work.
- Third-party scripts: the chat widget, the heatmap, three separate analytics tools and ad tags are what breaks INP. Asking whether each is genuinely used pays more than code optimisation.
- Server response time: if page generation is slow, no front-end work makes up for it. Caching or static generation cuts the first half of LCP directly.
- Layout shifts: images without dimensions, a cookie banner injected late, an ad slot. All three are solved by reserving the space.
Does speed raise rankings?
Page experience signals feed into Google's assessment, but speed alone does not lift a weak page into a good position; it separates two pages of equal strength. The real gain is elsewhere: on a mobile page above the threshold, visitors leave before the content appears. The return on speed work shows up not in a ranking table but in how many people complete the form.
Frequently asked
What PageSpeed score should I aim for?
- The score is not a target. The target is field data showing LCP under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1. Meet those three and the score rises on its own; chasing the score leads to cosmetic changes that improve none of the three things being measured.
Is switching hosting enough to get faster?
- If server response time is genuinely slow it makes a difference, but on most sites the biggest delay happens in the browser, not on the server: large images, late-loading fonts and third-party scripts. Measuring server response time before committing to a move prevents a wasted migration project.
Does a cookie banner affect speed?
- Yes, and usually in two places at once. When the banner loads late and pushes the page down, CLS breaks; and because most banner tools load their own script, it weighs on INP too. The fix is not removing the banner: reserving the space and taking the tool's script off the critical loading path is enough.
Sources
- 01Web Vitals — LCP, INP ve CLS eşikleri — web.dev, Google, 2026
- 02Understanding page experience in Google Search results — Google Search Central, 2026
Queries this page answers
- how to improve site speed
- core web vitals
- website too slow
- improve lcp
- pagespeed score