Core Web Vitals: What They Measure and How to Improve Them
SEO · Published · 6 min read · RankMonks
Core Web Vitals are three metrics Google uses to measure how a page feels to a real visitor: how fast the main content loads, how quickly the page responds to input, and how much the layout moves about.
They are part of how Google assesses page experience, which is one of many inputs to ranking. Relevance and content quality carry far more weight, but when pages are otherwise similar, a better experience can help.
Slow, jumpy pages also lose visitors before they read a word. This guide explains each metric, how to measure it and what to fix first.
Key takeaways
- Core Web Vitals are Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift.
- A page passes when LCP is 2.5 seconds or less, INP is 200 milliseconds or less and CLS is 0.1 or less, measured at the 75th percentile of page loads.
- Google assesses Core Web Vitals using field data from real visitors, not the lab score from a single test.
- Most problems come from page templates, so fixing one template usually improves every page built on it.
- Core Web Vitals are a modest ranking input, and good scores will not make up for content that misses what the searcher wants.
What are Core Web Vitals?
Core Web Vitals are the three measurements Google has chosen to represent the quality of a page's user experience. Each covers a different moment in a visit.
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| Largest Contentful Paint (LCP) | Time until the largest visible element has rendered | 2.5 s or less | Over 2.5 s, up to 4 s | Over 4 s |
| Interaction to Next Paint (INP) | Delay between an interaction and the next visual update | 200 ms or less | Over 200 ms, up to 500 ms | Over 500 ms |
| Cumulative Layout Shift (CLS) | How much visible content moves unexpectedly | 0.1 or less | Over 0.1, up to 0.25 | Over 0.25 |
A few details are worth knowing:
- LCP usually tracks a hero image, a video poster or a large block of heading text.
- INP looks at clicks, taps and key presses throughout the visit and reports one of the slowest. It replaced First Input Delay as a Core Web Vital in March 2024.
- CLS is a score, not a time. It combines how much of the screen moved and how far.
The thresholds are judged at the 75th percentile. In plain terms, at least three in four visits to a page need to meet the "good" mark for the page to pass. Mobile and desktop are assessed separately.
How do you measure Core Web Vitals?
Measure Core Web Vitals with field data first, then use lab data to diagnose. Field data comes from real visitors on real devices. Lab data comes from a single simulated test.
| Field data | Lab data | |
|---|---|---|
| Source | Real Chrome users over a rolling period of about four weeks | One test run on a simulated device |
| Where to find it | Search Console, the top section of PageSpeed Insights | Lighthouse, the lower section of PageSpeed Insights |
| Best for | Knowing whether you pass | Finding the cause and testing a fix |
| Limits | Needs enough traffic, slow to update | Does not reflect your actual visitors |
A sensible routine:
- Open the Core Web Vitals report in Google Search Console. It groups similar addresses and marks them as good, needs improvement or poor, for mobile and desktop.
- Pick the worst group that matters commercially. Note which metric is failing.
- Run an example address through PageSpeed Insights. Read the field data at the top, then the diagnostics below.
- Reproduce the problem in your browser. The Performance panel in Chrome DevTools shows which element is the LCP, which interactions are slow and which elements shift.
Two cautions. The performance score out of 100 in Lighthouse is not a Core Web Vital, and Google does not use it for ranking. Also, lab tests cannot report INP, because nobody is interacting with the page. Total Blocking Time is the closest lab stand-in.
How do you improve Largest Contentful Paint?
Improve LCP by getting the largest element to the browser sooner and removing whatever delays it from rendering. Start by identifying that element, because the fix depends on what it is.
Common fixes, roughly in order of impact:
- Speed up the server response. Use caching and a content delivery network so the HTML arrives quickly.
- Shrink the LCP image. Serve it at the size it is displayed, in a modern format such as WebP or AVIF, with sensible compression.
- Tell the browser it is important. Do not lazy load the LCP image. Add
fetchpriority="high"or preload it so it is requested early. - Remove render-blocking resources. Defer scripts that are not needed for the first view, and trim unused CSS.
- Put the LCP element in the HTML. If a script has to run before the main image or heading appears, LCP will be slow.
How do you improve Interaction to Next Paint?
Improve INP by reducing the amount of JavaScript that runs on the main thread when someone interacts. The browser can only do one thing at a time on that thread, so a long task makes the page feel frozen.
Work through these:
- Audit third party scripts. Chat widgets, tag managers, trackers and advert scripts are frequent causes. Remove what you do not use and delay the rest.
- Break up long tasks. Split heavy functions into smaller pieces so the browser can respond in between.
- Do less on each interaction. Show a visual response at once, then do slower work afterwards.
How do you improve Cumulative Layout Shift?
Improve CLS by reserving space for everything before it loads. Layout shifts happen when the browser has to make room for something it did not know the size of.
The usual causes and fixes:
- Images and videos without dimensions. Add
widthandheightattributes, or a CSSaspect-ratio, so the space is held. - Adverts, embeds and iframes. Give their containers a fixed minimum height.
- Banners inserted above content. Cookie notices and promotions should overlay the page or occupy reserved space, not push content down.
- Web fonts that swap in. Choose a fallback font with similar proportions, and preload key fonts.
Shifts that happen straight after a visitor's own action, such as opening a menu, are expected and do not count against you.
How do you check that your fixes worked?
Check fixes in the lab straight away, then confirm with field data over the following weeks. Field data is a rolling average, so it will not move the day you deploy.
- Rerun PageSpeed Insights or Lighthouse on the affected template and compare the diagnostics.
- In Search Console, open the issue in the Core Web Vitals report and use "Validate fix".
- Wait for the rolling window to fill with post-fix visits before judging the result.
Core Web Vitals fit naturally into a wider technical SEO audit, and they sit alongside the content checks in our on-page SEO checklist.
Frequently asked questions
Are Core Web Vitals a ranking factor?
Core Web Vitals are used by Google's ranking systems as part of assessing page experience. They are one input among many, and relevance matters far more. Good scores help most when competing pages are similar in quality.
What is a good Core Web Vitals score?
A good result is LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less. Each is measured at the 75th percentile of page loads. A page needs to meet all three to pass the assessment.
What replaced First Input Delay?
Interaction to Next Paint replaced First Input Delay as a Core Web Vital in March 2024. First Input Delay only measured the delay before the first interaction was handled. INP considers interactions across the whole visit, so it gives a fuller picture of responsiveness.
How long do Core Web Vitals take to update after a fix?
Field data for Core Web Vitals is collected over a rolling period of about four weeks. After a fix, expect the numbers to improve gradually and settle once that window contains only visits from after the change.
Core Web Vitals are easier to fix when you know which template and which element is at fault. If you want help finding that, start a conversation.
Written by RankMonks.