Skip to main content
SEO

Core Web Vitals for marketers who don't write code

What LCP, INP, and CLS actually measure, which ones affect rankings, and how to brief a developer without guessing.

Ankit Chandra3 min read

Core Web Vitals get discussed as though they're a single score. They're three separate measurements of three unrelated problems, and conflating them is why so many "make the site faster" briefs produce no improvement.

The three metrics, plainly

LCP, Largest Contentful Paint

Measures: how long until the biggest visible thing on screen has loaded. Usually a hero image or headline.

Target: under 2.5 seconds for 75% of visits.

Usually caused by: an oversized hero image, a slow server response, or render-blocking resources in the <head>.

This is the one most sites fail and the one most worth fixing, because it correlates directly with whether someone stays.

INP, Interaction to Next Paint

Measures: how long the page takes to visibly respond after someone taps or clicks. Replaced First Input Delay in 2024.

Target: under 200 milliseconds.

Usually caused by: too much JavaScript running on the main thread. Chat widgets, tag managers firing a dozen scripts, heavy analytics, and carousel libraries are the repeat offenders.

INP is where marketing tooling does most of its damage. Every tag you add through GTM has a cost, and it's paid by the visitor, on their device.

CLS, Cumulative Layout Shift

Measures: how much the page jumps around while loading.

Target: under 0.1.

Usually caused by: images without width and height attributes, ads or embeds injected above existing content, and web fonts that swap and reflow the text.

CLS is the cheapest of the three to fix and by far the most irritating to be on the receiving end of. It is what makes you tap the wrong thing because a banner loaded half a second late.

How much do they affect rankings?

Less than page-speed vendors imply, and more than nothing.

Core Web Vitals are a ranking signal, but a weak one relative to relevance and authority. A slow page with the best answer will usually outrank a fast page with a mediocre one.

Where they matter more:

  • As a tiebreaker between similarly relevant results
  • On conversion rate, which is not a ranking factor but is the reason you wanted the traffic
  • On crawl efficiency, since faster responses mean more of your site gets crawled per visit

Fix them for the second reason. The ranking benefit is a bonus.

Getting real numbers

Field data, what actual visitors experienced. This is what Google uses.

  • Search Console → Core Web Vitals report
  • Chrome User Experience Report (CrUX)

Lab data, a simulated load in a controlled environment. Useful for debugging, not for judging.

  • Lighthouse in Chrome DevTools
  • PageSpeed Insights (shows both, which is why it confuses people)

The distinction matters: a perfect Lighthouse score with failing field data means your real visitors are on slower devices and worse connections than your test. Trust the field data.

Briefing a developer without guessing

Vague briefs get vague results. Instead of "the site is slow", give them:

Our LCP on mobile is 4.1s at the 75th percentile, per Search Console. The LCP element on the homepage is the hero image, currently a 1.2MB PNG. Please serve it as AVIF with a WebP fallback, sized responsively, and preload it. Target is under 2.5s.

That brief can be actioned in an afternoon. "Make it faster" cannot.

The tag manager conversation

At some point, someone will want to add a fifth tracking script. It's worth having a standing rule:

  • Every tag has an owner and a stated purpose
  • Tags get audited quarterly and removed if the owner can't say what decision they inform
  • Anything not needed for the initial render loads after interaction

Most sites carrying an INP problem are carrying it because nobody has ever removed a tag. They only ever get added.

Ankit Chandra

Digital Marketing Consultant working on SEO, performance marketing, and creator programmes for brands that measure growth in revenue.

Work with me

Get the next one by email

One email per new article. Nothing else.

Related reading