Chirag DigitalCore Web Vitals are three measurements Google uses to judge how fast and stable a page feels to a real visitor: how quickly the main content appears, how quickly the page responds when tapped, and whether things jump around while loading. They are a minor but real ranking factor, and a major factor in whether a visitor stays or leaves — especially on the mid-range phones and patchy mobile data most Indian users are browsing on. You do not need to understand the engineering behind them to fix what is slow.
This sits alongside the on-page SEO work most small business sites need — it is the part that happens after the words on the page are right.
Why this matters beyond rankings
Google has confirmed Core Web Vitals are a ranking signal, but a small one — good content on a slow page still outranks thin content on a fast one. The bigger cost is behavioural. A page that takes more than three seconds to show anything loses a large share of visitors before they see it, and every extra second after that compounds the loss. On a ₹10,000 phone over 4G in a market with patchy coverage, the gap between a fast and a slow site is often the difference between a lead and a bounce.
The three metrics, without the jargon
| Metric | What it actually measures | Good | Needs work | Poor |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | How long until the biggest visible thing on the page — usually a hero image or heading — has fully loaded | Under 2.5 seconds | 2.5–4 seconds | Over 4 seconds |
| INP (Interaction to Next Paint) | How long the page takes to visibly respond after a tap or click | Under 200 milliseconds | 200–500 milliseconds | Over 500 milliseconds |
| CLS (Cumulative Layout Shift) | Whether elements jump around as the page loads — the button that moves right as you were about to tap it | Under 0.1 | 0.1–0.25 | Over 0.25 |
In plain terms: LCP is "how long until it looks loaded," INP is "how long until it actually works," and CLS is "how much it jumps around while doing both."
How to check your own score, free
- Go to PageSpeed Insights (pagespeed.web.dev) and enter your homepage URL. Check the mobile score first — that is the one Google actually uses for ranking, and it is almost always worse than desktop.
- Look at the top summary for pass or fail on each of the three metrics, not the 0–100 performance score. The pass/fail is what affects rankings; the number underneath it is a general performance grade that includes things outside Core Web Vitals.
- In Google Search Console, open the Core Web Vitals report under Experience. This shows real visitor data across your whole site, not a single test — it is slower to update but far more representative than a one-off PageSpeed check.
- Repeat this for your two or three highest-traffic pages, not just the homepage. A fast homepage with a slow product or service page still loses those visitors.
What actually slows down small business sites in India
- Uncompressed images. A phone photo straight from a camera can be 4–8 MB. A properly compressed version of the same image looks identical at 150–300 KB. This is the single most common cause of a poor LCP score.
- Too many WordPress plugins. Each one loads its own script, and most small business sites accumulate plugins nobody remembers installing. Five to ten plugins is normal; twenty-five is common, and each one adds load time.
- Third-party embeds. Chat widgets, review badges, embedded videos and ad scripts each fetch code from someone else's server before your page can finish loading. Useful individually, expensive in combination.
- No caching. Without caching, the server rebuilds the page from scratch for every single visitor instead of serving a pre-built copy. This is usually a one-time setup, not an ongoing cost.
- Cheap shared hosting. A ₹99-a-month hosting plan is sharing server resources with hundreds of other sites. This is often the actual bottleneck underneath every other fix, and no amount of image compression fixes a server that is simply overloaded.
- Web fonts loading before text can render. Custom fonts that block the page from showing any text until they arrive are a common, invisible cause of a slow LCP.
Fixes, ranked by effort versus impact
| Fix | Effort | Typical impact |
|---|---|---|
| Compress and resize images before uploading | Low | High |
| Enable a caching plugin (WP Rocket, LiteSpeed Cache, W3 Total Cache) | Low | High |
| Remove unused plugins and themes | Low | Medium |
| Lazy-load images below the fold | Low–medium | Medium |
| Move to better hosting or add a CDN | Medium | High |
| Defer non-essential third-party scripts (chat widgets, ad tags) | Medium | Medium |
| Reduce custom font weights and preload the main one | Medium | Low–medium |
| Rebuild a bloated page template | High | Varies |
Start at the top. The first three rows alone resolve most small business sites' worst scores, and none of them require touching code.
The score you actually need, not a perfect one
Chasing a 100 on PageSpeed Insights is usually wasted effort past a certain point — Google's actual threshold is passing "Good" on all three Core Web Vitals, not a perfect performance score. A site sitting at 78 with all three metrics in the green is in better shape for both rankings and real visitors than a site obsessing over minor gains toward 100. Diminishing returns set in fast once you clear the "Good" bar — spend the remaining effort on content and links instead.
A worked example: a real estate agent's site
Before: LCP 5.8 seconds, CLS 0.31, hosted on a shared ₹149/month plan, twelve plugins, hero images averaging 3.2 MB uncompressed.
Changes made in one afternoon: compressed all images (average dropped to 220 KB), removed four unused plugins, installed a caching plugin, and added explicit width and height attributes to images so the layout stopped shifting while they loaded.
After, one week later: LCP 2.3 seconds, CLS 0.04. Both metrics moved from Poor to Good with no hosting change and no code written. Average time on listing pages increased by 40 seconds, and enquiry form submissions rose over the following month — a plausible result of visitors staying long enough to actually browse listings rather than a proven causal link, but consistent with what speed improvements usually produce.
Frequently asked questions
Will fixing Core Web Vitals alone improve my rankings significantly?
Rarely on its own. It is a tiebreaker-level signal, not a major one — strong content and relevant on-page SEO matter far more. Fix it because slow pages lose visitors, and treat any ranking improvement as a bonus.
Do I need a developer to fix this?
For the highest-impact fixes — image compression, caching, removing plugins — no. Most of it is done through your CMS or hosting dashboard. A developer becomes worth it only for the "rebuild a bloated template" tier of fixes.
Why is my mobile score so much worse than desktop?
Mobile testing simulates a mid-range phone on a throttled connection deliberately, because that better represents real-world conditions for most visitors, especially in India. A site that feels instant on office wifi and a laptop can still fail Core Web Vitals on mobile.
How often should I recheck my score?
Monthly is enough for most small sites, and always after adding a new plugin, widget or major image-heavy page — those are the changes most likely to quietly undo previous fixes.
Does switching to WordPress hurt page speed compared to a custom site?
Not inherently — a well-configured WordPress site with a caching plugin and a light theme can score as well as a custom build. The plugin count and hosting quality matter far more than the platform itself.
Where to start
Run your homepage and your busiest service or product page through PageSpeed Insights today, and note which of the three metrics fails. Then work down the effort-versus-impact table above, starting with image compression and caching — most sites see a meaningful jump from those two alone.
If chasing this down isn't a good use of your time, that's part of what our SEO audit covers, and a free audit will show you exactly which fixes your site needs first.