Core Web Vitals explained: LCP, INP and CLS for non-developers

Core Web Vitals are three measurements Google uses to describe how a page feels to a real visitor: how fast the main content appears, how quickly the page reacts when you click or type, and whether things jump around while it loads. They are called LCP, INP and CLS.

You don't need to write code to understand them or to check your own site. This guide explains each one in plain words, gives the official thresholds, shows how to check your pages for free, and lists the usual causes and fixes so you can have a useful conversation with your developer.

It also covers what Google actually says about rankings, which is more measured than much of what you will read elsewhere.

The three metrics and their thresholds

These are the thresholds published on web.dev by Google's Chrome team and used in PageSpeed Insights and Search Console.

The 75th percentile rule

Your score isn't an average. Google's guidance is that "a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices."

In plain words: line up all visits to a page from fastest to slowest and take the value three quarters of the way along. If 75% of visits see the main content within 2.5 seconds, LCP is good, even if the slowest quarter wait longer. PageSpeed Insights says this is chosen so that pages "provide a good user experience under the most difficult device and network conditions."

Two more things to know:

• Mobile and desktop are scored separately. A page can pass on desktop and fail on mobile.
• A page passes the Core Web Vitals assessment only when all three metrics are good at the 75th percentile. If there isn't enough INP data, PageSpeed Insights judges it on LCP and CLS alone.

LCP: how fast the main content appears

LCP "reports the render time of the largest image, text block, or video visible in the viewport, relative to when the user first navigated to the page." The viewport is the part of the page you can see without scrolling. Search Console's help says the LCP element is typically an image or video, or a large block of text, such as a hero image or main headline.

web.dev splits LCP into four parts, which helps you find where the time goes:

1. Time to First Byte (TTFB): how long until your server starts sending the page.
2. Resource load delay: how long before the browser starts downloading the main image.
3. Resource load duration: how long that download takes.
4. Element render delay: the gap between the image arriving and it appearing on screen.

The two "delay" parts should be close to zero on a well-built page.

Common causes and fixes

• Slow server response. Fix: cache pages and serve them from a CDN (content delivery network), which keeps copies on servers close to your visitors. web.dev names a CDN as one of the most effective ways to cut TTFB.
• The main image is found late. It is added by JavaScript, set as a CSS background, or lazy-loaded (set to load only when scrolled into view). Fix: use a normal <img> tag in the HTML, remove loading="lazy" from that image, and add fetchpriority="high" so the browser starts fetching it sooner.
• The page is built in the browser. With client-side rendering, JavaScript must run before anything appears. Fix: server-side rendering, so the HTML arrives with the content in it.
• Heavy files blocking the page. Fix: defer scripts and styles that aren't needed for the first screen.
• A large image. Fix: compress it and use a modern format such as AVIF or WebP. web.dev warns that this alone may not improve LCP if the delays above are the real problem.

INP: how quickly the page responds

INP measures the time from a click, tap or key press until the screen next updates to show a response (the "next paint"). Scrolling, hovering and zooming don't count. Unlike its predecessor, it watches every interaction during the visit, and for most pages it reports the slowest one. On pages with many interactions, it ignores one outlier for every 50.

Each interaction has three parts:

1. Input delay: waiting for the browser to finish whatever it was already doing.
2. Processing time: your site's code reacting to the click.
3. Presentation delay: the browser drawing the updated screen.

Common causes and fixes

Slow INP usually means the browser is busy, often running JavaScript, when the visitor interacts. A task that runs for more than 50 milliseconds is a "long task", and it can stop the page responding quickly.

• Too much JavaScript. Fix: remove unused code, and split code so each page only loads what it needs.
• Third-party tags. Analytics, chat widgets, A/B testing and ad scripts all compete for the same time. Fix: review your tag manager regularly and remove tags nobody uses.
• Long tasks in your own code. Fix: break them up so the browser can respond between chunks (developers call this "yielding").
• Very large, complex pages. Fix: keep the page structure (the DOM) small; big pages take longer to redraw after every click.
• Doing everything before showing anything. Fix: show visual feedback straight away and do non-urgent work afterwards.

INP replaced FID on 12 March 2024

Before INP, responsiveness was measured by FID (First Input Delay). FID "only measured the input delay of the first interaction on a page". INP covers every interaction and includes the time to run code and draw the result. The Chrome team made INP a Core Web Vital and retired FID on 12 March 2024, and FID was removed from Search Console the same day. web.dev notes that "many fewer sites are passing the threshold" for INP than did for FID, so a site that passed on FID may not pass on INP.

CLS: how much the page jumps around

CLS measures unexpected movement of visible content: the button that moves just as you tap it, or the paragraph that slides down when an advert loads. The score has no unit. Zero means nothing moved; each shift's score combines how much of the screen moved and how far.

CLS reports the worst burst of shifts, called a session window: shifts less than 1 second apart, up to 5 seconds in total. Shifts within 500 milliseconds of a click, tap or key press are treated as expected and don't count.

Common causes and fixes

web.dev lists the most common causes as images without dimensions, ads, embeds and iframes without dimensions, content injected after the page loads, and web fonts.

• Images and videos without a size. Fix: give every image width and height attributes, or a CSS aspect-ratio, so the browser reserves space before it downloads.
• Ads, embeds and widgets. Fix: reserve space with a minimum height on the container.
• Banners that push content down. Cookie and notification banners that slide in often cause shifts. Fix: overlay them instead, and animate with CSS transform rather than properties that change the layout.
• Web fonts. Text reflows when the custom font replaces the fallback. Fix: preload key fonts, use font-display: optional, or match the fallback font's size.
• The back button. Fix: make pages eligible for the back/forward cache (bfcache), which restores a page instantly with no shifts. Pages served with no-store caching or using unload handlers are often excluded.

Field data and lab data

You will see two kinds of numbers, and they often disagree.

CrUX collects data from Chrome users who have opted in, and only includes public pages with enough visitors. Chrome's documentation says CrUX data "is used by Google Search to inform the page experience ranking factor", so field data is what counts.

Lighthouse loads your page on a simulated mid-range phone on a mobile network. It reports extra diagnostic metrics, such as FCP (First Contentful Paint, when anything first appears) and TBT (Total Blocking Time, how long the page was too busy to respond after that). Its performance score runs from 0 to 100: 90 or above is good, 50 to 89 needs improvement, below 50 is poor. Scores vary between runs, and PageSpeed Insights says good lab data "does not necessarily mean real-user experiences will also be good."

How to check your own site for free

PageSpeed Insights

1. Go to PageSpeed Insights and enter a page URL.
2. Read the real-user results at the top first, on both the mobile and desktop tabs.
3. If a page has too little real-user data, PageSpeed Insights falls back to data for your whole site (the origin), or shows none.
4. Scroll down to the Lighthouse diagnostics for clues about what is slow.

Search Console's Core Web Vitals report

1. Open the Core Web Vitals report in Search Console. It uses the same CrUX field data.
2. Look at mobile and desktop separately. Similar pages are grouped, and each group gets the status of its worst metric.
3. Only indexed URLs with enough data appear. A small site may see "No data available".
4. Google suggests fixing "Poor" first, then the issues affecting the most URLs or your most important ones.
5. After a fix ships, click Start Tracking. Search Console then watches the next 28 days of data before marking the issue fixed.

What Google says about rankings

Google's page experience documentation is clear but measured:

• "Core Web Vitals are used by our ranking systems."
• There is no single page experience signal; Google's ranking systems "look at a variety of signals".
• Good results in Search Console or third-party tools "doesn't guarantee that your pages will rank at the top of Google Search results".
• "Google Search always seeks to show the most relevant content, even if the page experience is sub-par. But for many queries, there is lots of helpful content available. Having a great page experience can contribute to success in Search, in such cases."
• Scores are meant to help you improve your site for users, and "trying to get a perfect score just for SEO reasons may not be the best use of your time."

The honest reading: relevance comes first. Page experience can contribute when many pages answer a search well. Aim to get every metric into "good" for your important pages, then spend your time elsewhere. A faster, steadier page is also simply better for visitors.

What to ask your developer

Search Console's help gives non-technical owners two rules of thumb: keep a page and all its resources under 500KB, and limit a page to 50 resources for best performance on mobile. Then ask:

1. Which element is the LCP on our homepage and main templates, and is it in the HTML from the start?
2. Is that image lazy-loaded? Does it have fetchpriority="high"?
3. What is our TTFB, and is our HTML cached on a CDN?
4. Which third-party scripts load on every page, and which can we remove or delay?
5. Which interactions are slowest for real users, and which long tasks cause them?
6. Do all images, videos, embeds and ad slots have space reserved?
7. How do we load web fonts?
8. Are our pages eligible for the back/forward cache?
9. Can we collect our own field data? web.dev recommends sites set up their own real-user monitoring, for example with the web-vitals JavaScript library.

How the BeforeQuery AI Marketer helps

The AI Marketer's SEO tab runs PageSpeed Insights on your homepage and shows the Lighthouse scores for performance, accessibility, best practices and SEO, on mobile and desktop, with lab measurements of LCP, FCP, TBT and CLS. It also flags render-blocking files. It does not measure INP or real-user field data, so use the PageSpeed Insights field section and the Search Console report described above for those.

The free plan includes one homepage audit at sign-up. On paid plans, the SEO Agent audits your homepage every day and writes 2 fixes a day, each with steps and a copy-ready snippet you can pass to your developer.

Performance work usually needs your developer. For on-page fixes such as alt text, titles, meta descriptions and canonical tags, the Coding Agent opens a GitHub pull request that you review and merge. For the wider checklist, see our technical SEO audit checklist. Sign up free.

Frequently asked questions

Are Core Web Vitals a ranking factor?

Yes, but a measured one. Google says "Core Web Vitals are used by our ranking systems", and also that good scores don't guarantee top rankings and that it will show the most relevant content even if its page experience is poor. Treat good Core Web Vitals as something that helps when pages are otherwise similar, not as a substitute for relevant content.

Why are my PageSpeed Insights and Search Console numbers different?

Search Console groups similar pages together and reports the group, while PageSpeed Insights reports a single URL, which may be faster or slower than its group. Search Console also keeps URL parameters that PageSpeed Insights strips. And the lower part of PageSpeed Insights is a one-off lab test, which often differs from 28 days of real-user data.

Why does PageSpeed Insights show no real-user data for my page?

Real-user data comes from the Chrome User Experience Report, which only includes public pages with enough visits from Chrome users who have opted in. New or low-traffic pages often don't qualify, so PageSpeed Insights shows data for your whole site instead, or nothing. The lab test still works, but it can't measure INP.

Do I need a Lighthouse score of 100?

No. Google says trying to get a perfect score just for SEO reasons may not be the best use of your time. Aim for "good" on LCP, INP and CLS in real-user data for your important pages, using Lighthouse to find causes.

How long until fixes show up?

Field data covers the previous 28 days, so improvements appear gradually as new visits replace old ones. When you click Start Tracking in Search Console's Core Web Vitals report, it monitors your site for 28 days before confirming the issue is fixed. Lab tests in PageSpeed Insights show the effect immediately.

Sources

• Web Vitals (web.dev)
• Largest Contentful Paint (web.dev)
• Interaction to Next Paint (web.dev)
• Cumulative Layout Shift (web.dev)
• Optimize LCP (web.dev)
• Optimize INP (web.dev)
• Optimize CLS (web.dev)
• The most effective ways to improve Core Web Vitals (web.dev)
• Interaction to Next Paint becomes a Core Web Vital on March 12 (web.dev)
• First Input Delay (web.dev)
• First Contentful Paint (web.dev)
• Total Blocking Time (web.dev)
• Why lab and field data can be different (web.dev)
• About PageSpeed Insights (Google)
• Overview of CrUX (Chrome for Developers)
• Core Web Vitals report (Search Console Help)
• Understanding Core Web Vitals and Google search results
• Understanding page experience in Google Search results