Core Web Vitals in 2026: fixing LCP, INP and CLS on real Indian sites

TL;DR: Core Web Vitals are three metrics Google measures from real Chrome users, not from lab tests. LCP measures how fast the main content appears, INP measures how quickly the page responds to interaction, and CLS measures unexpected layout movement. The thresholds are 2.5 seconds, 200 milliseconds and 0.1, assessed at the 75th percentile over 28 days.

The metric that catches most sites is INP, which replaced FID and is substantially harder to pass because it measures every interaction rather than only the first. For Indian sites the difficulty is compounded by the audience: a large share of traffic arrives on mid-range Android phones over mobile networks, and that is precisely the profile INP punishes.

What the three metrics actually measure

Largest Contentful Paint measures when the largest visible content element finishes rendering. Usually a hero image, a banner, or a large block of text. It answers: how long before the page looks like something.

Good is under 2.5 seconds. Poor is over 4 seconds.

LCP breaks down into four parts, and knowing which one dominates tells you what to fix: time to first byte, resource load delay, resource load duration, and render delay. A slow TTFB is a server problem. A long load duration is usually an oversized image.

Interaction to Next Paint measures responsiveness. When a user taps, clicks or types, how long until the page visibly updates? INP reports a value near the worst interaction across the whole visit.

Good is under 200 milliseconds. Poor is over 500.

Cumulative Layout Shift measures unexpected movement of visible elements. The classic case: you go to tap a link, an ad loads above it, everything moves down, and you tap the wrong thing.

Good is under 0.1. Poor is over 0.25.

The important framing: these are user experience metrics that happen to be ranking inputs. Fixing them because Google measures them is fine. Fixing them because a page that responds in 90ms feels better than one that takes 600ms is the better reason, and it shows up in conversion long before it shows up in rankings.

Field data versus lab data

A distinction that causes endless confusion.

Lab data comes from a simulated page load: Lighthouse, the PageSpeed Insights performance score, or your browser's devtools. One load, one simulated device, one simulated network. Reproducible, useful for debugging, and not what Google uses for ranking.

Field data comes from real Chrome users who opted into reporting, aggregated in the Chrome User Experience Report. This is what Search Console reports and what feeds the ranking signal.

Consequences worth internalising:

Your Lighthouse score of 95 does not mean you pass Core Web Vitals. Lighthouse cannot measure INP properly at all, because INP requires actual user interaction and a simulated load has none.

Assessment uses the 75th percentile across 28 days. That means three quarters of visits must meet the threshold, so you are optimising for your slower users rather than your median. Improvements take weeks to appear in field data because the window rolls.

Sites with low traffic may have insufficient field data, in which case Google falls back to origin-level or category-level data.

Where to look: Search Console's Core Web Vitals report for field data grouped by URL pattern, PageSpeed Insights for both field and lab data on a single URL, and the web-vitals JavaScript library if you want to collect your own real-user measurements, which is the most useful option for diagnosing INP.

Why INP is harder than FID was

FID, the metric INP replaced, measured only the delay before the browser began processing the first interaction. It did not measure how long the processing took, and it ignored every interaction after the first.

Most sites passed FID easily. It was a low bar.

INP measures the full duration from interaction to the next visual update, across effectively all interactions in the visit, and reports near the worst one. Three components: input delay while the main thread is busy, processing time for your event handlers, and presentation delay while the browser renders the result.

That means a site can pass FID comfortably and fail INP badly, which is exactly what happened to a large number of sites at the transition.

What fails INP in practice:

Heavy JavaScript event handlers doing significant work synchronously. Long tasks blocking the main thread, so an interaction arriving mid-task waits for it to finish. Third-party scripts, particularly tag managers, chat widgets and analytics, executing on interaction. Large DOM trees where any style recalculation is expensive. React or similar frameworks re-rendering large subtrees on every state change. And on WordPress specifically, plugin scripts attaching handlers to everything.

The diagnostic difficulty is that INP problems are invisible in lab tools. You need real-user data or manual testing where you actually interact with the page on a throttled mid-range device while recording a performance profile.

Fixing LCP

In rough order of typical impact.

Optimise the LCP element itself. Identify it first, since PageSpeed Insights names it. Usually a hero image.

Serve it in a modern format, WebP or AVIF, at appropriate dimensions. A 3000px-wide image displayed at 800px is wasting most of its bytes. Use responsive srcset so mobile devices get mobile-sized files. Compress properly, since quality 80 is visually indistinguishable from 100 at a fraction of the size.

This single fix resolves a large share of LCP failures on Indian business sites, where oversized hero images are close to universal.

Never lazy-load the LCP element. A common self-inflicted wound: a lazy-loading plugin applies to all images including the hero, which delays the very thing being measured. Exclude above-the-fold images.

Preload the LCP resource. A <link rel="preload"> for the hero image tells the browser to fetch it early rather than waiting to discover it in the HTML.

Reduce TTFB. If the server takes 800ms to respond, LCP cannot be good. Full-page caching is the highest-leverage fix, followed by a current PHP version, object caching, and database optimisation. If the server is far from your users, distance alone can cost more than everything else combined.

Eliminate render-blocking resources. CSS and synchronous JavaScript in the head block rendering. Inline critical CSS, defer the rest, and add defer or async to scripts that do not need to run immediately.

Self-host fonts and preload them. Third-party font requests add a DNS lookup, a connection and a round trip. Use font-display: swap so text renders in a fallback rather than staying invisible.

Fixing INP

Harder, because the problem is usually your JavaScript rather than your assets.

Break up long tasks. Any task over 50ms blocks the main thread. Split heavy work into chunks and yield between them so the browser can handle pending interactions. Modern approaches use scheduler.yield() where available, with setTimeout as a fallback.

Move work off the interaction path. When a user taps, update the UI immediately and defer everything non-essential. The user needs to see something happen; the analytics event and the state sync can wait a frame.

Audit third-party scripts ruthlessly. Tag managers, chat widgets, session recording, A/B testing tools and ad scripts are the most common INP culprits, and each one runs code you did not write on your users' devices. Load them after interaction where possible, or remove ones nobody uses. Most sites are carrying at least one script nobody remembers adding.

Reduce DOM size. Very large DOM trees make every style recalculation expensive. Page builders generate deeply nested markup, and a page with 3,000 nodes responds noticeably worse than one with 800.

Debounce expensive handlers. Input, scroll and resize handlers firing on every event are a reliable source of jank.

Avoid layout thrashing. Reading a layout property and then writing to the DOM in a loop forces repeated synchronous layout. Batch reads, then batch writes.

On WordPress, the practical version: deactivate plugins one at a time on staging and measure INP after each. The offender is usually one or two plugins loading substantial JavaScript on every page regardless of whether that page uses the feature.

Fixing CLS

The easiest of the three, and the most often ignored.

Set explicit dimensions on images and video. Width and height attributes, or a CSS aspect ratio. Without them the browser does not know how much space to reserve and content jumps when the image arrives.

Reserve space for ads and embeds. A container with a fixed minimum height prevents the shift when the ad loads. This is the single largest CLS source on content sites.

Never insert content above existing content. Cookie banners, promotional bars and notification strips that push the page down are a classic failure. Overlay them or reserve space.

Handle font loading. A fallback font with different metrics causes a shift when the web font swaps in. size-adjust and matched fallback metrics reduce this substantially.

Avoid animating layout properties. Animate transform and opacity, which the compositor handles, rather than width, height or top, which trigger layout.

Watch dynamically injected content. Related posts, review widgets, and anything loaded after initial render should have reserved space.

CLS is largely a discipline problem rather than a technical one. Reserve space for everything that will appear, and the metric takes care of itself.

Fixes ranked by impact

Fix	Primarily helps	Effort	Typical impact
Compress and resize the LCP image	LCP	Low	Very high
Enable full-page caching	LCP	Low	Very high
Exclude above-fold images from lazy loading	LCP	Low	High
Remove unused third-party scripts	INP	Low	High
Set image dimensions everywhere	CLS	Low	High
Reserve space for ads and embeds	CLS	Low	High
Move server closer to users	LCP	Medium	High for India
Defer non-critical JavaScript	LCP, INP	Medium	High
Preload the LCP resource	LCP	Low	Medium
Self-host and preload fonts	LCP, CLS	Medium	Medium
Break up long JavaScript tasks	INP	High	High where relevant
Reduce DOM size	INP	High	Medium to high
Upgrade PHP version	LCP	Low	Medium
Object caching	LCP	Medium	Medium

The pattern: the highest-impact fixes are mostly low effort, and they are mostly about not shipping unnecessary bytes or unnecessary scripts. The genuinely hard work, breaking up long tasks and reducing DOM size, matters on complex applications and rarely on a business site.

The India-specific problem

Core Web Vitals are measured on the devices your users actually have, and for Indian sites that changes the calculation.

Device profile. A large share of Indian traffic arrives on mid-range Android phones with substantially less CPU headroom than a flagship. INP is a CPU-bound metric. JavaScript that executes in 40ms on a fast device can take 200ms on a mid-range one, and the field data reflects the latter.

Test on a real mid-range Android device, or use aggressive CPU throttling in devtools. Testing on a MacBook and concluding the site is fast is the most common measurement error.

Network conditions. Variable mobile networks with real latency mean every additional round trip costs more. This makes reducing request count and connection setup disproportionately valuable, and it makes server distance expensive.

Server location. A user in Pune hitting a Mumbai server sees perhaps 15 to 30 milliseconds of round trip. The same user hitting Singapore sees 60 to 90, and the US East Coast pushes past 250. TTFB is a direct LCP component, and across the multiple round trips of a page load the difference compounds.

If your audience is Indian and your server is not, that is frequently the single largest available improvement, and no amount of front-end optimisation substitutes for it. Our note on when to move from shared hosting covers how to tell whether the server or the site is your constraint.

Practical implication. Indian sites should weight mobile optimisation harder than international guidance suggests. Fewer scripts, smaller images, less JavaScript, and a server in-region.

How much this actually affects rankings

Honest calibration, because this gets oversold in both directions.

Core Web Vitals are a ranking signal. They are a minor one relative to content relevance, quality and links. Passing them will not lift a page that does not deserve to rank, and failing them will not sink a page that clearly answers the query better than anything else.

Where they matter most is at the margin: between two pages of similar quality and authority, the faster one has an advantage. On competitive queries where many pages are similarly good, that margin is where results are decided.

The stronger argument is not ranking at all. It is behaviour. Slow, janky pages produce higher bounce rates, lower engagement and worse conversion, and those effects are larger and more immediate than any ranking adjustment. A checkout that responds in 100ms converts better than one that takes 600ms, and that is true whether or not Google ever notices.

So the right framing: fix Core Web Vitals because your users are on mid-range phones on mobile networks and the experience is currently worse than you think. Treat the ranking benefit as a bonus.

FAQs

What are the Core Web Vitals thresholds?

LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1 for a good rating. Poor is LCP over 4 seconds, INP over 500 milliseconds, and CLS over 0.25. Assessment uses the 75th percentile of real user visits over a rolling 28-day window, so three quarters of visits must meet the threshold.

What replaced First Input Delay?

Interaction to Next Paint replaced FID as a Core Web Vital. FID measured only the delay before processing the first interaction, which most sites passed easily. INP measures the full time from interaction to the next visual update across effectively all interactions in the visit, reporting near the worst, which is a substantially harder standard.

Why does my Lighthouse score not match Search Console?

Because they measure different things. Lighthouse produces lab data from a single simulated load and cannot measure INP properly, since INP requires real interaction. Search Console reports field data from real Chrome users at the 75th percentile over 28 days. A Lighthouse score of 95 does not mean you pass Core Web Vitals.

How do I improve LCP on WordPress?

Start with the LCP element, usually the hero image: serve it as WebP or AVIF at correct dimensions with responsive srcset, and never lazy-load it. Then enable full-page caching, upgrade to a current PHP version, defer non-critical JavaScript, and preload the LCP resource. If your server is far from your audience, moving it in-region often matters more than all of these.

What causes bad INP scores?

Heavy JavaScript event handlers running synchronously, long tasks blocking the main thread, third-party scripts such as tag managers and chat widgets, very large DOM trees making style recalculation expensive, and framework re-renders of large subtrees. On WordPress it is usually one or two plugins loading substantial JavaScript on every page regardless of whether the page uses the feature.

How do I fix Cumulative Layout Shift?

Set explicit width and height or aspect ratio on every image and video, reserve fixed space for ads and embeds, never inject content above existing content, handle font swap with matched fallback metrics, and animate transform and opacity rather than layout properties. CLS is mostly a discipline problem: reserve space for anything that will appear later.

Do Core Web Vitals really affect Google rankings?

Yes, as a minor signal relative to content relevance, quality and links. They matter most at the margin, between pages of similar quality on competitive queries. The stronger reason to fix them is user behaviour, since slow and unresponsive pages produce measurably worse engagement and conversion regardless of any ranking effect.

How long before improvements show in Search Console?

Typically several weeks, because field data uses a rolling 28-day window at the 75th percentile. Changes deployed today only fully reflect once the window has rolled past the pre-fix period. Lab tools show the improvement immediately, which is useful for confirming the fix worked while you wait for field data.

Does a CDN fix Core Web Vitals?

It helps LCP by reducing distance for static assets and can improve TTFB, but it does not address INP at all, since INP is about JavaScript execution on the user's device. If your server is already in-region for your audience, a CDN's benefit is smaller than usually claimed. It is not a substitute for compressing images or removing scripts.

Why do my scores look fine but Search Console says poor?

Most likely you are testing on a fast device and connection while your users are not. A large share of Indian traffic is on mid-range Android phones where JavaScript executes several times slower. Test with aggressive CPU throttling or on a real mid-range device, and remember field data reflects your slower quartile, not your median.

Does server location affect Core Web Vitals?

Significantly, through TTFB, which is a direct component of LCP. A user in India reaching a Mumbai server sees a round trip of tens of milliseconds; the same user reaching a US server sees over 250, compounded across every request in a page load. For an India-focused site on overseas hosting, moving in-region is frequently the single largest available improvement.

Should I remove my page builder to improve performance?

Not necessarily, but audit what it generates. Page builders produce deeply nested markup and often load their full CSS and JavaScript on every page, which hurts both INP and LCP. Check whether your builder offers asset optimisation or per-page conditional loading before considering a rebuild, since migration carries its own risks.

Conclusion

Three metrics, three different problems. LCP is mostly about bytes and server response. INP is about JavaScript. CLS is about reserving space.

For most Indian business sites, the highest-leverage work is unglamorous and quick: compress the hero image and stop lazy-loading it, enable full-page caching, set dimensions on every image, reserve space for anything that loads late, and delete the third-party scripts nobody uses. That list resolves the majority of failures and takes an afternoon.

INP is the one that will require actual investigation, and the tools most people use cannot see it. Get real-user data, test on a throttled mid-range Android device rather than your laptop, and expect the answer to be one or two plugins.

The India-specific point is worth repeating: if your audience is here and your server is not, distance is costing you more than any front-end optimisation will recover. Fix that first, then optimise.

And keep the ranking effect in proportion. These are minor signals. The reason to do the work is that your users are on modest phones over variable networks, and the experience they are getting is worse than the one you are testing.

HostCloud runs LiteSpeed with server-level caching, HTTP/3, Brotli and NVMe storage on Indian infrastructure, which addresses the TTFB and distance half of this directly. Plans start at ₹99 a month at https://hostcloud.in, with free migration if you are moving from an overseas server.