Core Web Vitals for Local Business Websites

Core Web Vitals are the three user-experience measurements Google collects from real Chrome users and folds into its page experience signals: Largest Contentful Paint (loading), Cumulative Layout Shift (visual stability), and Interaction to Next Paint (responsiveness). For a local business website — a restaurant, a detailer, a contractor — they are also a decent proxy for something more commercially important: whether a visitor on a phone, on cellular, actually sees your page before they give up.

The three metrics, in plain engineering terms

Largest Contentful Paint (LCP)

The time until the largest visible element — almost always the hero image or headline — finishes rendering. Google's threshold for "good" is 2.5 seconds at the 75th percentile of real users. The usual offenders on small-business sites are oversized hero images, render-blocking CSS, and web fonts that delay text paint. The fixes are equally unglamorous: properly sized and compressed images (AVIF/WebP), fetchpriority="high" on the LCP image, preloaded self-hosted fonts, and no third-party scripts ahead of first paint.

Cumulative Layout Shift (CLS)

A score for how much the page visibly jumps while loading. Good is under 0.1. Layout shift is almost always self-inflicted: images without width/height attributes, late-injected banners, and fonts that swap in at a different size. Reserving space for every image and embed, and using font-display: swap with metric-compatible fallbacks, eliminates nearly all of it.

Interaction to Next Paint (INP)

INP replaced First Input Delay in March 2024. It measures the time from a user interaction — a tap, a click, a keypress — to the next visual update, across the whole visit. Good is under 200 ms. Heavy JavaScript is the cause and less JavaScript is the cure; a static or mostly-static site with small, deferred scripts will rarely see INP problems at all.

Field data versus lab data

This distinction is the most common source of confusion we see. Lab data (Lighthouse, PageSpeed Insights' simulated run) is a controlled test on synthetic hardware — invaluable for debugging, meaningless as a ranking input. Field data (the Chrome User Experience Report, "CrUX") is what real visitors experienced over the trailing 28 days, and it is what Google actually uses. A page can score 100 in Lighthouse and still fail Core Web Vitals in the field, or the reverse. Low-traffic sites often have no CrUX data at all — Search Console will simply show nothing, which is normal and not a defect.

Lab data tells you what could be wrong. Field data tells you what is wrong. Only field data affects search.

Do Core Web Vitals affect rankings?

Yes, but modestly — and Google has been consistent about this. Page experience is a tie-breaker among relevant results, not a shortcut past better content. The reason we hold every build to a strict budget anyway is that the commercial effect is much larger than the ranking effect: industry studies (Google/Deloitte's "Milliseconds Make Millions" among them) repeatedly find measurable conversion lift per 100 ms of speed improvement. A fast site earns its keep whether or not the algorithm notices.

The BYHS performance budget

Every website we ship is built to hold these numbers on a mid-range phone over 4G, not a desktop on fiber:

The budget is deliberately tighter than the public thresholds. The 75th-percentile rule means a site that is merely "good" on average can still fail for its slowest quarter of visitors — which, for local businesses, is exactly the on-the-go phone traffic most likely to convert.

How we verify

• Search Console → Core Web Vitals report for field data per URL group.
• PageSpeed Insights for the CrUX summary plus a lab diagnosis in one place.
• Lighthouse in CI against the deployed site, not localhost, so CDN and header behavior are included.
• This site is the control: techniques land here first and are watched for a full CrUX cycle before they become part of the BYHS build standard.

← All research