What are Core Web Vitals?

Core Web Vitals are three Google-defined measures of important aspects of website experience. Largest Contentful Paint, or LCP, tracks when the largest visible content element renders. Interaction to Next Paint, or INP, describes how quickly a page can provide visual feedback after input. Cumulative Layout Shift, or CLS, captures unexpected movement of visible elements. Assessment uses real page views and considers the 75th percentile, separately for mobile and desktop. The recommended good thresholds are LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1. These metrics help teams direct technical work towards specific problems. They do not describe the whole quality of a website: useful content, accessibility and a clear interface remain important too.

A Largest Contentful Paint of 2.5 seconds or less is considered good. Interaction to Next Paint should be 200 milliseconds or less, while Cumulative Layout Shift should be 0.1 or less. These targets are evaluated at the 75th percentile of measured page views, with mobile and desktop assessed separately. An average or a single fast test run therefore tells a different story from field data. Even a number just below a threshold does not mean that every person on every device has the same experience. Review affected templates and common journeys such as navigation, filtering and forms. Search Console can reveal groups of URLs with problems; PageSpeed Insights and DevTools then help investigate the causes. Compare like with like when tracking changes over time.

Interaction to Next Paint evaluates responsiveness throughout a visit. It observes eligible clicks, taps and keyboard input, and usually reports the slowest interaction, with some outliers excluded on pages with many interactions. First Input Delay, or FID, measured only the wait before processing the first input. It did not cover subsequent interactions or the full time until the next visible response. INP replaced FID as a Core Web Vital for that reason. A menu that is slow only on the third click could have looked fine under FID yet show up under INP. To diagnose a poor result, examine the responsible interaction and its input, processing and presentation delays rather than optimising an isolated number. Measure typical user journeys, including actions while the page is loading.

A missing INP value in PageSpeed Insights does not automatically mean a website is fast. The tool can display Chrome UX Report field measurements only where enough eligible real usage data exists for the URL or origin. A visit with no relevant click, tap or keyboard input also produces no INP measurement; scrolling and hovering do not count as eligible interactions. Lighthouse simulates a page load in the lab and cannot provide a complete INP from a real visit. Instead, metrics such as Total Blocking Time may suggest responsiveness problems. When field data is unavailable, reproduce important interactions in DevTools and consider privacy-conscious real-user monitoring. State clearly which data source you used and avoid presenting a synthetic load score as a measurement of every visitor's responsiveness.

Google recommends good Core Web Vitals for page experience and success in Search. The metrics belong to its broader guidance on page experience, but Google does not promise a ranking improvement for reaching a particular score. A technically fast site can still be less relevant than one that answers a searcher's question well. Search intent, crawlability, useful information and trust all matter. For businesses, the direct experience benefit is just as important: visitors can see content sooner, use forms more smoothly and compare offers without elements jumping around. Set goals for important pages and user journeys rather than chasing a blanket score. Record field measurements before and after a change, and do not infer search performance from a single Lighthouse run or claim guaranteed ranking gains.

Begin by linking a poor INP score to an actual interaction: which click, input or filter feels delayed? Time can be lost before an event handler starts, while JavaScript runs, or before the browser paints its next frame. Use the DevTools Performance panel to examine long main-thread tasks, and repeat common journeys while the page is still loading. Remove unnecessary scripts, break up expensive work, and defer non-urgent follow-up tasks so that visible feedback can happen sooner. A laboratory improvement is only an intermediate result. Compare real field measurements afterwards, particularly on mobile devices and heavily used page templates. This approach prevents a team from spending its effort on a slow but rarely used demo action while more important interactions remain unresponsive for customers.

Start with field measurements where available. Search Console's Core Web Vitals report identifies affected URL groups, while PageSpeed Insights can show Chrome UX Report data for a URL or origin. Those measurements come from eligible real Chrome visits; some pages have insufficient data. Next use Chrome DevTools to reproduce a slow hero image, blocking script or shifting layout. For INP, interact with the page as a visitor would: a load-only test cannot capture a complete session's responsiveness. Evaluate mobile and desktop separately, and record the page template and measurement period. After shipping a change, revisit field data rather than calling one Lighthouse score proof of success for an entire website. If you add your own real-user monitoring, account for consent and privacy requirements before collecting interaction data.