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

Most business owners hear "Core Web Vitals" and assume it is a developer's problem, something to email off to whoever built the website and forget about. It is not. These are three numbers Google collects from real visitors to judge whether your page loads fast, reacts quickly to taps and clicks, and stays visually steady while it loads. Get them wrong and two things happen at once: your rankings take a small hit, and a much larger number of visitors simply leave before they read a word. I audit small business sites across Pune and the rest of India every month, and Core Web Vitals problems show up on almost all of them, usually from the same handful of repeatable causes. This guide explains what LCP, INP and CLS actually measure, how to read your real scores instead of guessing, the fixes that matter most depending on whether you run WordPress, Shopify, Wix or a static site, a fix order that clears the biggest problems first, and what these numbers do and do not do for your rankings.

What LCP, INP and CLS actually measure, and the 2026 thresholds

Core Web Vitals are three metrics Google collects from real visitors using Chrome, not from a one-off lab test on someone's laptop. Google sorts every page into "Good," "Needs improvement" or "Poor" for each metric, and the thresholds have stayed the same since INP replaced the older FID metric in March 2024:

• LCP (Largest Contentful Paint): the time until the largest visible element on the page, usually a hero image or main headline, finishes rendering. Good is under 2.5 seconds, poor is anything over 4 seconds.
• INP (Interaction to Next Paint): how long the page takes to visibly respond after a tap, click or key press, measured across the whole visit rather than just the first interaction. Good is under 200 milliseconds, poor is over 500 milliseconds.
• CLS (Cumulative Layout Shift): a score for how much content jumps around while the page loads, calculated from how far elements move and how much of the screen they affect. Good is under 0.1, poor is over 0.25.

You need all three in the green zone to get a "Good" page experience rating from Google. One poor metric is enough to flag the whole page, even if the other two are excellent, which is why a site can feel fast to you and still fail its Core Web Vitals assessment because of one overlooked layout shift.

Reading your real scores: PageSpeed Insights vs the Search Console report

PageSpeed Insights shows two different data sets on the same report, and mixing them up is the single most common mistake I see business owners make. Lab data comes from one simulated Lighthouse test run on Google's servers at the moment you click "Analyze." Field data comes from real visitors who loaded that exact URL on Chrome over the past 28 days, pulled from what Google calls the Chrome User Experience Report. Lab data is useful for debugging a single page in detail, because it is repeatable and consistent. Field data is what Google actually uses as the page experience ranking signal, because it reflects what your real visitors experienced on real phones and real networks. If a URL has not had enough Chrome traffic, PageSpeed Insights cannot show field data for it and quietly falls back to lab data or an origin-level score for the whole domain, which is worth noticing before you assume a page is passing when it simply has not been measured yet.

The Google Search Console Core Web Vitals report, found under Experience in the left menu, uses the same 28 day field data as PageSpeed Insights, but for every page on your site at once, grouped by similar template rather than one URL at a time. This report can lag reality by a few weeks, because it is a rolling average rather than a live number. Fix a problem today and PageSpeed Insights will usually confirm the lab improvement immediately, but the Search Console URL group will often keep showing "Poor" for two to four weeks until enough fresh field data has rolled in. My advice is to check PageSpeed Insights mobile tab right after making a change for fast feedback, and check Search Console once a month for the honest, site-wide trend.

The fixes that matter most, by platform

The metric you are fixing barely changes across platforms. What changes is where the setting lives and who controls it. Here is where to look on the four setups I see most often on Indian small business sites.

WordPress

Image formats are usually the biggest win: convert new uploads to WebP through an image optimisation plugin, or enable it in your hosting dashboard if your host offers automatic conversion. Lazy loading has shipped in WordPress core since version 5.5, but some older or heavily customised themes disable it without telling you, so check a product or blog image in your browser's page source for a loading="lazy" attribute. Fonts are worth auditing separately: many themes load four or five Google Fonts weights by default in the Customizer, and trimming that to two weights removes several render-blocking requests. Third-party scripts pile up fast on WordPress because every plugin can inject its own script tag in the header; chat widgets, popup builders and review widgets are the usual offenders, so count how many you actually use and remove the rest. Layout reservations are handled automatically for images added through Gutenberg's image block, but older widgets and manually pasted HTML often skip the width and height attributes that prevent shift. For the full picture on getting images right, see my guide to image SEO.

Shopify

Shopify auto-serves WebP on most current themes, but that only helps if you are uploading reasonably sized source files rather than a 6MB product photo straight off a phone camera, so resize before uploading where you can. Lazy loading is on by default in Shopify 2.0 themes for images below the fold; if your theme is customised or older, check the theme code for missing loading="lazy" attributes. Fonts are rarely the bottleneck if you stick to Shopify's bundled font sets rather than importing extra Google Fonts through custom CSS in theme settings. Third-party apps are the single biggest INP risk on Shopify: every installed app can add its own script tag that runs on every page whether you use it there or not, so go through Online Store, Themes, Edit code, or a script inventory app, and remove anything you installed once, tested and forgot about. Layout reservations matter most around product image containers and the price or add-to-cart row underneath them; set an explicit aspect ratio in theme settings so that row does not jump the moment the image finishes loading.

Wix

Wix compresses images automatically on upload, but very large source files still slow down the initial processing, so keeping originals under a few megabytes helps even though Wix does the final compression for you. Lazy loading is automatic and not something you can configure directly. Fonts are rarely a problem because Wix already limits you to a smaller curated font panel. The real risk on Wix is the App Market: chat widgets, booking widgets and marketing pop-ups each add their own script, so check Settings, then Tracking and Analytics, along with your installed apps list, and remove anything not actively driving enquiries. Wix's strict grid layout reserves space for most elements automatically, but freeform-positioned elements and anything set to animate in "on scroll" can still cause a visible jump as the page settles.

A static or custom-coded site

Full manual control means every fix is direct and usually faster to ship than on a platform with a plugin layer in the way. Serve WebP or AVIF images at the exact display size rather than scaling a large image down with CSS. Add explicit width and height attributes, or an aspect-ratio in CSS, to every image and video tag. Set font-display: swap and consider self-hosting font files instead of a render-blocking Google Fonts stylesheet link. Add defer or async to every script tag except the one thing that genuinely must run first. Preload the hero image with a <link rel="preload"> tag in the head. Static sites usually score better across all three metrics once these five changes are in place, simply because there is no plugin or app layer adding hidden weight you cannot see.

The fix order that clears the biggest problems first

Fixing all three metrics at once is confusing and easy to do out of order. This is the sequence I use on client sites, because each step either gives you a baseline to measure against or fixes the highest-impact problem before the smaller ones. It takes about two hours of hands-on work for a typical small business site, plus a two to four week wait for Search Console to catch up.

Step 1: Run PageSpeed Insights on your homepage and busiest page

Open pagespeed.web.dev and test both your homepage and whichever page brings the most traffic or enquiries. Read the mobile tab, not desktop, since Google ranks your site based on its mobile version. Note your LCP, INP and CLS field scores if shown, or lab scores if the page has too little traffic for field data yet. Write these three numbers down somewhere you will actually look again. This is the baseline every later change gets measured against, and skipping it is the main reason people cannot tell if a fix actually worked.

Step 2: Check the Search Console Core Web Vitals report for the whole site

Open Search Console, click Experience, then Core Web Vitals, and look at how many URLs sit in each status for each metric. This tells you whether the problem is isolated to one page or baked into a template used across dozens of pages. Fixing a shared template, like a product page layout or a blog post header, fixes every page using it in one pass, which is a far better use of an afternoon than fixing one URL by hand and hoping the rest are fine.

Step 3: Fix LCP first by compressing and preloading the hero image

Convert the largest visible image on the page to WebP, keep it under 200KB, and add a preload link in the head so the browser starts fetching it before it even finishes parsing the rest of the HTML. This single change produces the biggest LCP improvement I see on almost every site I audit, which is why it comes before anything else on this list. If you have not already, run a quick pass over every other image on the site while you are at it; my image SEO guide covers sizing and compression in more depth.

Step 4: Fix CLS by reserving space for images, ads and embeds

Add width and height attributes to every image and video tag on the page. Wrap any ad slot, map embed or social feed in a container with a fixed minimum height matching its expected size. Switch dynamic banners and cookie notices so they overlay the page instead of pushing existing content down when they appear. This step usually takes CLS from a poor score to a good one in a single afternoon of HTML edits, with no design changes required.

Step 5: Fix INP by auditing third-party scripts

List every script tag loading from a domain that is not yours: chat widgets, analytics tools, heatmaps, review badges, popup builders. Remove anything you cannot name a specific reason for keeping. Add defer to everything that remains except the one script that genuinely must run immediately. This step alone often removes more render-blocking weight than every other fix on this list combined, because most small business sites are carrying three or four scripts nobody remembers installing.

Step 6: Fix font-related shift with font-display swap

Add font-display: swap to your font declarations so the browser shows fallback text immediately instead of leaving a blank gap while the custom font downloads. Cut your font weights down to two or three instead of five or six; each extra weight is a separate file the browser must fetch before that particular piece of text can render in its final style. This is a small fix, but it closes out the last common source of layout shift after images and ads are handled.

Step 7: Re-test and recheck Search Console after two weeks

Run PageSpeed Insights again immediately to confirm your lab scores improved; this tells you the fix itself worked. Then wait two to four weeks and check the Search Console report again, since field data is a rolling 28 day average and needs time to fully reflect the change. Mark a date on your calendar rather than panicking if the report still shows "Poor" the day after you make a fix. It has not failed, it just has not caught up yet.

What Core Web Vitals does and does not do for your rankings

Google has been explicit that Core Web Vitals is a tie-breaker signal inside the broader page experience system, not a lever you can pull to outrank a page with better content and stronger authority. When two pages answer the same query with similar relevance and a similar backlink profile, the faster and more stable one tends to edge ahead. But a page with thin, unhelpful content will not out rank a genuinely useful page just because it loads in half a second. I have audited plenty of blazing-fast pages that could not rank for anything, and slightly slower pages that dominate their category because the content, structure and authority behind them was strong enough to matter more. Treat Core Web Vitals as a floor you need to clear, not a ceiling you are trying to raise indefinitely.

The technical work in this guide, image compression, layout fixes and script cleanup, was one part of taking a Pune dental clinic's site from Google position #59 to the top five in two months. It mattered, and it was not the only thing that mattered; the content and on-page work around it did just as much. If you want the fuller picture of technical SEO beyond just speed, my technical SEO basics guide covers crawlability, indexing and HTTPS alongside vitals. And if you are still deciding whether any of this effort is worth your time and money at all, I answer that question directly in is SEO worth it in 2026.

Fast, well-structured pages also help outside traditional rankings. A page that loads quickly and is not held up by a dozen third-party scripts is easier for AI crawlers to fetch and read in full before they move on, which matters more each year as AI Overviews and chat tools decide what to cite. I cover that overlap in how AI Overviews are changing SEO and in SEO vs GEO in 2026.

Common mistakes I see on Indian small business sites

• Compressing images once and never again. Every new product photo or blog image goes back to camera-original size unless compression is built into the upload workflow rather than treated as a one-time cleanup.
• Testing CLS on desktop only. A wide monitor hides shift that only appears on a narrow mobile viewport, where text wraps differently and elements stack in a different order.
• Installing a caching plugin and assuming the job is done. Caching plugins help with server response time but cannot fix a 6MB unoptimised hero image or twelve unused third-party scripts on their own; they paper over part of the problem, not all of it.
• Chasing a perfect 100 PageSpeed score. Lab scores in the high 90s do not always match good field data, and squeezing out the last few lab points wastes hours that usually matter more spent on content or links.
• Ignoring the Search Console report because one page tested fine. A single URL can score well in PageSpeed Insights while ten other pages on the same template score poorly; the site-wide report catches what a one-off test misses.
• Blaming Core Web Vitals for a sudden ranking drop without checking anything else first. A sharp ranking loss is far more often a content, backlink or indexing issue. Checking vitals is step three or four in a ranking-drop investigation, not step one.

Frequently asked questions

What is a good Core Web Vitals score in 2026?

Good means all three metrics sit in the green zone at the same time: LCP under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1. These thresholds have not changed since INP replaced FID as the responsiveness metric in March 2024. Google measures this from real Chrome users over a rolling 28 day window, so your score reflects actual visitor experience, not a single lab test.

Why does PageSpeed Insights show a different score than Search Console?

PageSpeed Insights can show two different numbers: lab data from one simulated test run, and field data from real visitors on that specific URL over the past 28 days. Search Console's Core Web Vitals report uses the same field data but groups it across your whole site by page template. If you just made a fix, the lab score updates immediately while both field data sources take two to four weeks to catch up.

Can I fix Core Web Vitals myself without a developer?

Mostly, yes. Compressing images, adding width and height to image tags, removing unused third-party scripts and switching on lazy loading are things most business owners or their content editor can handle directly in WordPress, Shopify or Wix, usually through a plugin, app or theme setting rather than code. Where you may need a developer is a static or custom-coded site, or render-blocking CSS that needs restructuring rather than removing.

Will fixing Core Web Vitals alone improve my Google rankings?

A little, and only as a tie-breaker. Google has said Core Web Vitals is part of the page experience signal, which matters when two pages are otherwise closely matched on relevance and authority. It will not push a thin or poorly written page above a genuinely useful competitor. Think of it as removing a ceiling on pages that already have good content, rather than a lever that raises rankings by itself.

How often should I recheck my Core Web Vitals?

Once a month is enough for most small business sites, and immediately after any major change like a redesign, new plugin, new theme or hosting migration. Because field data is a rolling 28 day average, changes take a few weeks to fully show up in Search Console even though a PageSpeed Insights lab test reflects the fix the same day.

Your next step

Run your homepage through PageSpeed Insights right now and write down your three scores, then work through the seven steps above in order rather than jumping straight to the one that sounds easiest. For a broader technical scan beyond just speed, my free website SEO checker flags other issues in under a minute. If your scores are still poor after working through this guide and you suspect deeper render-blocking CSS or a hosting problem, 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 for business owners.
• Once your pages are fast, make sure they are built to rank with the free on-page SEO checklist for 2026.
• Speed is only one input into whether SEO delivers a return at all. My honest take is in does SEO still work in 2026.
• See how fast, well-structured pages also help with AI search visibility in SEO vs GEO in 2026.
• If Google cannot find your pages in the first place, none of this matters; start with what crawling means in SEO.