Core Web Vitals for Indian users, explained

Most websites are built and reviewed on a fast laptop over office Wi-Fi. Most visitors in India arrive on a mid-range Android phone over a mobile connection. That gap is where speed problems hide — and where Google’s Core Web Vitals can help you see what your real users experience.

The three Core Web Vitals

Google measures three things, based on real visits to your site (field data from Chrome users), and judges each at the 75th percentile — meaning three out of four visits should hit the “good” mark.

Metric	What it measures	“Good” threshold
LCP — Largest Contentful Paint	How long until the main content (usually the hero image or headline) appears	2.5 seconds or less
INP — Interaction to Next Paint	How quickly the page responds when someone taps, clicks or types	200 milliseconds or less
CLS — Cumulative Layout Shift	How much the layout jumps around while loading	0.1 or less

They matter for two reasons: they’re part of how Google evaluates page experience, and — more importantly — they describe whether visitors stay.

Test like your users

Before fixing anything, measure in conditions that match your audience:

• Use field data first. PageSpeed Insights and Search Console show how real Chrome users experience your site.
• Test lab runs on a throttled mobile profile. Lighthouse’s mobile preset simulates a slower phone and network; a real mid-range Android device on 4G is even better.
• Test more than the home page. Service pages, product pages and blog posts often carry different weight.

Fixing LCP: show the main content sooner

• Don’t hide content behind a loader. Full-screen “loading” animations delay the largest paint by design. Let the page render immediately.
• Render HTML on the server. If the browser must download and run a large JavaScript bundle before anything appears, LCP suffers. Server-rendered or static pages paint straight away.
• Optimise the hero image. Serve AVIF or WebP, size it for the screen with srcset, set explicit width and height, and preload it. Never lazy-load the LCP image.
• Self-host fonts and preload the main one. Use font-display: swap so text shows immediately.

Fixing INP: keep the main thread free

• Ship less JavaScript. Every kilobyte has to be parsed and executed on a phone CPU that’s much slower than a laptop’s. Only add interactivity where it’s needed.
• Audit third-party scripts. Ads, chat widgets, tag managers and trackers are frequent causes of slow interactions. Remove what you don’t need; delay what you do.
• Break up long tasks. Split heavy work so the browser can respond to taps in between.

Fixing CLS: stop the page jumping

• Give every image and video dimensions so space is reserved before it loads.
• Reserve space for anything injected later — banners, embeds, ads.
• Match fallback font metrics using size-adjust and related descriptors so the swap to your web font doesn’t reflow text.
• Animate with transform and opacity only, never properties that change layout.

A realistic checklist

1. No loader screens.
2. Server-rendered or static HTML.
3. Hero image in AVIF/WebP, preloaded, with dimensions.
4. Self-hosted, subset fonts — at most two families.
5. JavaScript only where it earns its place.
6. Third-party scripts audited and minimised.
7. Test on a throttled mobile profile before every release.

We build every site this way by default — this website included. If yours is slow, talk to us or read about our web development service.