Most Core Web Vitals advice tells you to chase a green score. That is the wrong goal. This core web vitals guide covers the three things Google measures, what actually causes each one to fail on Indian business websites, and which fix earns back the most money for the least work.
If your site was built cheaply on a page builder and then loaded with plugins and three tracking scripts, you already know the feeling. It looks fine on your laptop and crawls on a mid-range Android phone on mobile data. That gap is where enquiries disappear. Our website development work starts with the checks below, because a slow site quietly taxes every rupee you spend on ads.
What are Core Web Vitals, in plain business terms?
Core Web Vitals are three measurements of how a page feels to a real visitor on a real phone. LCP asks how long until the main content appears. INP asks how fast the page responds when someone taps. CLS asks whether the layout jumps while it loads.
Google publishes a pass mark for each one. LCP should finish within 2.5 seconds, INP should stay under 200 milliseconds, and CLS should stay under 0.1. A page passes only when 75 percent of real visits meet the mark.
One correction worth making: INP replaced First Input Delay in March 2024. If your developer is still reporting FID numbers, the report is out of date and so is the fix list attached to it.
Do Core Web Vitals actually affect your Google rankings?
Yes, but weakly. Google uses page experience as a tiebreaker between pages of similar relevance and quality. A slow page with the best answer still outranks a fast page with a thin one. The bigger and more provable return is conversion: fewer people abandon a page that loads and responds.
We do not guarantee rankings, and nobody honest does. Speed work has two payoffs with very different levels of certainty. The ranking payoff is small and situational. The conversion payoff shows up in your own enquiry count, and you can measure it yourself inside a month.
So treat vitals as hygiene, not strategy. If your pages are not ranking at all, the cause is usually content, search intent or authority rather than milliseconds. We cover the usual reasons a page sits still in search separately, and speed sits low on that list. Fixing vitals will not rescue a page that answers the wrong question.
LCP, INP and CLS: what actually breaks each one
LCP: the wait before anything useful appears
LCP measures when the largest element in the first screen finishes rendering. On most Indian business sites that element is a hero banner, a slider image or a large heading block. Four causes explain nearly every failure we test.
An uncompressed hero image of 1 MB or more. A slider or animation library that must run before the image is even requested. A slow first response from crowded shared hosting. CSS or fonts that block rendering while the browser waits for a third-party server.
INP: the tap that does nothing
INP measures the delay between a tap and the visible response, across the whole visit rather than the first click. It fails when the browser is busy running JavaScript and cannot repaint. Page builders, chat widgets, popup plugins and tag managers all compete for the same single thread.
The classic symptom is a mobile menu that opens half a second after the tap. The visitor taps again, the menu closes, and they decide your business is careless. That is a lost enquiry, not a lost score. It is a common failure on page builder sites, and it is rarely fixed by a caching plugin.
CLS: the button that moves as you reach for it
CLS measures unexpected layout shifts after painting has started. Images with no width and height set, offer strips injected above the fold, cookie bars and late-loading fonts all push content down the page. On an enquiry form or a checkout, that means wrong taps and abandoned sessions.
Symptom to cause: what the complaint is telling you
You do not need a testing tool to start. Most owners already know what annoys them about their own site, and the annoyance points straight at the metric. Match the symptom to the likely cause before you pay anyone to investigate it.
| What you or a customer notices | Metric it hurts | Most likely cause | First fix to try |
|---|---|---|---|
| Text appears, then the banner drops in seconds later | LCP | Heavy hero image, or an image loaded by a slider script | Serve one compressed WebP hero directly in the HTML, drop the slider |
| Page looks ready but the menu and buttons ignore the first tap | INP | JavaScript from the page builder, chat widget and tag manager | Remove what nobody uses, defer the rest until after first paint |
| Text loads in one font, then flicks to another | LCP and CLS | Web fonts pulled from a third-party server with no fallback sizing | Self-host two weights, set font-display and a size-matched fallback |
| Customer taps a button and lands on the wrong page | CLS | Offer bars, ads or notices injected above content after load | Reserve fixed height for every injected block and every image |
| Fine on office wifi, painful on mobile data | All three | Total page weight and too many separate requests | Cut image weight first, then unused plugins, then scripts |
Test on a mid-range Android handset on a normal mobile connection, not on your laptop. For most Indian business sites, a large share of traffic arrives that way. If you only ever check the site on office wifi, you will never see what your customers see.
A core web vitals guide to images, fonts, scripts and tags
Four categories cause the large majority of failures we find. Work through them in this order, because each one makes the next easier to measure.
Images come first because they are usually the heaviest thing on the page and the cheapest to fix. Resize to the size actually displayed, convert to WebP, and set width and height attributes so the browser reserves space. Lazy load everything below the first screen, but never the hero image, since lazy loading the hero makes LCP worse.
Fonts are the quiet offender. Every extra weight is another file the browser fetches before it paints text. Two weights are enough for almost any business site. Self-host them, set font-display to swap, and pick a system fallback with similar metrics so the swap does not shove the layout.
Heavy JavaScript on the main thread is the main reason INP fails, and scripts that block rendering make the first moments worse. Anything in the head that is not needed to draw the first screen should be deferred or removed. Audit the plugin list honestly: the sliders, counters, popups and animation libraries added over three years are usually still loading on every page. A deeper walkthrough sits in our notes on making an existing site faster.
Third-party tags are the ones owners forget. A Meta Pixel, Google Tag Manager container, WhatsApp chat button, Razorpay checkout script and a review widget each add JavaScript the browser must fetch, parse and run before it can respond to a tap. Keep the tags that feed a decision you actually make, load them after the page is interactive, and delete the rest.
- Every image resized, compressed to WebP, and given width and height in the HTML.
- Hero image loaded eagerly, everything below the fold lazy loaded.
- Two self-hosted font weights, font-display swap, size-matched fallback.
- Nothing in the head that is not needed to render the first screen.
- Chat, pixel and analytics tags fired after the page becomes interactive.
- Fixed height reserved for offer strips, banners and cookie notices.
- Core Web Vitals report in Search Console checked once a month.
What should you fix first?
Fix in this order: images, then render-blocking scripts, then third-party tags, then fonts, then layout stability. Images are usually the largest single part of the problem and cost the least to solve. Do not start with server upgrades or a full rebuild until the cheap wins are done and measured.
- Test three pages, not one: your home page, your best service page, and the page your ads point to.
- Resize and compress every image on those pages, then set width and height attributes.
- Deactivate plugins and scripts nobody uses. Each removal helps INP more than any caching setting will.
- Defer what remains, so chat widgets, pixels and analytics load after first paint.
- Self-host fonts, cut to two weights, and set a fallback that matches in size.
- Reserve space for anything injected late: offer bars, banners, cookie notices.
- Re-test after 28 days and judge the result on field data, not the lab score.
That sequence handles most sites. If you are not sure which page carries the most revenue, send us the URL and a note about your traffic and we will tell you which one to fix first. We reply within one business day.
Sometimes the honest answer is that the platform is the problem. A theme with a builder stacked on top of it, plus twenty plugins, cannot be tuned into a fast site. When the fix list keeps growing, compare the cost of patching against a rebuild, and read our take on choosing between WordPress and a custom build before you commit.
Why do PageSpeed Insights and your own phone disagree?
PageSpeed Insights shows two different things. The lab test is a simulation run once on a throttled device. The field data is what real Chrome users experienced over the previous 28 days, reported at the 75th percentile. Ship fixes against the lab, but judge success on the field numbers.
Low-traffic sites often show no field data at all. That is normal and not a fault. Use the lab score for direction, and watch the Core Web Vitals report in Search Console as traffic builds.
Field data also moves slowly. Because it is a rolling 28-day window, a fix deployed today shows up gradually over the following month. Do not panic on day three and undo the work. Track enquiry rate in the same period, since that is the number your business actually runs on.
Free tools cover most of this. Paid monitoring and audit tools exist. Their pricing changes often, so check the vendor's own page before subscribing. Vitals also sit inside a wider list of technical fixes, which we set out in our technical checklist for service businesses.
Frequently asked questions
Is a green PageSpeed score worth chasing?
Not for its own sake. The score is a lab summary of one simulated load. The pass or fail Google uses comes from real visits. A site can score 95 in the lab and still fail INP for actual customers, so aim to pass the three thresholds in field data.
Can I fix Core Web Vitals on WordPress without rebuilding the site?
Usually yes. Image compression, plugin removal, script deferral and font hosting fix most WordPress sites without touching the design. A rebuild becomes the better option when the theme and builder generate the bloat themselves, or when the site is several years old.
How long does Core Web Vitals work take?
Most fixes on an existing site land within two to four weeks, with weekly checkpoints so you see progress. Because field data updates on a 28-day rolling window, allow a further month before judging the result. A full rebuild follows our usual six to twelve week range.
Does a faster site help my Google Ads too?
It helps the part you control. Landing page experience feeds into Ad Rank, and a page that responds quickly wastes fewer clicks. If you are paying for traffic, slow pages are a direct cost, not a technical detail.
Where to start this week
Open PageSpeed Insights, test your top three pages on mobile, and write down the largest image on each. That single list usually explains most of your LCP problem. Then count the third-party scripts loading on every page and ask which of them you have looked at in the last six months.
Vitals are worth fixing because they cost you enquiries, not because Google awards points for them. Our team does this work for businesses across Pune and Pimpri-Chinchwad, and for Vadodara clients served from the same Akurdi office, whether as standalone speed work or as part of a new build handled by our Pune team. It also supports the wider search work we run alongside it.
If you want a straight answer about your own site, tell us what it is doing and on which pages. We will look at the three metrics, name the two changes worth making first, and be clear about what speed will and will not do for your rankings.
