How to Improve Core Web Vitals on a Small Business Website (2026 Guide)

Most Core Web Vitals advice online is written for sites with a full performance team. You probably don’t have one. You have a WordPress site, or maybe a static site you built yourself, and Google is telling you that your pages are slow. This guide covers what actually moves the needle in 2026: the three metrics that matter, how to measure them without guessing, and the specific fixes that work on real small business sites.

The three metrics, and what actually counts as “good”

Google’s thresholds haven’t changed much, but the way they’re measured has. Everything is field data now. Lab scores from Lighthouse are useful for debugging, but the numbers Google uses come from the Chrome User Experience Report (CrUX), which is real users on real devices, mostly phones.

• LCP (Largest Contentful Paint): under 2.5 seconds. This is usually your hero image or your main heading.
• INP (Interaction to Next Paint): under 200 milliseconds. This replaced First Input Delay in March 2024. It measures how long the page takes to respond to a tap or click, and it catches slow JavaScript that FID used to miss.
• CLS (Cumulative Layout Shift): under 0.1. This is stuff jumping around while the page loads.

A page passes only if 75% of real visits hit all three thresholds. That “75% of visits” part matters. If your site gets a lot of traffic on older Android phones, your field data will be worse than your desktop Lighthouse score, and the field data is what counts.

Measure first, and use the right tool

Before you touch anything, get a baseline. Three tools, in this order:

• PageSpeed Insights for the field data up top (the CrUX section) plus a lab audit below it. Ignore the lab score if the field data is fine.
• Search Console > Core Web Vitals for the site-wide view. This groups URLs by issue type so you can see if it’s one template or everything.
• Chrome DevTools Performance panel for the actual cause. This is where you find out why LCP is 4 seconds.

One warning: don’t optimize based on a single Lighthouse run on your fast laptop. Enable CPU throttling and network throttling in DevTools, or you’ll spend a week fixing problems your users don’t have while missing the ones they do.

Fixing LCP

LCP is almost always one of four things: slow server response, a render-blocking resource, a huge hero image, or a font that blocks text. Work through them in that order.

1. The hero image

This is the most common culprit on small business sites. A 3MB JPEG from a phone camera is not a hero image. Serve modern formats and set explicit dimensions so the browser can reserve space:

<img
 src="/images/hero-1600.avif"
 srcset="/images/hero-800.avif 800w,
 /images/hero-1600.avif 1600w"
 sizes="100vw"
 width="1600"
 height="900"
 alt="Storefront on Main Street"
 fetchpriority="high"
 decoding="async">

The fetchpriority="high" attribute tells the browser this image matters more than anything else on the page. Use it on exactly one image. If you set it on five, you’ve set it on none. And do not lazy-load your hero. loading="lazy" on the LCP image is one of the most common self-inflicted performance wounds I see.

2. Server response time

If your Time to First Byte (TTFB) is over 800ms, nothing else you do will save LCP. On shared hosting with no page cache, that’s normal. Fixes, roughly in order of effort:

• Turn on full-page caching (WP Rocket, LiteSpeed Cache, or your host’s built-in cache).
• Put Cloudflare in front. The free tier handles this fine.
• If the site is mostly static, generate static HTML instead of rendering it per request.
• Move off the $5 shared plan. This is the unglamorous answer nobody wants, but a slow origin is a slow origin.

3. Fonts

Web fonts block text rendering. Self-host them (don’t rely on a third-party CDN for a font you use on every page), use woff2, and preload the one font file that renders above the fold:

<link rel="preload" href="/fonts/inter-var.woff2"
 as="font" type="font/woff2" crossorigin>

The crossorigin attribute is required even for same-origin fonts. Miss it and the preload silently does nothing.

Fixing INP

INP is a JavaScript problem, and it’s the metric most sites fail without realizing it. The cause is long tasks: any chunk of JS that runs for more than 50ms blocks the main thread, so taps feel dead.

The usual suspects on a small business site are chat widgets, analytics tag managers, and third-party embeds. Open DevTools, go to the Performance panel, record yourself clicking around, and look for long yellow blocks. Then ask which script owns them.

A few things that help without a rewrite:

• Break up long tasks. If you’re looping over a big list, yield to the browser periodically with scheduler.yield() (now broadly supported) or a setTimeout fallback.
• Debounce expensive handlers. Scroll and resize listeners that do heavy work are a classic INP killer.
• Defer or remove third-party scripts. Every chat widget, heatmap, and A/B testing tool adds main-thread work you don’t control. Audit them quarterly and delete what you’re not using.
• Move non-urgent work off the main thread with a Web Worker if it’s genuinely heavy.

Here’s a simple yield helper that works in 2026 without a polyfill dependency:

async function processItems(items) {
 for (const item of items) {
 doWork(item);
 // Yield every item so the browser can handle input.
 if (scheduler?.yield) {
 await scheduler.yield();
 } else {
 await new Promise(r => setTimeout(r, 0));
 }
 }
}

Fixing CLS

Layout shift is the easiest of the three to fix, and it’s almost always caused by the same handful of things.

Reserve space for images and embeds

Set width and height on every image. For responsive images, wrap them so the aspect ratio is locked:

.media {
 aspect-ratio: 16 / 9;
 width: 100%;
}
.media img {
 width: 100%;
 height: 100%;
 object-fit: cover;
}

Same idea for iframes. A YouTube embed with no reserved height will shove your whole page down when it loads. Set the container’s aspect ratio first.

Stop injecting banners above content

Cookie notices, promo bars, and “we’re open” banners that get inserted at the top of the DOM after load are the number one CLS source I see on local sites. Either render them server-side so they’re there on first paint, or position them fixed at the bottom where they don’t push anything.

Fonts again

If you use a custom font, the fallback font renders first and then gets swapped, which shifts text. Use font-display: swap and match your fallback’s metrics so the swap is invisible:

@font-face {
 font-family: "Inter";
 src: url("/fonts/inter-var.woff2") format("woff2");
 font-display: swap;
 size-adjust: 100%;
 ascent-override: 90%;
 descent-override: 22%;
}

Getting those override values exactly right takes some fiddling, but even approximate values cut the shift dramatically.

What I’d do first on a typical local business site

If you only have an afternoon, do these in order:

1. Compress and resize the hero image, convert it to AVIF or WebP, and add fetchpriority="high".
2. Turn on page caching and put Cloudflare in front.
3. Remove or defer third-party scripts you don’t actually use.
4. Set explicit dimensions on every image and iframe.
5. Re-check Search Console field data in 28 days. Field data lags, so don’t panic when nothing changes overnight.

That list handles most of the problems on most sites. The rest is usually template-specific, which is why it pays to know which template is failing before you start editing. If you’re not sure you want to do this yourself, this is the kind of work that falls under Long Island web design and it’s worth doing right the first time, because a slow site quietly costs you leads.

And if you’re also trying to rank locally, performance and local search overlap more than people think. Page experience is a real ranking input, and it compounds with everything else. If you’re working on both at once, my notes on Long Island SEO cover the local side of it.

FAQ

Do Core Web Vitals actually affect rankings?

They’re a tiebreaker, not a magic bullet. Google uses page experience as one of many signals. A fast page won’t outrank a more relevant one, but between two equally relevant pages, the faster one has an edge. The bigger benefit is conversion: faster pages keep more visitors.

How long until I see my changes in Search Console?

Field data is a 28-day rolling window, so expect 3 to 4 weeks before improvements show up. Lab tools like Lighthouse update immediately, which is why people get confused when the Search Console report still shows failures the day after a fix.

Should I worry about my Lighthouse score?

Only as a debugging tool. A 95 in Lighthouse with bad field data means you’re testing on hardware your users don’t have. Watch the CrUX numbers in PageSpeed Insights and the Search Console report. Those reflect the people who actually visit your site.