Blog

Core Web Vitals for business sites

Core Web Vitals explained for business owners: what LCP, CLS and INP mean commercially, how to measure them, and what actually improves them.

Scaledex team6 min read

Core Web Vitals are three numbers Google uses to describe how a page feels to the person loading it. They are measured from real Chrome users, reported in Search Console, and used as part of Google’s page experience signals. That is reason enough for a business to know what they are. The better reason is that they describe, in numbers, the difference between a site that feels like it works and one that people leave.

The three metrics in plain language

Largest Contentful Paint (LCP)

How long it takes for the biggest visible element, usually the hero image or the main headline, to appear on screen. Good is 2.5 seconds or less; poor is over 4 seconds. Commercially, LCP is the answer to “how long until the page looks like it has loaded”. Everything before that moment is a blank screen and a chance to give up.

Cumulative Layout Shift (CLS)

How much the page jumps around while it loads: the button that moves just as you tap it, the text that shifts when an image or a banner appears above it. Good is 0.1 or less; poor is over 0.25. Commercially, CLS is mis-taps, wrong clicks and a general feeling that the site is flimsy.

Interaction to Next Paint (INP)

How long the page takes to respond visibly after a tap, click or key press, measured across the whole visit and reported as the worst typical case. Good is 200 milliseconds or less; poor is over 500. INP replaced First Input Delay in March 2024 and is stricter, because it counts every interaction, not just the first. Commercially, INP is the menu that does not open, the filter that lags, the form that seems to ignore the button.

How they are measured

Each metric is taken at the 75th percentile of real page loads over the previous 28 days, from Chrome users who have opted into reporting, separately for mobile and desktop. Your own laptop on office fibre is not the measurement. A visitor on a mid-range Android phone on a mobile connection is closer to it.

Why a business should care

Search is the obvious reason. Page experience is one ranking consideration among many; it will not rescue thin content, but pages rated poor lose tie-breakers to competitors that are not, and Search Console will keep telling you about them.

The larger reason is money already spent. Every visitor arrived because of something you paid for: an ad, a campaign, a salesperson’s follow-up, months of content. A slow or shifting page loses a share of those visitors before they see the offer. Google and several large retailers have published studies linking load time to conversion; the exact figures vary by site and audience, so the useful number is your own. Segment your analytics by page speed and look at conversion in each bucket.

There is a quieter benefit. Fast pages are usually simpler pages, with less JavaScript and fewer third-party tags. Simpler pages break less often and cost less to maintain.

Finding out where you stand

  • Search Console’s Core Web Vitals report shows field data for groups of URLs, flagged good, needs improvement or poor. Start here.
  • PageSpeed Insights shows field data for a single URL at the top and a lab test underneath. Trust the field data; use the lab data to find causes.
  • Real-user monitoring on your own site, whether Cloudflare Web Analytics or another tool, gives you the same numbers with more detail and no 28-day lag.
  • Lighthouse in a build pipeline catches regressions before they ship. It is a lab measurement, so it is not the score that matters, but it stops the numbers getting worse.

What actually moves LCP

  1. Server response time. If the HTML takes a second to arrive, nothing else matters. Prerender pages where you can, cache aggressively at the edge, and avoid a CMS that renders every request from scratch.
  2. Render-blocking resources. Stylesheets and scripts in the head that the browser must fetch before it can draw anything. Keep CSS small enough to inline, and defer scripts.
  3. The LCP element itself. If it is an image: size it correctly, serve AVIF or WebP, mark it high priority, never lazy-load it, and preload it if it is referenced from CSS. If it is text, the font is the problem, which is the next item.
  4. Fonts. Self-host one family, subset it, preload the file and use a font-display strategy that shows text immediately. Every extra family and weight is another download in front of your headline.
  5. Third-party scripts. Tag managers, chat widgets, consent tools and analytics compete with your content for bandwidth and CPU. Load them after the page is usable, or not at all.

What actually moves CLS

  1. Width and height on every image, video, iframe and embed, so the browser reserves the space before the asset arrives.
  2. Reserved space for anything injected late: banners, cookie notices, promotional bars, embedded forms.
  3. Font fallbacks with matching metrics, so the swap from the fallback font to the real one does not reflow the page.
  4. No content inserted above existing content after load. If a notification bar must appear, it must have had its space from the start.
  5. Animations on transform and opacity, not on properties that change layout.

What actually moves INP

  1. Less JavaScript on the main thread. This is the whole story for most business sites. The main causes are third-party tags and frameworks that hydrate an entire page of static content so that one menu can open. A marketing site needs almost no JavaScript; a product page needs it only where something is interactive.
  2. Shorter tasks. Long-running scripts block every interaction that happens during them. Break work up, respond to the input first and do the heavy part afterwards.
  3. Smaller pages. Thousands of DOM nodes and expensive CSS make every interaction slower, because each one triggers layout work.
  4. Immediate visual feedback. A pressed state or a spinner within a frame makes an interaction feel responsive even when the work behind it takes longer.
  5. An audit of the handlers on controls people actually use: navigation, search, filters and form validation.

An order of work for a typical business site

  1. Measure. Get the field data from Search Console and pick the page groups that matter commercially: home, service or product pages, the contact or checkout flow.
  2. Fix hosting and caching. This is usually the single biggest LCP change and often the cheapest.
  3. Fix the LCP element and the fonts on the important templates.
  4. Add dimensions to media and reserve space for late content.
  5. Audit third-party tags. List every script, name the person who reads its output, and remove the ones nobody claims. This is where INP is won.
  6. Reduce framework JavaScript on content pages.
  7. Wait 28 days and measure again; the field data needs a full window to reflect a change.

How we build for it

The sites we build start from the position that makes all of this easy: every page prerendered and served from the edge, CSS inlined, one self-hosted font, images with explicit dimensions in modern formats, and no JavaScript unless a component needs it. Performance and accessibility budgets run on every build, so a regression fails the build rather than reaching Search Console a month later. This site is built the same way, and the only interactive component on it is the contact form.

If your site is rated poor and you would like to know why, get in touch and we will start with the measurement.

  • performance
  • core-web-vitals
  • seo
  • web