Core Web Vitals: How to Fix LCP, INP and CLS

Most business owners hear "Core Web Vitals" and assume it is a developer problem. It is not. These are three numbers Google uses to judge whether your page loads fast, responds quickly and stays stable on screen. Poor scores push you down in search results and, more practically, make visitors leave before they read a word. The good news is that most fixes are straightforward, especially on a small business site. This guide walks through each metric in plain English, explains the most common causes I see on Indian business sites, and tells you exactly what to do about them.

What Core Web Vitals actually are

Core Web Vitals are three metrics Google tracks on every page. They are measured using real visitor data collected from Chrome browsers, so you cannot fake them in a lab test. The three are:

LCP (Largest Contentful Paint): how long until the biggest visible element on the page, usually the hero image or main headline, appears on screen.
INP (Interaction to Next Paint): how quickly the page reacts when someone taps a button, clicks a link or types into a form. This replaced the older FID metric in March 2024.
CLS (Cumulative Layout Shift): whether elements on the page jump around while loading, like text shifting down when an image pops in late.

Google groups pages into three buckets: "Good" (green), "Needs improvement" (yellow) and "Poor" (red). You want green across all three. That means LCP under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1. Let me break each one down.

LCP: making the main content appear fast

LCP measures perceived speed. It answers the question "when does this page feel loaded?" If you open a page and stare at a blank screen for four seconds before the hero image and headline appear, that is a terrible LCP. Visitors on a Jio or Airtel connection in India notice this immediately.

What causes slow LCP

In my experience auditing small business sites in Pune and across India, the same culprits show up repeatedly:

Massive, uncompressed images. A photo straight off a phone camera can be 4 to 6 MB. That single file takes longer to download than the rest of the page combined, especially on a mobile connection.
Slow or distant hosting. If your server is in the US or Europe and your audience is in India, every page request travels thousands of kilometres before a single byte arrives. That adds 200 to 500 milliseconds before anything even starts loading.
Render-blocking JavaScript and CSS. Scripts and stylesheets in the head of your page force the browser to download and process them before it paints anything on screen. A site with six tracking scripts, two chat widgets and a cookie banner can stall the entire page for seconds.
Too many web fonts. Loading four or five font weights from Google Fonts adds extra network requests that delay the first paint.

How to fix LCP

Compress images to WebP format. WebP files are typically 25 to 35 percent smaller than JPEG at the same quality. A 3 MB JPEG becomes a 150 KB WebP that looks identical on screen. Free tools like Squoosh (squoosh.app) handle this in seconds. If your CMS supports it, enable automatic WebP conversion.
Lazy load images below the fold. The hero image at the top of the page should load immediately. Every other image, the ones visitors have to scroll to see, should use loading="lazy" so the browser fetches them only when needed. This frees up bandwidth for the content that matters first.
Use a CDN or pick a closer data centre. If your audience is in India, your hosting should be in Mumbai or Singapore, not Virginia. Services like Cloudflare (free tier) cache your static files on servers worldwide and serve them from the nearest location to the visitor.
Defer non-critical scripts. Move analytics, chat widgets and tracking pixels to load after the main content has rendered. The defer and async attributes on script tags handle this. Your visitor sees the page first, and the tracking loads quietly afterwards.
Preload the hero image. Adding a <link rel="preload"> tag in the head tells the browser to start fetching the hero image immediately, before it discovers it in the HTML. This shaves a few hundred milliseconds off LCP on content-heavy pages.

INP: making the page feel responsive

INP measures responsiveness. When a visitor taps your "Get Quote" button, how long before the page visually responds? If there is a noticeable delay, a lag where nothing happens for half a second, that is poor INP. People assume the button is broken and tap again, or just leave.

What causes poor INP

Heavy JavaScript on the main thread. The browser has a single thread for processing JavaScript and painting the screen. If a script is busy crunching data for 400 milliseconds, the browser cannot respond to a tap during that time. The visitor sees a frozen page.
Too many third-party scripts. Every chat widget, analytics tracker, heatmap tool and social media embed adds JavaScript that competes for the main thread. I have seen business sites with 12 third-party scripts. Each one is small on its own, but together they choke responsiveness.
Long tasks in event handlers. If clicking a button triggers a script that recalculates a large table, fetches data synchronously or manipulates hundreds of DOM elements at once, the page freezes until that work finishes.

How to fix INP

Audit and remove unnecessary third-party scripts. Be honest about which scripts actually earn their keep. That heatmap tool you installed eight months ago and never checked? Remove it. The social share buttons nobody clicks? Remove them. Every script you remove gives the main thread breathing room.
Code-split and load JavaScript on demand. Instead of loading one massive bundle, break your JavaScript into smaller pieces and load each piece only when needed. If a feature only runs on the contact page, it should not load on the homepage.
Optimise event handlers. If a button click triggers expensive work, break that work into smaller chunks using requestAnimationFrame or setTimeout to yield back to the browser between steps. The browser can paint the response first and finish the heavy work afterwards.
Use web workers for heavy computation. If you have JavaScript that processes data (filtering a product list, sorting results), move that work off the main thread into a web worker. The main thread stays free to respond to taps.

CLS: keeping the page stable

CLS measures visual stability. You know the experience: you start reading a paragraph and suddenly it jumps down because an ad loaded above it, or you go to tap "Submit" and a banner pushes the button away so you tap "Cancel" instead. That is layout shift, and it is infuriating.

What causes high CLS

Images and videos without dimensions. If your HTML does not specify the width and height of an image, the browser does not know how much space to reserve. It renders the text first, then when the image loads it shoves everything down to make room.
Dynamically injected content. Ad banners, cookie consent bars and newsletter popups that insert themselves into the page after it has loaded push existing content around. An ad slot that appears at the top of the page and pushes everything down 250 pixels is the classic offender.
Late-loading web fonts. When a custom font loads after the fallback font has already rendered, the text reflows because the two fonts have different letter spacing and line heights. The entire paragraph shifts.

How to fix CLS

Set width and height on every image and video. Even if you use CSS to make images responsive, putting width and height attributes in the HTML lets the browser calculate the aspect ratio and reserve the right amount of space before the image loads. This single fix eliminates the most common CLS problem.
Reserve space for ads and embeds. If your page has ad slots, wrap them in a container with a fixed minimum height matching the ad size. The space stays reserved whether the ad loads in one second or five. Same principle for embedded videos, maps and social feeds.
Use font-display: swap in your font declarations. This tells the browser to show text in the fallback font immediately, then swap to the custom font when it loads. The brief visual change is less disruptive than a blank gap followed by a reflow. Pair it with preloading your most important font file for the fastest swap.
Avoid inserting content above existing content. If you need to show a notification or banner, overlay it on top of the page (like a sticky bar) rather than pushing the page content down. Overlays do not cause layout shift.

How to check your Core Web Vitals

You do not need paid tools to measure this. Two free options cover everything:

Google PageSpeed Insights (pagespeed.web.dev): paste any URL and it shows both lab data (simulated) and field data (real visitors). The field data section at the top is what matters for rankings. Always check the mobile tab, not desktop, because Google ranks based on the mobile version.
Google Search Console Core Web Vitals report: this groups all your pages by status (good, needs improvement, poor) and tells you which metric is failing on which pages. It uses real Chrome user data, so it reflects actual visitor experience. Check it under "Experience" in the left menu.

For a broader technical health check, my free Website SEO Checker flags speed issues alongside indexability, meta tags and other SEO basics in under a minute.

Why this matters more in India

Most of your visitors are on phones, and a large share are on 4G connections that are fast by Indian standards but slower than urban broadband in the US or Europe. That means every extra kilobyte and every extra server round-trip hurts more. A page that scores "good" on a developer's MacBook in Pune can score "poor" for a visitor on a Redmi phone in Nashik.

Hosting location matters too. If your site is on a shared hosting plan with the data centre in the US, every request adds 150 to 300 milliseconds of latency before the server even starts responding. Moving to a host with a Mumbai or Singapore data centre, plans start at around 200 to 500 rupees per month, typically cuts your LCP by 30 to 50 percent with no other changes.

The fixes that give you the biggest return

If you do nothing else, do these four things. They fix the majority of Core Web Vitals problems I see on Indian small business sites:

Compress every image to WebP and keep file sizes under 200 KB. This alone fixes most LCP problems.
Add width and height attributes to every image in your HTML. This alone fixes most CLS problems.
Audit your third-party scripts. Remove what you are not actively using. This improves both LCP and INP.
Move your hosting to a data centre in Mumbai or Singapore if your audience is in India.

These are not exotic fixes. They are basic housekeeping that most sites skip. Get them right and you are ahead of the vast majority of local competitors, because most of them have not done this either.

Speed is not a vanity metric. Every second of delay costs you visitors, leads and rankings. Fix the basics and you fix most of the problem.

When to get help

Image compression, lazy loading and removing unused scripts are things any site owner can handle. If your scores are still poor after doing those, the problem is usually deeper: render-blocking CSS that needs restructuring, JavaScript that needs code-splitting, or a hosting setup that needs rethinking. Those are one-time fixes that pay off for years. If you want a clear diagnosis of what is holding your site back and a prioritised list of what to fix, get in touch and I will take a look.

Related guides

For the full picture on technical SEO beyond speed, read my guide to technical SEO basics every business owner should know.
Run through the complete free on-page SEO checklist for 2026 to make sure each page is properly optimised.
If you are wondering whether your business even needs a website, here is my honest take on whether you need a website in 2026.

Frequently asked questions

Do Core Web Vitals really affect rankings?

Yes, but they are one signal among many. Google confirmed Core Web Vitals as a ranking factor in 2021, and they remain part of the page experience signals in 2026. They will not rescue thin content, but when two pages are roughly equal in relevance and authority, the faster, more stable page tends to win. More importantly, poor vitals hurt conversions directly. A page that takes five seconds to load on a phone loses visitors before Google even enters the picture.

How often should I check my Core Web Vitals?

Once a month is a sensible rhythm for most small business sites. Google Search Console has a Core Web Vitals report that flags pages with issues, and it updates regularly with real user data. After any major site change, like a redesign, a new plugin or switching hosts, run a PageSpeed Insights test on your key pages immediately. If nothing changes on the site, monthly is enough to catch slow regressions before they hurt traffic.

My site is on shared hosting, is that a problem for Core Web Vitals?

It can be. Cheap shared hosting means your site shares a server with hundreds of other sites, so when the server is busy your pages load slowly regardless of how well they are optimised. If your LCP is consistently above 3 seconds and you have already compressed images, deferred scripts and minimised plugins, the host is likely the bottleneck. Moving to a decent managed host with a Mumbai or Singapore data centre typically cuts load time by 30 to 50 percent for Indian visitors. Plans start around 200 to 500 rupees per month, which is modest next to the leads you lose from a slow site.

Work with Shreyas → ← Back to blog