Core Web Vitals: what LCP, INP and CLS are and how to improve them

Core Web Vitals are three Google metrics that use real-user data to measure the experience of a page: LCP (Largest Contentful Paint) measures loading, INP (Interaction to Next Paint) measures responsiveness to interactions and CLS (Cumulative Layout Shift) measures visual stability. A page counts as good when, at the 75th percentile of visits, LCP is 2.5 seconds or less, INP is 200 milliseconds or less and CLS is 0.1 or less, with mobile and desktop assessed separately (web.dev). Google's ranking systems use these metrics, but a good result does not guarantee a position and does not outrank the relevance of the content (Google Search Central).

This guide covers the definitions in effect in October 2026. It explains each metric, how the assessment works, what Google says about ranking, where to see the numbers and where to start improving each one.

The three metrics and their thresholds

Each metric has three bands: good, needs improvement and poor. The thresholds below are the same in PageSpeed Insights and in the Search Console report (PageSpeed Insights documentation, Search Console Help).

LCP: when the main content appears

LCP marks the moment the largest element visible in the initial viewport is rendered, counted from the start of navigation. Candidates are images (<img> and <image> inside an SVG), videos (the poster or the first frame, whichever comes first), elements with a background image loaded through url() in CSS (gradients do not count) and blocks of text (web.dev, LCP). The chosen element can change with screen size, because each device shows a different part of the page (web.dev, lab and field differences).

INP: how long the page takes to respond

INP observes clicks, taps and key presses throughout the visit and measures how long each interaction takes until the screen shows the response. Scrolling, hover and zoom are not included. The value for the visit is the slowest interaction; on pages with many interactions, the slowest one in every group of 50 is discarded so that a single outlier does not set the result (web.dev, INP).

INP replaced FID (First Input Delay) as a Core Web Vital on March 12, 2024. FID only measured the delay before the browser started handling the first interaction; INP considers every interaction and runs until the screen is updated. Chrome gave anyone reading FID from the CrUX and PageSpeed Insights APIs until September 9, 2024 to move to INP (web.dev, INP announcement). Material that still describes FID as a Core Web Vital is out of date.

CLS: how much the page jumps

CLS measures unexpected layout shifts, such as a button that moves down because a banner loaded above it. Shifts are grouped into windows: shifts less than 1 second apart go into the same window, and each window lasts at most 5 seconds. The page's CLS is the window with the largest total, observed over the whole life of the page, including after scrolling. Shifts that happen within 500 ms of a click, tap or key press are treated as expected and left out (web.dev, CLS).

How the assessment works: 75th percentile, mobile and desktop

Google does not assess a single visit. The recommended measure is the 75th percentile (p75) of visits, split between mobile and desktop (web.dev). The 75th percentile means three out of every four visits had that value or better. web.dev explains that this cutoff makes sure most visits met the target without letting extreme cases distort the number (web.dev, defining the thresholds).

A page or origin passes the assessment when the p75 of all three metrics is in the good band. In PageSpeed Insights, when there is not enough INP data, the assessment considers only LCP and CLS (PageSpeed Insights).

The thresholds are the same for mobile and desktop, because user expectations do not change with the device. Since mobile has more limited hardware and networks, most thresholds were set with mobile in mind (web.dev). The results, however, are reported separately: in Search Console, each group of pages gets one status for mobile and another for desktop, and the group's status is that of its worst metric (Search Console Help). A good result on desktop tells you nothing about mobile.

What Google says about Core Web Vitals in ranking

The page experience documentation on Google Search Central, updated in September 2026, states the following (Google Search Central, page experience):

• Core Web Vitals are used by the ranking systems, and Google recommends achieving good results in them for success in Search and for the user experience in general.

• Good results in the Search Console report or in third-party tools do not guarantee that pages will rank at the top.

• Chasing a perfect score purely for SEO reasons may not be the best use of your time.

• Search always tries to show the most relevant content, even when the page experience is poor. When there is a lot of helpful content available for a query, a good page experience can contribute to the result.

• There is no single page experience signal; the systems look at several signals.

• Apart from Core Web Vitals, the other aspects of page experience do not directly help ranking, although they make the site more pleasant to use.

• The assessment is generally done per page, with some site-wide assessments.

Google does not publish how much weight Core Web Vitals carry in ranking. The cautious reading of this documentation is to treat the metrics as one factor among many: it is worth fixing what is in the poor band, especially on pages competing for queries with plenty of helpful competing content, but it makes no sense to expect that moving from "needs improvement" to "good" will change positions by itself. The strongest reason to improve is still the visitor, who waits less and does not click in the wrong place.

Where to see your site's numbers

There are two kinds of data. Field data comes from real visits, with the devices and networks visitors actually use. Lab data comes from a simulated load, with a fixed device and network. web.dev recommends starting with field data to find out whether there is a problem and using lab data to find the cause (web.dev, tools). The difference between the sources is covered in detail in Lighthouse, CrUX and RUM: which Core Web Vitals data to use.

The sources for the table are the PageSpeed Insights documentation, Search Console Help, the CrUX methodology, the Web Vitals page and the web-vitals library repository.

CrUX (Chrome User Experience Report) is Google's public field dataset. It gathers visits from Chrome users on desktop and Android who have turned on usage statistics reporting and history sync. It only includes pages and origins that are publicly discoverable and have enough visits; Google does not disclose the minimum (CrUX methodology). The CrUX API is free, updates daily and returns the rolling average of the last 28 days, broken down by phone, desktop and tablet.

RUM (real user monitoring) is data collected by the site itself. The web-vitals library, maintained by the Chrome team, measures the metrics the same way Chrome measures them for Google's tools (web-vitals). That lets you see data per page, per page type and with the responsible element, which CrUX does not show.

FCP, TTFB and TBT: supporting metrics, not Core Web Vitals

Some tools show other metrics next to the Core Web Vitals. They help find the cause of a problem, but they are not part of the assessment (web.dev).

web.dev itself says a TTFB above 0.8 s is not a problem in itself when it does not hurt the metrics that matter (web.dev, TTFB). The same reasoning applies to FCP and TBT: use them to explain a poor LCP or INP, not as a target on their own.

How to improve each metric

The recommendations below summarize the ones web.dev considers most effective (web.dev, the most effective ways to improve Core Web Vitals). Each metric has its own guide on this blog.

LCP

The starting point is to make the LCP resource (usually an image) discoverable in the initial HTML, without lazy loading and with high priority. Next comes server response time, which can drop with HTML caching on a CDN close to the user. Instant navigations, with the back/forward cache and prerendering, also reduce LCP. The step-by-step process, split into the four parts of LCP time, is in How to improve LCP.

INP

INP gets worse when the browser's main thread is busy with JavaScript at the moment of the click. The main lines of work are breaking up long tasks so the browser gets control back often, shipping less JavaScript (including old third-party tags) and avoiding large rendering updates, with a smaller DOM. Details in How to improve INP.

CLS

Most CLS goes away when all content that loads later (images, ads, embeds) has reserved space, with width and height, aspect-ratio or a minimum height. It also helps to make the page eligible for the back/forward cache and to animate with transform instead of properties that affect layout, such as top or margin. See How to fix CLS.

After a fix, CrUX field data takes up to 28 days to fully reflect the change, because it is a rolling average. If you look after many sites and need to catch regressions right after a deploy, the process is in How to monitor the performance of multiple sites.

How to check your site

The WebVyze Core Web Vitals test shows CrUX data for the last 28 days, for mobile and desktop, for up to 10 URLs. When a metric is poor, the LCP, INP and CLS diagnostics use Google PageSpeed to point to the cause. To follow results over time, the paid plans include scheduled audits, alerts and a real-visitor script (about 10 KB, based on the web-vitals library) that records LCP, INP and CLS for each visit along with the cause. WebVyze only reads public pages and does not change the site.