Core Web Vitals Optimization: Fix LCP, INP and CLS Where Real Users Feel Them
A green PageSpeed score is not a pass. We diagnose Core Web Vitals from real-user field data, fix the causes template by template, and validate the result where Google actually measures it.
Get Your Free Core Web Vitals Audit
See exactly what is holding your rankings back — reviewed by our team, no obligation.
By Khushbu Solanki, Founder, AmplifyKlicks · 16+ years in SEO & digital marketing · Updated September 2026
Why Your Site Can Score 90 and Still Fail
Most business owners check speed the same way: run the homepage through PageSpeed Insights on a fast office connection, see a green number, and assume the job is done. Then Search Console reports dozens of URLs as “Poor” and nobody can reconcile the two.
Both are telling the truth about different things. The score is a lab test: one simulated page load under fixed conditions. Core Web Vitals, as Google assesses them, are field data: what real Chrome users experienced on their own phones and networks over the last 28 days. A visitor in Vadodara on a three-year-old Android handset, on a congested 4G connection, experiences your site very differently from a Lighthouse run on a laptop.
Definition
Core Web Vitals are three metrics Google uses to measure real-world page experience: Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability. A page passes when the 75th percentile of real visits meets the “good” threshold for all three, assessed separately for mobile and desktop.
Core Web Vitals optimization is one discipline inside our wider technical SEO programme. It is also the one where the gap between what agencies promise and what real users experience is widest — which is exactly why we work from field data first.
The Three Metrics, the Thresholds, and What Usually Breaks Them
| Metric | What it measures | Good | Poor | Most common causes we find |
|---|---|---|---|---|
| LCP | Time until the largest image or text block in the viewport is rendered | ≤ 2.5 s | > 4.0 s | Uncompressed hero images or sliders, slow server response, render-blocking CSS and JS, lazy-loaded hero image, web fonts delaying text |
| INP | Delay between a tap, click or key press and the next visual update, across the whole visit | ≤ 200 ms | > 500 ms | Long JavaScript tasks, chat and tracking scripts, page-builder bloat, heavy event handlers, very large DOM |
| CLS | How much visible content unexpectedly moves while the page is used | ≤ 0.1 | > 0.25 | Images and embeds without dimensions, late-loading banners and cookie bars, ads without reserved space, font swaps |
Values between the two thresholds are rated “needs improvement”. Interaction to Next Paint replaced First Input Delay in March 2024, and it is considerably stricter: FID only measured the first interaction, while INP reflects close to the slowest interaction in a visit. Many sites that comfortably passed FID now fail INP without anything on the site having changed.
Do Core Web Vitals Actually Affect Rankings?
Yes — but we would rather give you the accurate answer than the one that sells a project. Core Web Vitals are part of Google’s page experience signals. Google has been consistent that relevance and helpfulness outweigh them: a fast page with thin content will not outrank a slower page that answers the query better. In competitive results where several pages are comparably relevant, experience can help separate them.
The bigger, more dependable return is commercial. Slow, jumpy, unresponsive pages lose visitors before they read anything, and lose buyers at the moment they tap “Enquire” or “Add to cart”. That is why we treat Core Web Vitals as a shared metric between SEO and our CRO programme rather than a box to tick for Google.
If an agency guarantees ranking gains from Core Web Vitals work alone, be cautious. What good performance reliably does is remove a handicap and protect conversion rate. Rankings then depend on everything else being right too.
Field Data vs Lab Data: Where We Measure
| Source | Type | What we use it for |
|---|---|---|
| Search Console Core Web Vitals report | Field (CrUX) | Which groups of similar URLs pass or fail on mobile and desktop, and confirmation after fixes via Validate Fix |
| Chrome UX Report / PageSpeed field section | Field | 75th-percentile values per URL or origin over 28 days; the numbers Google actually assesses |
| Real-user monitoring (web-vitals library) | Field, your own | Attribution: which element is the LCP, which interaction causes poor INP, which element shifts. Essential for INP |
| Lighthouse / PageSpeed lab section | Lab | Reproducible diagnosis and immediate before/after checks while fixing |
| Chrome DevTools Performance panel | Lab | Tracing long tasks, render-blocking resources and layout shifts frame by frame |
Two practical notes. Low-traffic pages often have no URL-level field data, so Google falls back to the origin (whole-site) figures — which is why fixing shared templates matters more than polishing one page. And lab tools cannot measure INP directly, because there is no real user interacting; Total Blocking Time is only a proxy. For INP, real-user monitoring is not optional.
How We Fix LCP
We break Largest Contentful Paint into its four sub-parts, because each has different causes and a different fix. Optimising the wrong one wastes weeks.
| LCP sub-part | What it is | Typical fixes |
|---|---|---|
| Time to First Byte | Server response before anything can load | Page caching, faster hosting or server in India, CDN edge caching, fewer redirects, database and backend tuning |
| Resource load delay | Time before the browser even starts fetching the LCP image | Put the image in the HTML (not CSS or JS), fetchpriority="high", preload where needed, never lazy-load the hero |
| Resource load duration | Time to download the LCP resource | WebP or AVIF, correct dimensions, responsive srcset, compression, CDN delivery |
| Element render delay | Time between download and paint | Remove render-blocking CSS and JS, inline critical CSS, defer non-essential scripts, avoid client-side-only rendering of the hero |
On the Vadodara business sites we audit, the single most common LCP failure is a homepage slider: several full-width images, loaded by a JavaScript library, with the first slide lazy-loaded. Replacing it with one properly sized, prioritised static image often fixes LCP on its own.
How We Fix INP
INP failures are almost always JavaScript competing for the browser’s main thread at the moment a user interacts. Our work typically covers:
- Third-party script triage. Chat widgets, multiple analytics and ad pixels, heatmaps, review widgets and embedded maps. Each is audited for business value versus main-thread cost, then removed, delayed until interaction, or loaded behind a lightweight facade.
- Breaking up long tasks. Any task over 50 ms blocks interaction. We split heavy work and yield back to the main thread so input can be handled between chunks.
- Event handler cost. Menus, filters, add-to-cart buttons and form validation that run far more work than needed on every tap.
- DOM size. Page builders can produce pages with many thousands of elements; every interaction that triggers layout pays for all of them.
- Framework hydration. On React, Next.js and similar builds, reducing or deferring hydration of components that are not immediately interactive.
How We Fix CLS
- Explicit
widthandheight(or aspect-ratio) on every image, video and iframe. - Reserved space for anything injected later: cookie banners, promotional bars, ad slots, review widgets and “WhatsApp us” buttons.
- Font loading that does not reflow text: preloaded, self-hosted fonts with matched fallback metrics.
- No content inserted above what the user is already reading, except in direct response to their action.
- Back/forward cache eligibility, so returning visitors get an instant, shift-free page instead of a fresh load.
Our Core Web Vitals Process
- Field baseline by template. We group URLs the way Search Console does — homepage, service pages, blog posts, product and category pages — and record 75th-percentile LCP, INP and CLS for each on mobile and desktop.
- Real-user attribution. Where traffic allows, we add lightweight real-user monitoring so we can see which element, script or interaction causes each failure instead of guessing.
- Diagnosis. Lab traces reproduce each problem and isolate the cause: the LCP sub-part at fault, the long tasks behind INP, the elements shifting.
- Prioritisation. Fixes are ranked by templates affected × traffic × business value, so the change that repairs 400 product pages beats the one that perfects the About page.
- Implementation. We implement directly, or write developer-ready tickets with the exact change, the expected effect and how to test it, working alongside your existing developer.
- Validation. Lab checks confirm each fix immediately. Field data confirms it over the following 28 days, and we trigger Validate Fix in Search Console.
- Regression guardrails. A performance budget and monitoring, because the next plugin, pixel or banner is usually what breaks a passing site again.
Platform-Specific Notes
| Platform | Where the problems usually are |
|---|---|
| WordPress | Page builders, plugin overload, missing page caching, shared hosting. We cover this in depth in our WordPress-specific speed optimisation service. |
| WooCommerce | Cart fragments on every page, heavy product galleries, uncached dynamic pages, filter plugins |
| Shopify | App scripts accumulating in the theme, oversized theme sections, third-party review and upsell widgets |
| React / Next.js | Client-side rendering of above-the-fold content, large bundles, hydration cost driving poor INP |
| Magento / custom PHP | Slow server response and full-page cache configuration, unoptimised theme JavaScript |
For online stores, performance work is coordinated with store-level ecommerce SEO, since product and category templates carry most of the revenue and most of the URLs.
The India Factor
Core Web Vitals are measured on your actual visitors, and for most Indian businesses that means mobile-first traffic on mid-range Android devices with variable network quality. Three things follow:
- Test on mobile, throttled. A site that feels instant on a MacBook in an office can fail badly on the devices your customers use.
- Server location matters. Hosting on a budget server in another continent adds latency to every request before a single byte of content arrives. A server or CDN edge in India shortens that distance.
- JavaScript costs more on cheaper phones. The same script that takes 80 ms on a flagship can take several times longer on an entry-level handset — which is why INP failures cluster on mobile.
What You Receive
- A field-data baseline for every template, mobile and desktop, for all three metrics
- A root-cause diagnosis for each failing template, with evidence
- A prioritised fix list scored by impact and effort, or the fixes implemented directly
- Before-and-after lab measurements for every change
- Field-data confirmation after the 28-day window and Search Console validation
- A performance budget and a short list of rules to stop regressions
If you are not sure performance is your main problem, start with a technical SEO audit service that weighs speed against crawling, indexing and content issues before you spend on any one of them.
This service is delivered by AmplifyKlicks, alongside our full range of digital marketing services, as part of our SEO company in Vadodara and our wider AI digital marketing in Vadodara practice.
Mistakes We See Before Clients Come to Us
- Chasing a 100 score. The score is a lab diagnostic. Aggressive “delay all JavaScript” settings can hit 100 while breaking menus, forms and tracking.
- Optimising only the homepage. Google assesses groups of URLs. Service, product and blog templates usually carry more traffic.
- Stacking optimisation plugins. Two caching or minification plugins fight each other and create new failures.
- Lazy-loading everything. Lazy-loading the hero image directly worsens LCP.
- Ignoring third parties. Your code can be clean while a chat widget ruins INP.
- Declaring victory on day one. Field data needs 28 days. A fix is only confirmed when real users confirm it.
Core Web Vitals FAQs
Are Core Web Vitals a Google ranking factor?
Yes, as part of Google’s page experience signals, but a modest one. Google has said relevance and content quality come first, so a fast page with weak content will not outrank a slower page that answers the query better. The larger and more reliable effect of good Core Web Vitals is on bounce rate, engagement and conversions.
Why does PageSpeed Insights show a good score but Search Console says my pages fail?
The score is lab data from a single simulated load. Search Console uses field data: the 75th percentile of real Chrome users over the previous 28 days, on their actual devices and networks. A page can score well in the lab and still fail for real mobile visitors on slower phones and connections. Field data is what Google uses for Core Web Vitals assessment.
How long does it take for Core Web Vitals fixes to show in Search Console?
Lab tools reflect a fix immediately, but field data is a rolling 28-day window, so Search Console typically takes around four weeks to show the full effect. When you click Validate Fix, Google monitors the affected URLs over a 28-day period before confirming the issue is resolved.
What replaced First Input Delay?
Interaction to Next Paint (INP) replaced First Input Delay as a Core Web Vital in March 2024. FID only measured the delay before the first interaction was processed. INP measures the responsiveness of all interactions during a visit and reports close to the worst one, which makes it a much stricter test of JavaScript-heavy pages.
Do I need a new website to pass Core Web Vitals?
Usually not. Most failures come from a small number of causes, such as an oversized hero image, render-blocking scripts, heavy third-party widgets or images without dimensions, and these can be fixed on the existing site. A rebuild only makes sense when the theme or platform itself is the bottleneck and fixes would cost more than replacing it.
Is a 100 PageSpeed score necessary?
No. The PageSpeed score is a lab diagnostic, not a ranking metric. The goal is for real users to experience LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less at the 75th percentile. Chasing a perfect score often leads to fragile optimisations that break functionality without improving what visitors experience.
Failing Core Web Vitals in Search Console?
Send us your site. We will pull your field data, identify which templates fail and why, and tell you what fixing them involves before you commit to anything.
\n
\n