Core Web Vitals: What They Are and How to Improve LCP, INP and CLS (2026)

Core Web Vitals are three numbers that sum up how a page feels to a real visitor: how fast the main content appears, how quickly the page reacts when someone taps or clicks, and whether things jump around while it loads. Google uses them in ranking, Chrome collects them from millions of real users, and Search Console grades every page on them.

Most guides stop at the definitions. This one explains what each metric actually measures in 2026, what counts as good, where to get trustworthy numbers, and then walks through the fixes that move each metric, in the order that usually pays off fastest.

What are Core Web Vitals?#

Core Web Vitals are a set of metrics from Google that measure real-world user experience for loading, interactivity and visual stability. There are three:

INP replaced First Input Delay (FID) on March 12, 2024. FID only measured the delay before the first interaction was handled. INP looks at the responsiveness of every interaction during the visit and reports one of the slowest, so it is a much harder and more honest test. If a guide still talks about FID, it is out of date.

The 75th percentile rule#

A page passes when at least 75% of real visits hit the "good" threshold for each metric, measured separately on mobile and desktop. That means you're not optimizing for your own fast laptop on office Wi-Fi. You're optimizing for the slower phones and connections in the top quarter of your audience.

Do Core Web Vitals affect rankings?#

Yes, but less than many people think. Google's page experience documentation says that "Core Web Vitals are used by our ranking systems", and in the same breath that good scores don't "guarantee that your pages will rank at the top", and that "Google Search always seeks to show the most relevant content, even if the page experience is sub-par."

In practice, Core Web Vitals work like a tiebreaker. They won't lift thin content above a genuinely more helpful page, but between pages of similar quality, a fast and stable one has an edge. The bigger payoff is usually conversions: visitors who wait less and don't misclick buy more, sign up more and bounce less.

Field data vs lab data: where to get your numbers#

This is where most confusion comes from. There are two kinds of measurement, and they answer different questions.

Field data comes from real Chrome users visiting your pages, collected in the Chrome User Experience Report (CrUX) over a rolling 28 days. It's what Google uses. You'll find it in:

• Search Console's Core Web Vitals report, which groups your URLs into Good, Needs improvement and Poor for mobile and desktop.
• PageSpeed Insights, in the "Discover what your real users are experiencing" section at the top, when your page or origin has enough traffic.
• The web-vitals JavaScript library, which you can add to your own analytics to collect LCP, INP and CLS from every visitor.

Lab data comes from loading the page once in a controlled environment, such as Lighthouse in Chrome DevTools or the lower half of PageSpeed Insights. It's repeatable and great for debugging, but it doesn't reflect your real users, and it can't measure INP at all, because no one is interacting with the page. Lighthouse reports Total Blocking Time (TBT) as a stand-in: high TBT usually predicts poor INP.

Use field data to know whether you have a problem, and lab data to find and fix it.

How to improve Largest Contentful Paint (LCP)#

Google's web.dev team breaks LCP into four parts, which tells you exactly where the time goes:

Find your LCP element first. PageSpeed Insights and the DevTools Performance panel both tell you which element it is. On most pages it's the hero image or the main headline.

Then fix the slowest part:

• Slow TTFB: use a CDN, cache full HTML pages where you can, cut slow database queries and server-side plugins, and avoid redirect chains before the page.
• Long load delay: make sure the LCP image is in the HTML the server sends, not injected by JavaScript. Add fetchpriority="high" to it, and use <link rel="preload"> if the image is set in CSS. Never lazy-load the LCP image.
• Long load duration: serve the right size for each screen with srcset, use modern formats like WebP or AVIF, and compress properly. A 1.5 MB hero image is the single most common LCP problem.
• Long render delay: remove or defer render-blocking CSS and JavaScript, and avoid hiding content until a script runs, as many A/B testing tools do.

How to improve Interaction to Next Paint (INP)#

INP is slow when the browser's main thread is busy and can't respond to the visitor. Every interaction has three phases: the delay before your code runs, the time your code takes, and the time to paint the result.

• Break up long tasks. Any JavaScript task over 50 ms blocks the page. Split big jobs into smaller chunks and yield back to the browser between them, for example with await scheduler.yield() where supported, or a setTimeout fallback.
• Do less work in event handlers. Update the screen first, then do the heavy work (analytics calls, data processing) afterwards.
• Audit third-party scripts. Chat widgets, tag managers, heatmaps and ad scripts all compete for the main thread. Remove what nobody uses and load the rest later. Our guide on how to see what scripts a website uses shows how to list them.
• Keep the DOM small. Very large pages make every update more expensive to render.
• Avoid layout thrashing. Reading layout values and writing styles in a loop forces repeated recalculation.

How to improve Cumulative Layout Shift (CLS)#

Layout shifts happen when something appears or resizes after the content around it has already rendered.

• Set width and height on every image and video, or use the CSS aspect-ratio property, so the browser reserves the space before the file loads.
• Reserve space for ads, embeds and iframes with a fixed-size container, even when no ad fills it.
• Don't insert content above existing content. Cookie banners, promo bars and "you might also like" blocks injected at the top push everything down. Use overlays or reserve the space.
• Load web fonts carefully. Preload key fonts and use font-display and fallback font metrics that match, so text doesn't reflow when the font arrives.
• Animate with transform, not layout properties. Moving elements with top or height causes shifts; transform doesn't.

Common causes and fixes at a glance#

Why Core Web Vitals regress after a launch#

Most sites don't fail Core Web Vitals because they were built badly. They fail because something changed and nobody measured it:

• A marketing team adds a new chat widget, heatmap or tag through the tag manager.
• A plugin or theme update ships more JavaScript and CSS.
• A new hero image is uploaded straight from a camera at 4 MB.
• A cookie banner or promo bar is added at the top of every page.

Because field data is a 28-day rolling window, the damage shows up in Search Console slowly, often weeks after the change that caused it. By then it's hard to remember what changed.

How MyKavo helps you catch regressions early#

MyKavo watches the causes of slow pages, so you find out about a regression the day it ships, not a month later:

• Weekly Lighthouse audits. Every active website gets an automatic Lighthouse audit of its homepage each week, and you can run one on demand for any page. The Performance section shows the Performance, Accessibility, Best Practices and SEO scores, plus lab metrics like LCP, CLS and Total Blocking Time, with a trend over time. If the performance score drops by 15 points or more, you get an alert.
• Page weight and request alerts. Each scan compares the total weight of the page and its resources against your approved baseline, and flags growth over 20%, or a jump of more than 25% in the number of requests.
• Third-party script alerts. When an unknown third-party script appears on a monitored page, MyKavo tells you, so a new tag never slips in unnoticed.

Lighthouse is lab data, so keep using Search Console and PageSpeed Insights for the field data Google ranks on. To check a page right now, the free Page Size Checker breaks down its weight by scripts, styles, images and fonts, and the free Script Detector lists every script it loads. For a broader checkup, see our website audit guide and our guide to website speed.

The bottom line#

Core Web Vitals measure what visitors feel: fast loading, quick responses and a stable page. Aim for an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less and a CLS of 0.1 or less at the 75th percentile. Use field data to find problems, lab data to fix them, and start with the biggest wins: the hero image, render-blocking code and third-party scripts. Then keep watching, because most regressions arrive quietly with the next plugin, script or image.

See what's weighing your pages down with the free Page Size Checker, then start free with MyKavo to get weekly Lighthouse audits and an alert the day a new script or heavy asset slows your site down.