Core Web Vitals for Small Business Websites: How to Fix LCP, INP and CLS

What are Core Web Vitals, in plain English?

Core Web Vitals are three numbers Google uses to describe how a page feels to a real visitor. Does the main content appear quickly? Does the page respond when I tap something? Does the layout stay still, or does the button jump away just as I reach for it?

Each question has a metric. Largest Contentful Paint (LCP) measures loading: how long until the largest image or block of text in the visible area is shown. Interaction to Next Paint (INP) measures responsiveness: how long the page takes to visibly respond after a click, tap or key press. Cumulative Layout Shift (CLS) measures visual stability: how much content moves around unexpectedly while the page is in use.

INP is the newest. It replaced First Input Delay as a Core Web Vital in 2024, and it is stricter, because it looks at interactions throughout a visit, not just the first one. Many sites that passed under the old measure now fail on INP, and small business sites loaded with plugins and widgets are among the most affected.

What scores count as good?

Google publishes three bands for each metric. Aim for the good band on all three.

• LCP: good within 2.5 seconds, poor beyond 4 seconds.
• INP: good at 200 milliseconds or less, needs improvement up to 500 ms, poor above 500 ms.
• CLS: good at 0.1 or less, poor above 0.25.
• How it is judged: at the 75th percentile of real page loads, separately for mobile and desktop. Three out of four visits must meet the target.

Do Core Web Vitals affect Google rankings?

Yes, but less than many vendors suggest. Google's own documentation says its core ranking systems use Core Web Vitals as part of page experience, that relevance comes first, and that Google will show the most relevant content even if its page experience is poor. It also says good scores do not guarantee a top ranking.

In practice, a fast page will not outrank a slow one that answers the search far better. Where several pages are similarly useful, page experience can tip the balance. That makes vitals a tie-breaker in competitive searches, not a shortcut.

The stronger reason to care is your customers. A page that loads slowly on a phone, freezes when someone taps Book now, or jumps as they try to press Call loses enquiries regardless of where it ranks. Fixing vitals is usually as much a conversion project as an SEO one.

How do you check your Core Web Vitals?

Start with field data, which comes from real Chrome users through the Chrome User Experience Report, known as CrUX. This is the data Google uses.

Google Search Console has a Core Web Vitals report that groups similar pages and labels them good, needs improvement or poor, for mobile and desktop. It is free and covers your whole site, but only once there is enough traffic. Smaller sites often see no data, because CrUX needs a minimum number of visits.

PageSpeed Insights at pagespeed.web.dev shows the field data for a single URL, or for the whole site, when available, plus a lab test run by Lighthouse. The lab test simulates a mid-range phone on a slow connection and lists specific problems. Use it to diagnose, not to judge. A lab score of 70 on a page whose real visitors all have a good experience is not a problem.

When you fix something, Search Console lets you start a validation, which monitors the affected pages for 28 days. Field data is a rolling average, so improvements take several weeks to show fully.

How do you fix a slow Largest Contentful Paint?

Find the LCP element first. PageSpeed Insights names it. On most small business pages it is the hero image at the top, sometimes a large headline.

Google breaks LCP into four parts: the time for the server to respond, the delay before the browser starts downloading the LCP resource, the download itself, and the time to render it. Each points to a different fix.

Slow server response: cheap shared hosting, an overloaded WordPress install or no caching. Page caching and a content delivery network usually help most. Static or pre-rendered pages, such as those produced by Next.js static export, start fast by design.

Late start: the image is only discovered after scripts run, or it is lazy-loaded. Google's guidance is direct: never lazy-load the LCP image. Put it in the HTML, and mark it with fetchpriority high so the browser downloads it first.

Slow download: the image is far too large. A 4,000-pixel photograph straight from a camera, saved as a 3 MB JPEG, is common on small business sites. Resize it to the size it is displayed at, serve it in a modern format such as WebP or AVIF, and provide smaller versions for phones.

Slow render: fonts, stylesheets or scripts that block the page from painting. Reduce render-blocking CSS, and let text show in a fallback font while the web font loads.

• Do not lazy-load the main image at the top of the page.
• Add fetchpriority high to that image only.
• Resize and compress images, and serve WebP or AVIF.
• Use page caching and a CDN, or pre-rendered pages.
• Remove sliders and autoplay video from the top of the page.

How do you fix a poor Interaction to Next Paint?

INP is almost always a JavaScript problem. When a visitor taps a button, the browser has to run the code that handles the tap and then redraw the screen. If the browser's main thread is busy running other scripts, the tap waits. Google splits each interaction into input delay, processing time and presentation delay, and on small business sites the input delay caused by other scripts is usually the biggest.

The usual culprits are third-party scripts: chat widgets, booking and review widgets, social feeds, multiple analytics and advertising tags, heat-mapping tools and A/B testing scripts. Then come heavy themes and page builders that ship large amounts of JavaScript for features the page does not use.

The fixes follow from that. Audit every script on the site and remove what nobody uses. Load what remains after the page has finished its main work, or only when the visitor needs it. A chat widget can appear as a simple button and load its full code when tapped. Keep the code that runs when someone taps a button small, and break long tasks into smaller pieces so the browser can respond in between.

Field INP comes from real taps, so lab tools can only estimate it. Lighthouse reports Total Blocking Time, which is a good lab proxy: a high blocking time almost always means poor INP on real phones.

How do you fix Cumulative Layout Shift?

Layout shift happens when something appears or changes size after the page has started showing, pushing other content down or sideways. The visitor loses their place, or taps the wrong thing.

The commonest causes are images and videos without width and height, so the browser does not know how much space to reserve; banners, cookie notices and promotional bars that slide in at the top; ads and embeds that load late; and web fonts that render at a different size from the fallback font.

The fixes are mostly simple. Give every image and video its dimensions or a fixed aspect ratio. Reserve space for any banner or embed before it loads, or show it as an overlay that does not move the content. Load fonts with a fallback whose size is adjusted to match. CLS is usually the easiest of the three to bring into the good range.

A real example: what our own audit found

We ran a full audit of our own website in October 2026, and it is a useful example because it shows how a well-built site can still have one large problem.

On search basics, the site was clean: every page had a unique title and description, a canonical tag and valid structured data, and layout shift was close to zero. But Lighthouse's mobile test of one blog post scored 36 for performance, with a lab LCP of 11.2 seconds and a Total Blocking Time of 7.7 seconds. The home page scored 52 and a service page 63. These lab tests ran with mobile throttling on a modest office PC, so the absolute times are pessimistic, but the pattern was clear.

The cause was a single feature. Our site has an animated 3D mascot, Buddy, that opens a chat assistant. Its 3D library was about 554 KB of JavaScript, loaded and run on every page as soon as the page opened, and on a throttled phone it occupied the main thread for around nine seconds. Everything else waited behind it.

The fix we have planned keeps the mascot but changes when it loads: a lightweight static image appears straight away, and the 3D scene loads once the page has finished its main work or when a visitor taps it. The lesson applies to any small business site. One widget, chosen for good reasons, can cost more than everything else on the page put together. Measure before you add, and load the extras last.

Platform tips: WordPress, Shopify, Wix and Squarespace

WordPress: the platform can be fast, but themes and plugins often are not. Use a lightweight theme, a caching plugin, an image optimisation plugin and good hosting, and remove plugins you do not use. Page builders add weight, so use them sparingly. Our comparison of Next.js and WordPress covers when a different approach makes sense.

Shopify: the platform handles hosting and caching well, so most problems come from the theme and apps. Every app can add scripts to every page, including apps you uninstalled whose code was left in the theme. Audit apps regularly, choose a well-built theme and compress product images.

Wix and Squarespace: you control less of the code, so focus on what you can: fewer heavy sections, compressed images, no autoplay video at the top and fewer third-party embeds.

On every platform, the same rule holds: each widget, tracker and embed has a cost. Keep the ones that earn their place.

Your Core Web Vitals checklist

Work through this list on your five most important pages, on mobile, starting with the home page and the pages that bring the most enquiries.

• Check Search Console's Core Web Vitals report and PageSpeed Insights field data.
• Identify the LCP element on each page.
• Resize, compress and convert large images; never lazy-load the top image.
• Add fetchpriority high to the main image.
• Turn on page caching and a CDN, or improve hosting.
• List every third-party script; remove unused ones and delay the rest.
• Load chat and other widgets on interaction, not on page load.
• Set width and height on every image and video.
• Reserve space for banners, embeds and cookie notices.
• Re-test, then start a validation in Search Console and wait 28 days.

When should you get professional help?

Many fixes, such as compressing images, removing plugins and apps, and taking autoplay video off the home page, are within an owner's reach. Professional help pays off when the problem is in the theme or the code, when scripts must be deferred without breaking tracking or bookings, or when the site needs rebuilding on a faster foundation.

We build and optimise websites for US businesses, working remotely from Pune, India, and we hold our own site to the same checklist. If you would like a second opinion, send us your website address through the contact page and we will reply in writing with the three changes we would make first. Our web design for US businesses and conversion rate optimization pages describe how we work, and our website redesign checklist covers what to protect if a rebuild is the answer.