You opened PageSpeed Insights, saw three acronyms in red, and a number that explains nothing. LCP, INP, CLS. This article translates each one, shows the official threshold Google uses to decide whether your page passes, and lists the fixes that solve most real problems.
What Google actually measures
Core Web Vitals is a set of three metrics that try to answer three questions about the experience of someone opening your page:
- Did the important part load fast? That is LCP.
- When I tapped, did it respond fast? That is INP.
- Did the content stay put, or jump around? That is CLS.
Notice what is not on that list. Total load time is not there. Number of requests is not there. The Lighthouse score from 0 to 100 is not there. Google chose to measure perception, not server statistics. A page can take eight seconds to finish loading everything and still pass all three metrics, as long as the main content appears early, responds to touch, and does not move.
Each metric has three bands: good, needs improvement, and poor. For a page to be considered passing, it has to sit in the good band on all three, and that assessment uses the 75th percentile of real visits. In other words: being fast on your own machine is not enough. It has to be good for 75% of the people who arrive.
LCP: the largest visible element
LCP stands for Largest Contentful Paint. The browser looks at the visible area of the screen and asks: what is the largest block of content here? Usually it is the top image, a video, a large block of text, or the main heading. LCP is the moment that element finishes rendering.
The official thresholds:
| Band | Value |
|---|---|
| Good | up to 2.5 seconds |
| Needs improvement | 2.5 to 4.0 seconds |
| Poor | above 4.0 seconds |
In practice, poor LCP almost always has one of four causes: the server is slow to send the first byte, the top image is huge and unoptimised, there is CSS or JavaScript blocking rendering before the content, or the main image is only discovered after JavaScript runs. The image side is covered in detail in images that do not sink your site.
Finding out which element is your LCP takes thirty seconds. The PageSpeed Insights report has an item pointing at the exact element, and in Chrome developer tools, on the performance tab, the LCP marker sits visibly on the timeline. Do that before optimising anything, because teams routinely spend hours compressing an image that is not even the measured element.
INP: the response to a tap, which replaced FID in 2024
In March 2024, Google swapped FID for INP as the official responsiveness metric. The difference matters. FID measured only the delay of the first interaction in a session, which is why almost every site passed it. INP, Interaction to Next Paint, measures the gap between an interaction and the moment the screen is actually updated, considering every interaction in the visit and reporting essentially the worst one.
| Band | Value |
|---|---|
| Good | up to 200 milliseconds |
| Needs improvement | 200 to 500 milliseconds |
| Poor | above 500 milliseconds |
Poor INP is almost always JavaScript. The browser has a single thread for your code. If a script locks that thread for 400 milliseconds doing something, the tap sits in a queue waiting. Too many plugins, third-party banners, chat widgets, embedded maps, and tracking scripts are the usual suspects.
CLS: the layout that jumps
CLS is Cumulative Layout Shift. It is that experience of reaching for a button and, at the exact moment of the tap, an image finishing loading above and pushing everything down, so you tap something else. CLS measures how much content moved without the user asking for it.
| Band | Value |
|---|---|
| Good | up to 0.1 |
| Needs improvement | 0.1 to 0.25 |
| Poor | above 0.25 |
CLS is the cheapest of the three to fix, because the cause is nearly always the same: something entered the page without reserved space. An image with no width and height attributes. A banner that appears late. A custom font that swaps and changes the height of the text. A cookie notice that pushes the header down.
One detail confuses people: shifts caused by a user action do not count, as long as they happen right after it. Opening an accordion and seeing the content below move down is expected and carries no penalty. What counts is movement nobody asked for. To reproduce the problem, open the page with the cache disabled and the network throttled in developer tools: whatever loads slowly reveals exactly where space is missing.
Lab data vs field data
This is the most common confusion, and it is worth settling once.
Lab data comes from a simulation. Lighthouse opens your page in a controlled environment, with a simulated network speed and processor, and measures. It is reproducible, runs in seconds, and is meant for diagnosis. But it is a simulation, and INP does not even appear there in a real form, because there is no user clicking.
Field data comes from actual people. Chrome collects, from users who opted in to share, the metrics of the pages they visit. That dataset is CrUX, the Chrome User Experience Report, and it uses a rolling 28-day window. That is the data shown in the Core Web Vitals report in Search Console and at the top of PageSpeed Insights.
- A Lighthouse score of 100 does not mean your page passes. Only field data decides.
- After a fix, field data takes weeks to reflect it, because the window is 28 days.
- A low-traffic site may not have enough field data for a specific URL. In that case, Google may assess the origin as a whole.
Use the lab to fix and the field to confirm. Never the other way around.
It is also worth noting that field data mixes every device and connection that visited. A site with heavy mobile traffic on cellular networks will show worse numbers than a desktop lab run on fibre, and that is not a measurement error: it is the reality of your audience. That is why PageSpeed Insights separates mobile from desktop results, and the mobile column is almost always the one that decides.
The 6 fixes that solve most cases
- Serve the top image at the right size and in a modern format. A 3000-pixel-wide photo displayed in an 800-pixel area is pure wasted LCP.
- Mark the main image as high priority. Use
fetchpriority="high"on it and neverloading="lazy"on the hero element. Deferring the hero image is deferring your own LCP. - Declare width and height on every image and video. That alone solves a good share of CLS, because the browser reserves the space before the file arrives.
- Get third-party JavaScript out of the critical path. Chat, maps, pixels, and widgets can load later. Every third-party script at the top of the HTML is an INP risk.
- Control your fonts. Use
font-display: swap, preload only the files you really use, and set a fallback font with similar metrics to reduce the jump when the swap happens. - Reduce server response time. Caching, adequate hosting, and pre-rendered HTML attack the base of LCP. If the first byte is slow, nothing downstream makes up for it. Our comparison of hosting types is worth a read.
Three myths about Core Web Vitals
Myth 1: passing Core Web Vitals puts your site first. It does not. The metrics are part of page experience signals, which weigh less than relevance and content quality. They tend to act as a tiebreaker between similar pages, not as a shortcut.
Myth 2: a Lighthouse score of 100 is a pass. We just saw why not. Lab is not field.
Myth 3: it is the developer problem, not mine. A large share of the lost points comes from business decisions: installing the fourth tracking script, uploading the photo straight from the camera, accepting a third-party banner at the top. Whoever decides what goes on the page decides the metric outcome.
If you want a broader route to put the technical side in order, our technical SEO checklist covers what comes before and after performance metrics.
Want to know why your page is outside the thresholds and what exactly has to change? Talk to ALB Seven and we will look at your case with real data, not guesswork.