If you have opened Google Search Console or run a PageSpeed Insights test, you have probably run into three cryptic acronyms: LCP, CLS, and INP. They sound technical and intimidating, but they answer three very human questions about your website: Does it load quickly? Does it stay still while loading? Does it respond when I click?
These three metrics are Google’s Core Web Vitals, and they are a confirmed ranking factor. More importantly, they measure how your site actually feels to use. A site that fails them frustrates visitors and quietly loses both rankings and conversions.
In this guide, we will break down exactly what LCP, CLS, and INP mean, the current 2026 thresholds, and, most importantly, how to fix each one.
What Are Core Web Vitals?
Core Web Vitals are three metrics Google uses to measure the real-world experience of visitors on your pages:
- LCP (Largest Contentful Paint) measures loading speed
- CLS (Cumulative Layout Shift) measures visual stability
- INP (Interaction to Next Paint) measures responsiveness
Together they form part of Google’s page experience signals. Sites that pass all three have a measurable ranking advantage over sites that do not, especially as a tiebreaker between pages of similar content quality. Google documents all three in detail on its official Core Web Vitals guide.
One important note before we go further: INP replaced the older FID (First Input Delay) metric in March 2024. Any guide still talking about FID is out of date. INP is the current responsiveness metric, and it is the one most sites now struggle with.
The 2026 Thresholds
To pass Core Web Vitals, each metric needs to hit its “good” threshold:
| Metric | Measures | Good | Needs Work | Poor |
|---|---|---|---|---|
| LCP | Loading speed | ≤ 2.5s | 2.5s – 4.0s | > 4.0s |
| INP | Responsiveness | ≤ 200ms | 200ms – 500ms | > 500ms |
| CLS | Visual stability | ≤ 0.1 | 0.1 – 0.25 | > 0.25 |
There is a catch most people miss. You only pass a metric when at least 75% of your real visitors hit the “good” threshold. And Google grades you on field data (real Chrome users) at the 75th percentile over a rolling 28-day window, not on a single lab test.
This is why a perfect score in Lighthouse can coexist with a failing grade in Search Console. Lighthouse is a lab simulation on a fast connection. Real visitors on mid-range phones and slower networks are what actually count. Always trust your field data over lab scores.
The Reality Check: Most Sites Are Failing
If your site is failing Core Web Vitals, you are far from alone. Depending on the study, only around 48% of mobile websites pass all three Core Web Vitals. That means the majority fail at least one.
INP is the biggest culprit. It is the most commonly failed metric in 2026, with a large share of sites unable to hit the 200ms threshold. This makes sense once you understand what each metric requires, so let’s break them down one at a time.
LCP: Largest Contentful Paint (Loading Speed)
What It Measures
LCP measures how long it takes for the largest visible element on your page to load and render. This is usually your hero image, a large banner, a headline block, or a video thumbnail – the main thing a visitor sees “above the fold.”
In plain terms: how long until the page looks loaded to the person waiting? The target is 2.5 seconds or faster.
What Causes Poor LCP
LCP problems are almost always about resources and delivery: slow server response times, large unoptimized images, render-blocking CSS and JavaScript, and slow-loading web fonts.
How to Fix LCP
Improve your server response time (TTFB). If your server is slow to respond, everything downstream is delayed. Quality hosting with server-level caching is the foundation. This is where a good host makes a bigger difference than any plugin.
Optimize your images. Your LCP element is often an image. Compress it, serve it in a modern format like WebP or AVIF, and make sure it is appropriately sized for the device. Do not load a 3000px image into a 600px space.
Preload the LCP image. Tell the browser to prioritize loading your largest above-the-fold image so it does not wait in the queue behind less important resources.
Reduce render-blocking resources. Minimize and defer non-critical CSS and JavaScript so the browser can paint the main content sooner.
Use caching and a CDN. Cached pages and assets served from a location near the visitor load dramatically faster. If you are unsure how much caching actually helps here, our guide on what caching can and cannot fix explains the backend-versus-frontend distinction.
INP: Interaction to Next Paint (Responsiveness)
What It Measures
INP measures how quickly your page responds when a visitor interacts with it, clicking a button, tapping a menu, or typing in a field. Specifically, it measures the delay from the interaction to the moment the browser paints the visual response, and it reports the worst interaction across the whole visit.
The target is 200 milliseconds or faster. Anything slower and the page feels sluggish, like buttons are not registering your taps.
What Causes Poor INP
INP is the hardest Core Web Vitals metric to fix because it is not about compressing a file or adding an attribute. It is about JavaScript. Heavy JavaScript execution blocks the browser’s main thread, and while the main thread is busy, it cannot respond to the user.
Any JavaScript task that runs longer than 50 milliseconds blocks interaction. Stack several of these together and buttons feel dead for a noticeable moment. On WordPress, this is often caused by too many plugins, bloated themes, and third-party scripts (chat widgets, analytics, ad tags, tracking pixels).
How to Fix INP
Reduce and clean up your JavaScript. The single biggest lever. Remove plugins you do not need, since each one can add its own scripts. Fewer scripts means a less congested main thread.
Break up long tasks. Large JavaScript tasks should be split into smaller chunks so the browser can respond to user input between them rather than freezing.
Defer non-essential JavaScript. Load third-party scripts (chat widgets, tracking, ads) after the page is interactive, not before. They are the most common INP killers.
Audit your third-party scripts. Every external script is a potential INP problem. Question whether each one earns its place. A single heavy chat or tracking widget can wreck your INP on its own.
Choose a lightweight theme and page builder. Some themes and builders generate enormous amounts of JavaScript and DOM elements. A lean foundation makes every other fix easier.
Because INP is architectural rather than a quick toggle, it is the metric where professional help most often pays off, especially if your stack keeps failing no matter how many optimization plugins you add.
CLS: Cumulative Layout Shift (Visual Stability)
What It Measures
CLS measures how much your page unexpectedly moves around while it loads. You have experienced bad CLS yourself: you go to tap a button, an image or ad suddenly loads above it, the whole page jumps, and you tap the wrong thing. That frustrating jump is exactly what CLS penalizes.
The target is a score of 0.1 or lower. Unlike the others, CLS is a unitless score, not a time measurement.
What Causes Poor CLS
CLS is almost always about missing dimensions. When the browser does not know how much space an element will take up, it loads other content first, then shoves everything down when the element finally arrives. Common causes: images without width and height attributes, ads and embeds without reserved space, web fonts that swap and reflow text, and content injected dynamically above existing content.
How to Fix CLS
Always set width and height on images. This is the single most effective CLS fix. When the browser knows an image’s dimensions in advance, it reserves the correct space, and nothing jumps when the image loads.
Reserve space for ads, embeds, and iframes. Give these elements a defined size container so the surrounding content does not shift when they load.
Handle web fonts carefully. Font swapping can cause text to reflow. Use font-display settings and preload key fonts to minimize the shift.
Avoid inserting content above existing content. Cookie banners, notification bars, and dynamically injected elements should reserve their space rather than pushing everything down after the page has already rendered.
CLS is usually the easiest of the three to fix, since most issues come down to specifying dimensions and reserving space.
How to Measure Your Core Web Vitals
Before fixing anything, measure. Here is the practical workflow:
Start with field data. Open the Core Web Vitals report in Google Search Console. This shows your real-world CrUX data, grouped by URL type, for both mobile and desktop separately. This is the official scorecard.
Diagnose with PageSpeed Insights. Run your failing pages through PageSpeed Insights. It shows both field and lab data and gives specific suggestions for each metric.
Dig deeper with Chrome DevTools. For detailed diagnosis, the Performance panel in Chrome DevTools shows exactly what is delaying LCP, which tasks are blocking INP, and (with the Layout Shift Regions overlay) which elements are causing CLS.
One critical reminder: mobile and desktop are scored separately, and mobile is almost always harder to pass due to weaker devices and slower networks. Always check both.
Which Metric Should You Fix First?
Do not try to fix everything at once. Prioritize like this:
- Fix whatever is in the “Poor” band first. A metric in the red is doing the most damage. You will not get a “Good” overall rating until all three are out of “Poor.”
- Then tackle INP. It is the hardest and most commonly failed, so it usually needs the most attention.
- Then LCP. It often has the highest commercial impact since it affects the first impression and bounce rate.
- Then CLS. Usually the easiest to clean up once the others are handled.
Do not waste time optimizing a metric that is already green. And remember: because CrUX data updates on a 28-day rolling window, you need to wait several weeks after a fix before judging whether it worked. Patience is part of the process.
Why This Matters Beyond SEO
It is tempting to treat Core Web Vitals as an SEO box to tick. But the ranking benefit is almost a side effect of the real win.
These metrics measure how your site feels to a real person. A fast-loading, stable, responsive site keeps visitors engaged, reduces bounce rates, and converts better. A slow, jumpy, unresponsive one drives people away before they ever see your offer. Fixing Core Web Vitals improves the experience, and the rankings tend to follow.
This is also why chasing a perfect Lighthouse score misses the point. The goal is not a number in a simulator. The goal is a site that genuinely works well for the people using it on real devices.
Getting Help With Core Web Vitals
LCP and CLS are often fixable with disciplined optimization: better hosting, image optimization, reserved space, and caching. INP is where many site owners hit a wall, because it requires reworking how JavaScript is loaded and executed, which is genuinely technical.
If your WordPress site keeps failing Core Web Vitals no matter how many optimization plugins you add, the problem is usually deeper in the stack: a heavy theme, plugin bloat, or an overloaded server. Webueno’s Speed Optimization service audits your site against all three metrics and fixes the underlying causes, both the backend delivery and the frontend code, rather than just installing another plugin. And because we run managed WordPress hosting on isolated, high-performance servers, the foundational speed that LCP depends on is built in from the start.
Passing Core Web Vitals for Good
LCP, CLS, and INP are not as intimidating as they look. LCP is about loading fast (better hosting, optimized images, caching). CLS is about not jumping around (set dimensions, reserve space). INP is about responding quickly (less JavaScript, fewer heavy scripts).
Measure your field data first, fix whatever is in the “Poor” band, work through INP, LCP, and CLS in that order, then wait for the 28-day window to confirm your progress. Do that consistently, and you will not just pass Google’s thresholds; you will have a site that genuinely feels fast to every visitor.
If you would rather have it handled properly, Webueno’s Speed Optimization service can audit your Core Web Vitals and fix the root causes so you pass on real-world devices and stay passing.
Get your Core Web Vitals fixed by experts
Frequently Asked Questions
What are LCP, CLS, and INP?
They are Google’s three Core Web Vitals. LCP (Largest Contentful Paint) measures how fast the main content loads, CLS (Cumulative Layout Shift) measures how visually stable the page is while loading, and INP (Interaction to Next Paint) measures how quickly the page responds to clicks and taps.
What are the Core Web Vitals thresholds in 2026?
To pass, you need LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less. You pass a metric only when at least 75% of your real visitors hit the “good” threshold, measured over a rolling 28-day window.
Why did my Lighthouse score say 100 but Search Console says I’m failing?
Because they measure different things. Lighthouse is a lab test on a simulated fast connection. Google’s actual assessment uses field data from real Chrome users (CrUX) at the 75th percentile. Real visitors on slower devices and networks are what count, so always trust your field data over lab scores.
Which Core Web Vitals is hardest to fix?
INP is the hardest. LCP is usually about resources (images, server speed) and CLS is about dimensions (setting width and height), but INP is about JavaScript architecture. Fixing it means reducing and restructuring how scripts load and execute, which is more technical than the other two.
What replaced FID in Core Web Vitals?
INP (Interaction to Next Paint) replaced FID (First Input Delay) in March 2024. FID only measured the delay before the first interaction was processed. INP measures the responsiveness of all interactions throughout the visit and reports the worst one, making it a more complete measure of how responsive a page feels.
Are Core Web Vitals a Google ranking factor?
Yes. Core Web Vitals are a confirmed ranking factor as part of Google’s page experience signals. They are not the strongest signal (content relevance and authority matter more), but they act as a meaningful tiebreaker between pages of similar quality, and passing all three gives a measurable advantage.
How long does it take to see results after fixing Core Web Vitals?
Because Google uses field data over a rolling 28-day window, you typically need to wait several weeks after deploying a fix before the improvement fully reflects in your scores. Do not judge whether a fix worked based on the first few days.
Do Core Web Vitals differ between mobile and desktop?
Yes, and Google scores them separately. Mobile is usually harder to pass because of weaker processing power, slower networks, and touch interactions. Search Console shows both device categories separately, so check and optimize for both.
