Core Web Vitals for Indian websites: how to pass Google's page experience test
11 min read · 15-Dec-2025
villagehosting.in team
15 December 2025
Google uses Core Web Vitals as a ranking factor. Indian sites often fail LCP because of slow servers and unoptimised images. Here is the full fix checklist.
Core Web Vitals are measured on your actual visitors' devices
Google measures CWV from real Chrome users via the Chrome User Experience Report (CrUX). If most of your visitors are on mid-range Android phones with 4G connections, that's the data Google uses to rank you — not a desktop test in your office. The PageSpeed Insights 'Field Data' section shows your real user experience; the 'Lab Data' section shows simulated results. Always prioritise Field Data.
What are Core Web Vitals?
Core Web Vitals are three measurements Google uses to evaluate the user experience of a page:
- LCP (Largest Contentful Paint): How long until the largest visible element (usually a hero image or heading) appears. Target: under 2.5 seconds.
- INP (Interaction to Next Paint, replaced FID): How fast the page responds to user interactions like clicks. Target: under 200ms.
- CLS (Cumulative Layout Shift): How much the page jumps around as it loads. Target: under 0.1.
Google measures these from real user data using Chrome browsers. A page that fails these thresholds may rank lower than a slower page that passes — all other things being equal.
Why Indian sites struggle with Core Web Vitals
The image problem
Most Indian business websites were built by local web designers who uploaded full-resolution photos. A banner image uploaded at 4000×3000px, 6MB, served without compression is the single most common reason for LCP failure.
The server problem
LCP starts ticking from the first byte of the HTML response. If your server takes 600ms to respond (common on overloaded shared hosting in India), you have already spent most of your LCP budget before the browser even starts loading images.
TTFB (Time to First Byte) target: Under 200ms for pages served from Indian servers to Indian visitors.
The font problem
Indian websites often use Google Fonts with multiple weights — Roboto:300,400,500,700 — loaded with @import in the stylesheet. This creates a render-blocking chain that adds 300–500ms to load time on mobile.
The plugin problem
A typical WordPress site built by an Indian agency has 18–25 plugins installed. Many inject scripts and stylesheets unconditionally on every page. This adds hundreds of kilobytes of JavaScript that blocks rendering.
Fix 1: Optimise your images (biggest impact)
Convert to WebP
WebP images are 25–35% smaller than JPEG at equivalent quality. Modern browsers support WebP (including Chrome, which is 65%+ of Indian mobile traffic).
With WordPress:
- Install Imagify or ShortPixel plugin
- Set to automatic conversion on upload
- Enable WebP delivery
Without WordPress:
- Use Squoosh.app to convert manually
- For bulk conversion:
cwebp -q 80 input.jpg -o output.webp
Set correct image dimensions
Never upload a 4000px image if your design shows it at 1200px wide. Resize images to 2× the display size (to handle retina screens) before uploading.
Add explicit width and height to image tags
<img src="banner.webp" width="1200" height="600" alt="..." loading="lazy">
Width and height attributes prevent CLS — the browser reserves space for the image before it loads.
Preload your LCP image
If your LCP element is an image, add this to your <head>:
<link rel="preload" as="image" href="hero-image.webp">
This tells the browser to fetch the image immediately, before it parses the full HTML.
Fix 2: Improve server response time
Enable object caching
Without object caching, WordPress runs 20–40 database queries per page load. With Redis or Memcached, subsequent requests are served from memory.
On VillageHosting, Redis is available on all plans. Enable it in cPanel → Redis → Enable for domain.
Enable page caching
LiteSpeed Cache plugin on LiteSpeed servers is the fastest free caching solution for WordPress:
- Install LiteSpeed Cache plugin
- Go to LiteSpeed Cache → Cache → Enable cache
- Enable CSS/JS minification and combination
For Apache servers, use W3 Total Cache or WP Rocket.
Use a CDN for static assets
A CDN (Content Delivery Network) delivers your images, CSS, and JavaScript from servers close to your visitors. For Indian traffic, Cloudflare's free plan routes through their Mumbai and Chennai nodes.
- Add your site to Cloudflare (free plan)
- Point your domain's nameservers to Cloudflare
- Enable caching rules for static assets
CDN reduces TTFB for cached assets from 50–150ms to under 20ms.
Fix 3: Fix font loading
Switch from @import to <link> preload
Replace this in your stylesheet:
@import url('https://fonts.googleapis.com/css2?family=Roboto:wght@400;700&display=swap');
With this in your HTML <head>:
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Roboto:wght@400;700&display=swap">
Consider system fonts for body text
System fonts (San Francisco on Apple, Segoe UI on Windows, Roboto on Android) are already on the device. They add zero load time.
Use a system font stack for body text and load a custom font only for headings:
body {
font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif;
}
Limit font weights
Each font weight is a separate HTTP request. Roboto:300,400,500,600,700,900 is six requests. Use only the weights you actually need — usually 400 and 700.
Fix 4: Fix layout shift (CLS)
Image dimensions
Already covered above. Always set explicit width and height.
Ads and embeds
Ads that load after the page and push content down cause CLS. Reserve space for ads with a fixed-height container.
Late-loading content
Content that appears after JavaScript runs — cookie notices, chat widgets, notification bars — causes CLS if they push page content down. Use transform: translateY() or fixed positioning instead.
Web font flash
Text that jumps from fallback font to loaded font causes CLS. Mitigate with font-display: optional for non-critical fonts, or font-display: swap with a font that closely matches your loaded font's metrics.
Testing your Core Web Vitals
-
Google PageSpeed Insights: Enter your URL at pagespeed.web.dev. Shows field data (real user data) and lab data (simulated).
-
Google Search Console: If you have Search Console set up, check Core Web Vitals report for your site's real-user scores.
-
WebPageTest: More detailed waterfall view, useful for identifying specific bottlenecks. Run from Chennai or Mumbai for Indian-specific results.
Target scores
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP | < 2.5s | 2.5–4.0s | > 4.0s |
| INP | < 200ms | 200–500ms | > 500ms |
| CLS | < 0.1 | 0.1–0.25 | > 0.25 |
For most Indian WordPress sites, fixing images and enabling LiteSpeed caching will bring LCP from 4–6 seconds to under 2.5 seconds.
If you are stuck, bring your site to our team via WhatsApp. We have a performance optimisation service that includes a full Core Web Vitals audit with specific fixes for your stack.