Google's Core Web Vitals have been a ranking signal since 2021. Most Indian developers don't think about them. Most website owners don't know they exist. And most Indian websites fail at least two of them — not because the problem is hard to fix, but because nobody looked.
I've audited over fifty websites in the past three years. The pattern is nearly identical every time: a slow server response that nobody measured, hero images uploaded straight from a smartphone camera, Google Fonts loading in a way that blocks the page from rendering. These are ₹0 problems to diagnose and cheap to fix. But first, you need to know what you're measuring.
What Are Core Web Vitals
Core Web Vitals are a set of real-world performance metrics that Google uses to measure the user experience of a webpage. They measure three things: how fast the main content loads, how visually stable the page is while loading, and how quickly it responds to user input. Google uses these metrics as a ranking signal — all else being equal, a faster, more stable page ranks above a slower, jumpier one.
There are three metrics. They measure different things and have different thresholds for what Google considers "Good." All three are assessed on mobile and desktop separately, and Google weights mobile more heavily for most Indian sites since the majority of Indian web traffic comes from mobile devices.
LCP: Largest Contentful Paint
LCP measures how long it takes for the largest visible element on the page to render. This is usually your hero image, a large heading, or a banner at the top of the page. Think of it as the moment the page starts to feel real to the user — before that point, they're looking at a blank or partially loaded screen.
The target is under 2.5 seconds. Between 2.5 and 4 seconds is "Needs Improvement." Over 4 seconds is "Poor" — Google explicitly uses this as a negative ranking signal, and at this speed you're losing users to the back button before they see anything.
LCP is the metric most Indian websites fail. The reasons are almost always the same:
- Unoptimised hero images — developers upload 3–8MB JPEGs straight from a phone or camera. A single image causing a 4-second LCP is the most common finding in every audit.
- Slow server response (high TTFB) — ₹99–₹299/month shared hosting regularly produces a Time to First Byte over 800ms. That's before a single byte of your actual page content starts loading.
- Render-blocking resources — CSS and JavaScript loaded synchronously in the <head> that delay the browser from rendering anything visible.
- No preload hint for the LCP image — the browser discovers the hero image late and has to queue it behind other resources.
The most actionable insight from an LCP audit is almost always the image. If your hero image is over 500KB and not in WebP format, that's where to start — before touching hosting, caching, or any code.
CLS: Cumulative Layout Shift
CLS measures how much the visible content on the page moves around while it's loading. Every time an element shifts position unexpectedly — a paragraph that jumps down because an image above it loaded late, a button that moves because a font rendered differently, an ad that appears and pushes everything below it — that contributes to your CLS score.
The target is under 0.1. Above 0.25 is Poor. A score of 0 means nothing moved; a score of 0.5 means content was shifting significantly throughout the page load. CLS is the metric that causes users to accidentally tap the wrong element — a problem that's disproportionately bad on mobile, on 4G connections, and on lower-end Android devices that are common in India.
- Images without explicit width and height attributes — the browser doesn't know how much space to reserve until the image downloads, so content below shifts when it loads.
- Google Ads loading above existing content — a 250px ad unit appearing above the fold after the page renders is a textbook CLS failure.
- Web font FOUT (Flash of Unstyled Text) — text renders in a fallback font first, then jumps to the correct font when it loads, shifting surrounding content.
- Dynamic content injected without reserved space — banners, cookie notices, chat widgets that appear after page load without a pre-allocated container.
A CLS of 0.38 means your page is shifting enough that users regularly tap the wrong element. We've seen clinic contact forms get buried by an ad loading 300 milliseconds after the page appears — costing real patient inquiries. The ad was earning ₹800 a month. The missed inquiries were worth considerably more.
The fix for most CLS issues is straightforward: set width and height attributes
on every image tag, use font-display: swap for web fonts, and pre-allocate space for any
content that loads dynamically. None of these require a developer to rebuild the site — they're small
targeted changes.
INP: Interaction to Next Paint
INP measures how quickly your page responds when a user does something — clicks a button, taps a link, types in a search field. It replaced FID (First Input Delay) in March 2024 because FID only measured the delay before the browser started processing the first interaction. INP measures the full response time of any interaction throughout the entire page session, which is a far more accurate measure of how the page actually feels to use.
The target is under 200 milliseconds. Between 200–500ms is Needs Improvement. Over 500ms is Poor — at this speed, users feel the lag. Tapping a button that doesn't respond immediately for half a second is the experience equivalent of a stuck door handle.
INP failures are less common than LCP failures on Indian websites, but they're increasingly relevant as sites add more third-party scripts — live chat widgets, analytics platforms, marketing automation, and social proof tools that all run JavaScript in the background while the user is trying to interact with the page.
How to Check Your Scores
You don't need to hire anyone to find out where your site stands. These four tools give you the complete picture in under ten minutes, all for free.
Enter your URL and get an instant breakdown of all three Core Web Vitals, separated into Field Data (real user measurements collected by Chrome) and Lab Data (a simulated test run now). Field Data is what Google actually uses for rankings. If you don't have enough traffic for Field Data to show, start with Lab Data as a proxy. Run it on mobile — that's the score Google cares about most for Indian sites.
If you have Search Console set up (you should), navigate to Experience → Core Web Vitals. This shows you real user data aggregated across all your pages, grouped by URL pattern, with a breakdown of which pages are failing and why. This is the most actionable view because it shows you which specific pages Google is measuring and how they're performing against the thresholds.
Open Chrome, right-click → Inspect → Lighthouse tab. Run the Performance audit. This gives you a detailed trace of exactly what's happening during page load, with specific suggestions ranked by impact. The "Opportunities" section tells you what to fix first and estimates how much time each fix will save. This is the best tool for understanding what's causing a slow LCP specifically.
Install this free extension from the Chrome Web Store. As you browse your site normally, it shows a real-time overlay with your LCP, CLS, and INP scores updating live. It's useful for finding CLS issues specifically — you can watch the score update in real time as the page loads and immediately see what's causing the shift. It also shows INP as you interact with the page, which is the only way to measure INP outside of field data.
Want Us to Run the Audit For You?
We'll run a full Core Web Vitals audit on your site, identify the specific issues pulling down each metric, and give you a prioritised fix list — with real time and cost estimates. Free, no obligation.
The Clinic That Went from 7s to 1.4s
A healthcare clinic in Lucknow came to us after noticing they'd stopped showing up in local search results they'd previously ranked in. When we ran PageSpeed Insights on their homepage, the Field Data showed a 7.2-second LCP on mobile, a CLS of 0.38, and an INP of 580ms. They were failing all three metrics, badly, and had been for over a year.
The problems weren't complex. They were just invisible — because nobody had looked. Here's exactly what we found and what we changed:
- The homepage hero banner was a 4.8MB JPEG uploaded directly from a DSLR camera. No compression, no resize, no format conversion.
- The site was hosted on a ₹199/month shared hosting plan. Their TTFB was averaging 1,200ms — before a single byte of content started rendering.
- Google Fonts was loading synchronously in the <head>, blocking render for an additional 340ms while the font files downloaded.
- A booking plugin they'd stopped using 18 months ago was still active, loading its CSS and JavaScript on every page.
We made five changes over two weeks. No redesign. No rebuild. Just targeted fixes to the specific causes of each failing metric.
Fixed by: WebP conversion + compression (4.8MB → 110KB), preload hint added, hosting upgrade (TTFB: 1,200ms → 180ms)
Fixed by: Explicit width & height on all images, font-display: swap added for Google Fonts, booking plugin removed
Fixed by: Plugin removal reduced JavaScript payload by 68KB, deferred two non-critical scripts
The hosting upgrade was ₹300 more per month. The image compression took 20 minutes. The Google Fonts change was four lines of code. The total development cost was under ₹8,000. The result was a 60% increase in clinic inquiries within 8 weeks. Most performance problems are cheaper to fix than people think — they're just invisible until someone looks.
What's Killing Indian Websites
After auditing over fifty Indian websites across industries in Lucknow, Delhi, Mumbai, and Bangalore, the same five problems appear in almost every failing site. None of them are exotic. All of them are fixable without rebuilding the site.
-
₹99–₹299/month shared hosting with TTFB over 800ms
This is the invisible floor on your LCP. You cannot optimize your way to a 2.5s LCP if the server takes 1.2 seconds just to respond to the first request. No amount of image compression or code optimization can overcome a slow server. Every clinic, consultant, and restaurant website we've audited on budget shared hosting has failed LCP — without exception.
-
Unoptimised images — 3–8MB files uploaded straight from phones
The single most common finding in every audit. A developer builds the site, the client uploads their own photos over time, and nobody set up automatic image compression. A 5MB hero image on a 4G connection is a 7-second LCP. The fix is compression (tools like Squoosh or TinyPNG), format conversion to WebP, and ideally a CDN to serve images from a server close to the user.
-
Images without explicit width and height attributes
Every <img> tag without explicit
widthandheightattributes is a potential CLS source. The browser can't reserve space for the image until it downloads, so everything below the image shifts down when it loads. This is a one-line fix per image — but on a site with 40 images none of which have dimensions set, the cumulative CLS can be catastrophic. -
Synchronous Google Fonts loading
The standard Google Fonts <link> tag in <head> is a render-blocking resource. The browser stops everything to download the font before it renders any text. On a slow connection — which is most Indian mobile users outside major metros — this adds 200–600ms to your LCP for a font that the user might not even consciously notice. The fix is to load fonts with preconnect and a non-blocking strategy, or to self-host your fonts.
-
Plugin sprawl on WordPress sites
Every active plugin on a WordPress site loads its own CSS and JavaScript on every page, whether that page uses the plugin or not. A site with 14 active plugins — contact forms, sliders, SEO tools, social sharing, backup plugins, chat widgets, and three abandoned ones nobody remembers installing — is loading a mountain of unused code on every request. We've reduced JavaScript payload by 60–70% just by deactivating and deleting plugins that weren't actively used.
The Fixes, In Priority Order
Fix these in this order. Each one builds on the last, and the first two will have the biggest impact for most Indian websites.
Target under 200KB for any image on the page, and under 100KB for images below the fold. Use Squoosh.app (free, no upload limit) or TinyPNG. Convert JPEGs and PNGs to WebP — it's supported by all modern browsers and typically 25–35% smaller than equivalent JPEG quality. For WordPress, the Imagify or ShortPixel plugin handles this automatically for future uploads.
Add this to the <head> of any page where the LCP element is an image:
<link rel="preload" as="image" href="your-hero.webp">. This tells the browser to
start downloading the image immediately, before it would normally discover it while parsing the
HTML. Combined with image compression, this single change often drops LCP by 0.5–1.5 seconds.
Add width and height attributes to every <img> tag on your site.
This lets the browser reserve space before the image loads, eliminating the layout shift. You don't
need to match the exact display size — just the aspect ratio. For example:
<img src="hero.webp" width="1200" height="600" alt="...">. This is the fastest
CLS fix available.
Replace the standard Google Fonts <link> tag with preconnect hints followed by a
non-render-blocking load. Add rel="preconnect" links first, then load the font
stylesheet with media="print" onload="this.media='all'" — this loads the font
asynchronously so it doesn't block page rendering. Also add font-display: swap to your
CSS font declarations so text renders immediately in a fallback font rather than being invisible
while the font downloads.
Run your current TTFB using PageSpeed Insights' "Server Response Time" check or WebPageTest.org. If it's over 400ms, no frontend optimization will get you a passing LCP on its own. For Indian sites, look at Cloudflare, Hostinger's Business plan, or Siteground — they all have servers in India and produce TTFB well under 200ms for typical WordPress sites. The cost difference from a budget host is usually ₹200–₹500/month. The performance difference is not small.
Go through every active plugin on your WordPress site. If you haven't used a plugin in the last 60 days, deactivate and delete it. Then use Chrome DevTools' Coverage tab (open DevTools → Ctrl+Shift+P → type "Coverage") to see what percentage of your loaded JavaScript and CSS is actually used on each page. Anything under 10% usage is a candidate for lazy loading or removal. A well-audited plugin list can reduce your JavaScript payload by 40–70%.
For any <script> tag that doesn't need to run before the page renders — analytics, chat
widgets, social sharing buttons, video embeds — add the defer attribute. This tells the
browser to download the script in the background and execute it after the HTML has finished parsing,
without blocking rendering. For scripts where execution order doesn't matter, async is
even better. Most third-party scripts can safely be deferred without affecting page functionality.
Bottom Line
A passing Core Web Vitals score is not a trophy — it's the floor. Google uses it as a ranking tiebreaker: two equally relevant pages compete on speed and stability. More importantly, a 1.5-second LCP page converts better than a 7-second LCP page regardless of what Google does with the signal. Users leave slow pages before they read anything.
The clinic we worked on wasn't a complex technical project. It was four targeted fixes applied to the right places. Most Indian websites have similar low-hanging problems — the difference between a failing and a passing score is almost never a rebuild, it's an audit followed by a prioritised fix list.
We have never optimised a site's Core Web Vitals and had the client's conversion rate go down. Not once. Every performance improvement has had a measurable positive business outcome. Speed is not a technical concern — it's a business one. The developers who treat it as the latter get better results than the ones who treat it as a checkbox.
If you want to know where your site stands right now, run it through PageSpeed Insights on mobile and look at the three numbers. LCP over 4s, CLS over 0.25, or INP over 500ms — any of those is a fixable problem with a clear priority order. If you want someone to run the full audit and hand you the fix list, that's what we do.
The form is below.