Skip to main content
KPZsProductions

SEO

Core Web Vitals for a business website: what to measure and fix first

LCP, INP, CLS: three metrics Google uses to judge page experience. How to measure them and which fixes to make first.

October 31, 2026 · 3 minute read

A slow site costs you: visitors leave before they see your offer, and the contact form feels broken because the button reacts late. Google captured this in three metrics called Core Web Vitals. You do not need to understand them technically, but as a business owner it is worth knowing what they mean and what to do about them.

The three metrics in plain language

  • LCP (Largest Contentful Paint) — how quickly the biggest visible element appears on load: usually a photo or a headline. Google considers under 2.5 s good.
  • INP (Interaction to Next Paint) — how fast the page responds to a click, tap or keystroke. Under 200 ms is good.
  • CLS (Cumulative Layout Shift) — whether content jumps around while loading. Under 0.1 is good.

These thresholds are published by Google on web.dev and may change, so always check the source.

How to check without a developer

  1. Open PageSpeed Insights and paste your URL. You will see real-user data (if traffic is high enough) plus a lab test.
  2. Check the Core Web Vitals report in Google Search Console, which groups problem URLs.
  3. Test on a phone and a slower connection. Most traffic to local businesses is mobile.

The difference between real-user data and lab data matters: rankings rely on the former, while the latter helps with diagnosis.

What usually breaks LCP

  • An oversized hero image (full-resolution camera files).
  • A slow server or cheap hosting with long response times.
  • The main image lazy-loaded when it should start immediately.
  • Render-blocking scripts, such as several plugins and externally loaded fonts.

Do first: shrink and compress the hero image, use a modern format (WebP or AVIF), give it high loading priority, and check server response time.

What usually breaks INP

  • Too much JavaScript: plugins, chat widgets, ad and analytics scripts.
  • Heavy animations triggered on every interaction.
  • Forms with elaborate in-browser validation.

Do first: remove scripts nobody uses, defer non-critical widgets, and find which plugins add the most code.

What usually breaks CLS

  • Images without declared dimensions.
  • Cookie banners and ads injected above content after load.
  • Fonts that change text size once they load.

Do first: set fixed aspect ratios for images and embeds, reserve space for banners, and use fonts with proper loading behaviour.

A fix order that makes business sense

  1. Pages that bring traffic and enquiries (home, services, contact) before the blog.
  2. Low-cost fixes (images, unused scripts) before any rebuild.
  3. Measure after each change, since real-user data updates with a delay of several weeks.

When fixes are not enough

If the site runs on a heavy theme and a dozen plugins, further patches give diminishing returns. Compare the cost of constantly firefighting against the cost of moving to a lighter build. Talking about it commits you to nothing: describe your site in a brief and we will tell you what can be improved without a rebuild and what cannot.

Keep it in proportion

Core Web Vitals are one signal among many. A fast site with an unclear offer still does not sell. Treat performance as a prerequisite: the page must load quickly so that the content can do its job.

Table of contents

Services this post covers

Got a question we haven't covered here?

Write it straight into a brief – we'll answer with specifics, not a link to an FAQ.

Send a brief

Newsletter

Subscribe to the newsletter

Concrete lessons from our projects, new case studies and practical tips on web apps and automation. No spam.

By subscribing, you accept the privacy policy.

We use essential cookies to run the site and, with your consent, optional PostHog analytics. Cookie Policy