Core Web Vitals get more attention than their ranking weight deserves and less than their user-experience weight deserves. Both are true. In this part of my technical SEO guide, I explain the three metrics the way I explain them to engineering teams: what each measures, what usually causes a bad score, and how to decide what is worth fixing.
What Core Web Vitals are, and what they are not
Core Web Vitals are three field metrics Google uses in its page experience signals: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS). INP replaced First Input Delay. Each has a "good" threshold, and Google assesses a page (or group of similar pages) on whether the 75th percentile of real users clears it.
They are a ranking factor, but a modest one. A page with poor vitals and excellent content will usually outrank a page with perfect vitals and weak content. Vitals matter most in two situations: near ties between comparable pages, and sites so slow that users bounce before the content loads. The second is far more common in India than teams on fibre connections in Bangalore offices tend to believe.
The three metrics, with causes and fixes
Largest Contentful Paint (LCP)
LCP measures how long the largest visible element (usually a hero image, a large heading, or a block of text) takes to render after the user starts loading the page. The "good" threshold is 2.5 seconds.
In my experience, bad LCP traces back to one of four things: a slow server response, render-blocking CSS and JavaScript in the head, a hero image that is too large or loaded late (often lazy-loaded or injected by JavaScript), or web fonts that delay text painting. On ecommerce sites built on heavy themes, I regularly see all four at once.
Interaction to Next Paint (INP)
INP measures the delay between a user's interaction (tap, click, key press) and the next visual update, across the whole visit, reporting one of the slowest. The "good" threshold is 200 milliseconds.
Poor INP is nearly always a main-thread problem: JavaScript that runs too long and blocks the browser from responding. Typical culprits are third-party tags (analytics, chat widgets, A/B testing, ads), heavy framework hydration, event handlers doing expensive work synchronously, and large DOM trees. INP is where mobile hardware matters most: a mid-range Android phone executes the same script several times slower than a developer's laptop.
Cumulative Layout Shift (CLS)
CLS measures how much visible content moves unexpectedly during the page's life. The "good" threshold is 0.1. It is the metric users feel most sharply: you go to tap a button and an ad pushes it down.
Causes are mechanical and predictable: images and embeds without dimensions, ads and banners injected without reserved space, web fonts swapping and changing text size, content inserted above existing content (cookie bars, promo strips), and animations that move layout properties instead of using transforms.
| Metric | Common cause | Fix |
|---|---|---|
| LCP | Slow server response (high TTFB) | Cache HTML at the CDN or server, reduce database work per request, use a CDN with Indian edge locations |
| Render-blocking CSS/JS | Inline critical CSS, defer non-critical scripts, remove unused CSS from frameworks | |
| Hero image late or oversized | Never lazy-load the LCP image; add fetchpriority="high" and a preload; serve modern formats at the right size | |
| Web fonts delaying text | Use font-display: swap or optional, preload the one font file you need, consider system fonts | |
| INP | Third-party scripts on the main thread | Audit every tag; remove what nobody uses; load the rest after interaction or in a worker |
| Long JavaScript tasks and heavy hydration | Break long tasks up, hydrate only interactive components, reduce bundle size, server-render more | |
| Expensive event handlers | Debounce input handlers, move heavy work off the interaction path, update the UI first and compute later | |
| CLS | Images and embeds without dimensions | Always set width and height (or aspect-ratio) so the browser reserves the space |
| Injected ads, banners, cookie bars | Reserve a fixed slot, or overlay instead of pushing content down | |
| Font swap changing text metrics | Match fallback font metrics, preload the font, limit the number of weights loaded |
Lab data versus field data
This distinction causes more wasted effort than anything else in performance work.
Lab data comes from a tool (Lighthouse, PageSpeed Insights' lab section, WebPageTest) loading your page once on a simulated device and connection. It is reproducible and great for debugging. It is not what Google ranks on, and it often differs wildly from what users experience on their own devices and networks.
Field data comes from real users' browsers reporting what actually happened. This is what Google uses. The public source is the Chrome User Experience Report (CrUX), aggregated from opted-in Chrome users, visible in Search Console's Core Web Vitals report, the top of PageSpeed Insights, and the CrUX API and BigQuery dataset.
The rule I apply: diagnose in the lab, decide in the field. A Lighthouse score of 95 on your laptop means nothing if CrUX shows LCP at four seconds for your mobile users. Equally, a poor Lighthouse score on a page with good field data is not an emergency.
Why Indian mobile conditions change the priorities
Most Indian web traffic is mobile, and a large share of those devices are budget and mid-range Android phones on variable 4G connections. Two consequences follow.
First, JavaScript cost is multiplied. A bundle that hydrates quickly on a flagship phone can take several times longer on a device with a slower processor and less memory. INP problems invisible in a Gurgaon office are routine for users in tier-2 and tier-3 cities.
Second, bytes matter more. Every unneeded image kilobyte, unused CSS rule and third-party script is paid for on a network that may be slow and metered. A page that is "fast enough" on office wifi can be unusable on a congested cell.
When I work with D2C brands, marketplaces or publishers targeting a national Indian audience, I set performance budgets against a mid-range Android profile and a throttled connection, not the desktop Lighthouse run. For regional-language audiences there's an extra wrinkle: web fonts for Devanagari and other scripts are large, so font loading becomes a first-order LCP and CLS question.
What to fix first
Find the templates that fail in the field
Open the Core Web Vitals report in Search Console and group failing URLs by template. One or two templates usually account for most of the problem.
Fix server response time
If TTFB is slow, nothing downstream can be fast. Caching HTML and using a CDN with edges near your users is the highest-leverage LCP fix on most sites, and it also helps crawl capacity (see crawlability and indexability).
Fix the LCP element directly
Identify the LCP element on each template (Lighthouse tells you), then make sure it is in the initial HTML, not lazy-loaded, correctly sized and prioritised.
Cut third-party JavaScript
Usually the biggest INP fix and the hardest politically, because every tag has an owner. Make a list, find out who uses what, and delete or defer the rest.
Reserve space for everything that loads late
Dimensions on images, fixed slots for ads and embeds, metrics-matched fallback fonts. CLS fixes are mechanical and rarely regress once templates are correct. Only after all this is micro-optimisation (image formats, resource hints, bundle splitting) worth the time.
Diminishing returns: knowing when to stop
Once a template passes all three thresholds in the field, further performance work has very little SEO value. Google's assessment is pass or fail at the threshold, not a continuous score, so moving LCP from 2.3s to 1.4s doesn't improve your standing. It may improve conversion rate, which can justify the work on its own terms, but that is a product decision, not an SEO one.
I've seen teams spend months chasing a Lighthouse score of 100 while their category pages sat at click depth seven and their canonicals pointed at redirects. Performance is one part of a system. Once it's good enough, move the effort to the part that isn't, usually architecture or internal linking.
The exception is JavaScript-heavy sites, where the hydration cost that hurts INP can also delay or break rendering for Googlebot. I tested this in the JavaScript rendering test, and cover the rendering side in the JavaScript SEO guide.
Frequently asked questions
How much do Core Web Vitals affect rankings?
They are a real but small ranking signal, most relevant when comparable pages compete. Content relevance, links and site structure matter far more. Where poor vitals really hurt is user behaviour: slow pages lose visitors before the content loads.
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 reports field data from real users, mostly on mobile devices and slower networks. Field data is what Google uses. Trust it over the score, and use lab tools to work out why real users see slow loads.
Should I lazy-load all images?
Lazy-load images below the fold, but never the hero or LCP image. Lazy-loading the largest visible image is one of the most common self-inflicted LCP problems I see, often from a plugin or theme setting applied to everything.
Does a page builder or theme make it impossible to pass Core Web Vitals?
Not impossible, but harder. Heavy themes load CSS and JavaScript for features you don't use. You can usually pass by caching aggressively, removing unused modules, fixing the LCP image and cutting third-party tags. Sometimes a lighter template is cheaper than endless patching.
How long after fixing do the Search Console reports update?
CrUX is a rolling 28-day window, so field data needs roughly a month of post-fix traffic before a template moves fully from "poor" to "good". You can confirm the fix immediately in lab tools and in your own real-user monitoring.
Where this connects
This guide belongs to the technical SEO hub. Performance checks sit alongside crawl and index checks in my technical SEO audit framework; the interaction between heavy JavaScript and what Google sees was measured in the JavaScript rendering test; the technical SEO and content architecture case study shows performance work inside a larger rebuild; and if you'd rather have it implemented than diagnosed, see my technical SEO services.