Core Web Vitals without the jargon: LCP, CLS and INP for business owners

Your developer says the site is fast. Your customers say it’s slow. Core Web Vitals settle the argument. They’re three measurements Google publishes and uses as part of its page experience signals, and they’re taken from real visits by real people using Chrome, not from a lab.

You don’t need to read the specs. You need to know what each one measures, what ‘good’ looks like, and what to ask your team to fix.

LCP: how long until the page looks ready

Largest Contentful Paint measures how long it takes for the biggest thing in the visible screen, usually a hero image or headline, to appear. It’s the moment a visitor feels the page has loaded. Google’s threshold for ‘good’ is 2.5 seconds or less.

Common causes and fixes

• Huge hero images. Serve modern formats like WebP or AVIF, at the size the screen actually needs.
• The hero image is discovered late. Put it in the HTML, don’t lazy-load it, and give it a high fetch priority.
• The headline waits for a web font or an animation. Show text immediately with a fallback font, and never start the main heading invisible.
• Slow server response. Use caching and a CDN, and look at what your hosting is doing on each request.
• Too much JavaScript before anything shows. Defer anything not needed for the first screen.

<img
  src="/hero.avif"
  width="1200"
  height="630"
  fetchpriority="high"
  alt="Team planning a website in a Bengaluru studio"
/>

CLS: does the page jump around

Cumulative Layout Shift measures how much the page moves unexpectedly while someone is looking at it. You’ve felt it: you go to tap a link and an ad loads above it, and you tap the wrong thing. Google’s threshold for ‘good’ is a score of 0.1 or less.

Common causes and fixes

• Images and videos without dimensions. Always set width and height, or an aspect ratio, so the browser reserves space.
• Banners, cookie bars and ads that push content down. Reserve their space, or overlay them instead of inserting them.
• Web fonts that swap in at a very different size. Choose fallbacks with similar metrics, or adjust them so the swap barely moves anything.
• Content injected above existing content after load. Add new things below, or make room for them in advance.

INP: does the page respond when you touch it

Interaction to Next Paint measures how quickly the page visibly responds after someone taps, clicks or types. It replaced an older metric, First Input Delay, in March 2024, and it’s stricter because it looks at interactions across the whole visit, not just the first one. Google’s threshold for ‘good’ is 200 milliseconds or less.

Poor INP is the ‘I tapped the button and nothing happened, so I tapped it again’ problem. It’s usually caused by the browser being busy running JavaScript when the visitor tries to interact.

Common causes and fixes

• Too many third-party scripts: chat widgets, trackers, tag managers full of old tags. Audit them. Remove what nobody uses.
• Long tasks that block the main thread. Break big pieces of work into smaller chunks so the browser can respond in between.
• Heavy work on every keystroke or click. Show instant feedback first, then do the expensive part.
• Large page structures. Very big pages with thousands of elements make every update slower.

Where to see your numbers

• PageSpeed Insights (pagespeed.web.dev): paste a URL. The top section shows field data from real Chrome users, if your site has enough traffic. The lower section is a lab test, useful for diagnosis.
• Google Search Console: the Core Web Vitals report groups your pages by status, so you can see which templates are failing.
• Your own monitoring: real-user monitoring tools record the metrics from every visit, including from browsers Google’s data doesn’t cover.

Why business owners should care

Core Web Vitals are one of many signals in Google’s ranking systems. Good scores won’t rescue weak content, and great content can still rank with average scores. But the bigger reason is simpler: slow, jumpy, unresponsive pages frustrate people, and frustrated people leave. Every form, checkout and enquiry button lives on a page that has to load, sit still and respond.

Fix templates, not pages

Most sites are built from a handful of templates: home, product, category, article, contact. A problem in a template repeats on every page that uses it, and so does the fix. Start with the template behind your most visited and most valuable pages, fix it once, and watch the whole group improve. Search Console’s grouping helps here, because it clusters similar URLs that tend to share a template.

Field data takes time to catch up. Because it covers a rolling 28 days, a fix shipped today shows its full effect in the report a few weeks later. Use lab tests to confirm the fix straight away, then let the field data confirm it for real users.

Questions to ask your team

1. What are our field LCP, CLS and INP on mobile, for our top five landing pages?
2. Which third-party scripts load on every page, and who owns each one?
3. What’s the LCP element on the homepage, and is it ever hidden while JavaScript loads?
4. Do we test performance before every release, or only when someone complains?

The verdict

Show the main content fast. Keep it still. Respond the moment someone touches it. That’s all three metrics in nine words. The fixes are rarely glamorous: smaller images, fewer scripts, reserved space. They’re also some of the cheapest improvements you can make to a site that already exists.