What Are Core Web Vitals? How to Measure and Improve LCP, INP and CLS

Core Web Vitals is the collective name for three metrics Google defined to measure how fast a page loads for real users, how quickly it responds to interaction and how much it shifts while loading. Google counts these metrics among its page experience signals. On their own they do not outweigh content quality; but they can make the difference between similar pages, and bad values make visitors leave before you have said anything.

What the three metrics measure

LCP: Largest Contentful Paint

Measures how long the largest content element on screen (usually a hero image, a large heading or a video frame) takes to appear. It is roughly the moment the user says 'the page is open'. By Google's published thresholds, about 2.5 seconds or less is good; values above 4 seconds count as poor.

INP: Interaction to Next Paint

Measures how quickly the screen responds when the user clicks a button, opens a menu or types into a field. All interactions on the page are evaluated and one of the worst is reported. According to Google, about 200 milliseconds or less is good, over 500 milliseconds is poor. INP replaced FID, the earlier metric that measured only the first interaction.

CLS: Cumulative Layout Shift

Measures how much elements shift unexpectedly during loading. It is what you experience when an ad loads above the paragraph you just started reading and pushes the text down. It is a unitless score; about 0.1 or less is good, above 0.25 is poor.

How much do they affect rankings?

The honest answer: less than content and links, but not zero. Google says it uses page experience as one of a set of signals; the page that best answers the question usually stays on top even if it is slow. If two pages are at a similar level in content, the fast one gains the edge. There is an indirect effect too: a user bounces from a page that opens slowly or responds late to a tap, clicks the next result, and you lose both a visitor and a possible conversion.

In practice, follow this order: if your page is in the poor range, fixing it is a priority; if it is in the good range, the time you would spend improving it further usually pays more when spent on content or internal linking. Moving values from needs improvement to good is worth the effort, especially on pages that make money.

The difference between lab data and field data

To read Core Web Vitals correctly you need to separate two kinds of data. Lab data is a tool loading and measuring your page under fixed conditions (a specific device profile, a specific connection speed); Lighthouse does this. Because it is repeatable, it is ideal for debugging. Field data is measurements collected from Chrome users who actually visit your site, and this is the data Google uses as a ranking signal.

The two often disagree. A page that scores green in Lighthouse can look red in the field if most of your users come from old phones and weak mobile connections. Conversely, a page that looks slow in the lab can be fine in the field if your users come from office computers. Look at field data when deciding, lab data when finding the problem.

How to measure Core Web Vitals

The Search Console report

The Core Web Vitals report in Search Console is based on field data and sorts URLs into good, needs improvement and poor groups, separately for mobile and desktop. It groups similar pages; so you see a shared problem in the product page or blog post template on one line. The report has a limit: no data is shown for pages or sites without enough visitors. On small sites an empty report does not mean there is no problem.

PageSpeed Insights

You enter a single URL; at the top you see the field data for that page (if any), below it the Lighthouse lab result. It is the most practical way to examine the problem on a specific page in detail. It also shows which element is the LCP element and which scripts keep the main thread busy.

Lighthouse and browser tools

The Lighthouse tab in Chrome's developer tools runs the same audit locally. The Performance tab lets you examine interaction problems, meaning INP, frame by frame. If you want to scan the whole site regularly, a site audit tool runs Lighthouse on all your pages and collects the results in one table; weranklab's site audit does this in the same report as the technical errors, and because credits are charged per page you are not tied to a monthly plan.

Always measure with the mobile profile. Even if most of your traffic comes from desktop, Google evaluates sites primarily through the mobile version, and mobile values are almost always worse.

Common LCP problems and fixes

• Slow server response: if the browser gets the first byte late, everything else is delayed. Server-side caching, better hosting or a CDN are the first places to look.
• Large hero image: the LCP element is usually an image. Serve it in WebP or AVIF, at the size it will be shown on screen; define srcset for different screens.
• Lazy-loaded main image: deferring the image at the top of the screen worsens LCP directly. Only defer images below the fold and give the LCP image a high loading priority (fetchpriority).
• Render-blocking CSS and JavaScript: large stylesheets and synchronous scripts in the head delay the first paint. Inline the critical CSS and defer the rest.
• Web fonts: if the heading does not appear until the font loads, the LCP element waits. font-display: swap and preloading shorten that time.

Common INP problems and fixes

• Long JavaScript tasks: tasks that run longer than 50 milliseconds on the main thread after a click delay the response. Break big jobs into small pieces and let the browser paint in between.
• Third-party scripts: chat bubbles, analytics tags, A/B testing tools and ad code share the main thread. Measure how much each one consumes and remove the unnecessary ones.
• Heavy DOM updates on interaction: redrawing thousands of elements when a filter is clicked creates visible stutter. Leave non-visible content for later.
• Missing visual feedback: having the button change state immediately while waiting for the server response improves measured INP directly, because the metric measures the time to the next paint.

Common CLS problems and fixes

• Images and videos without dimensions: set width and height attributes or a CSS aspect-ratio so the browser reserves the space in advance.
• Late-loading ad and embed slots: give the box where the ad will go a fixed height; if the ad does not arrive, leave the space empty.
• Banners inserted above content: if a cookie notice, promo bar or app invitation pushes content down, show it as an overlay or reserve its space from the start.
• Font swapping: the size difference between the fallback font and the real font shifts lines. size-adjust can bring the fallback closer to the real font.
• Content added after interaction: shifts tied directly to a user's click do not count; shifts arriving half a second after the click do.

What order to work in

1. Start with the poor group in the Search Console report that contains the most URLs. A single template-level fix improves hundreds of pages at once.
2. For each group, open a representative URL in PageSpeed Insights; identify the LCP element, the longest task and the shifting elements.
3. Make the fix, verify it locally with Lighthouse, then wait to see it in the field. Because field data reflects the last 28 days, seeing the effect in reports can take weeks.
4. Prioritize pages that bring traffic. The LCP of a page nobody visits affects neither your rankings nor your revenue.

Core Web Vitals are one part of the technical SEO checklist; focusing on speed while crawlability and indexing problems remain is doing things in the wrong order. First make sure Google reaches the page, then improve the experience. To see the effect of improvements on rankings, track the related keywords; the rank tracking guide covers matching fix dates with chart notes. If you want to verify a page's mobile and desktop positions separately, the free rank checker needs no sign-up.

Do not chase scores. The last few points of improvement made to hit 100 in Lighthouse usually make no noticeable difference to the user; spending the same effort on a real checkout page with poor INP pays more.