Core Web Vitals Explained: LCP, INP, CLS

Your page looks fine to you. Google thinks it feels broken. That gap is what Core Web Vitals measure.

Core Web Vitals are three metrics Google uses to score how your page feels to a real person. Not how fast a server responds. How the page behaves while someone waits, reads, and taps. Since these signals feed ranking, they sit at the exact point where SEO meets user experience. Get them wrong and you lose traffic you already earned. Get them right and every other optimization compounds.

Here is what each one means, why it slips, and how to fix it without a rebuild.

LCP: how fast the main thing shows up

Largest Contentful Paint measures when the biggest visible element finishes loading. Usually a hero image, a headline block, or a banner. It answers one question. When does the page look ready?

Google wants LCP under 2.5 seconds. Most sites fail because of one heavy image, a slow server response, or render-blocking code that stalls everything else.

Fixes that move the number:

• Compress the hero image and serve it in a modern format like WebP or AVIF
• Add width and height so the browser reserves space instantly
• Preload the LCP image so it starts downloading first, not last
• Cut render-blocking CSS and JavaScript above the fold
• Put static assets on a CDN so distance stops adding delay

LCP is the metric most tied to raw speed. If your page feels slow, this is where it shows.

INP: how fast the page answers a tap

Interaction to Next Paint replaced First Input Delay in 2024. It measures the delay between a user action and the visible response. Click a button, open a menu, tick a box. How long until something happens on screen?

Google wants INP under 200 milliseconds. The usual culprit is JavaScript. When the main thread is busy running scripts, it cannot respond to input. The page freezes for a beat. Users feel it even when they cannot name it.

Fixes that help:

• Break long JavaScript tasks into smaller chunks so the browser can respond between them
• Remove or defer third-party scripts you do not strictly need
• Audit heavy analytics, chat widgets, and tag managers first
• Avoid running expensive work on every scroll or keystroke

INP punishes bloated pages hard. Every tracker and widget you bolt on costs responsiveness. This is why lean sites feel premium and cluttered ones feel cheap.

CLS: how much the layout jumps

Cumulative Layout Shift measures visual stability. You start reading. An image loads above the text and shoves it down. You go to tap a button and it moves. That jump is a layout shift, and it feels broken every time.

Google wants CLS under 0.1. The causes are almost always the same short list.

• Images and videos with no dimensions set
• Ads or embeds that load into a space with no size reserved
• Web fonts that swap and reflow the text
• Content injected above what is already on screen

The fix is boring and effective. Reserve space for everything before it loads. Set dimensions on media. Give ad slots a fixed height. Preload fonts. A stable page reads as a trustworthy page.

Lab data vs field data

This trips up almost everyone. There are two ways to measure Core Web Vitals and they disagree on purpose.

Lab data comes from a controlled test, like Lighthouse. One simulated device, one network speed, one run. It is great for debugging because it is repeatable.

Field data comes from real Chrome users on real devices, collected over 28 days. Google calls this the Chrome User Experience Report, or CrUX. This is the data that actually affects your ranking.

So your lab score can look perfect while your field score fails. Old phones, weak networks, and real behavior expose problems a clean test hides. Always trust field data for decisions and use lab data to find the cause.

Why this ranks, and why it converts

Core Web Vitals are part of Google’s page experience signals. They are not the biggest ranking factor. Relevance and content still lead. But when two pages are close, the faster, more stable one wins. And Google flags URLs as good, needs improvement, or poor, which shapes how the whole site is judged.

The bigger win is money, not rank. A page that loads fast, responds instantly, and never jumps converts better. Every hundred milliseconds of delay quietly leaks signups and sales. Speed is a growth lever wearing a technical costume. That is the same logic behind treating page speed as a conversion problem, not just an engineering one.

How to measure yours right now

You do not need a paid tool to start. Three free sources cover everything.

• PageSpeed Insights gives you both lab and field data for any URL in one view
• Search Console has a Core Web Vitals report that groups your whole site by status
• Chrome DevTools and the Lighthouse tab let you debug a single page live

Start with Search Console to see which page groups are failing. Then open PageSpeed Insights on a representative URL to find the specific metric dragging you down. Fix that one first. This is also the natural starting point for any technical SEO cleanup, since speed problems often hide deeper structural issues.

Getting started

Pick your most important page. Homepage, top landing page, or best product page. Run it through PageSpeed Insights and read the field data, not the lab score. You will almost always find one metric doing most of the damage. Fix that one thing. Measure again. Repeat.

Do not try to hit a perfect score on day one. Move each metric into the green band on your key pages, then widen from there. Small, focused fixes beat a big rewrite every time.

If you would rather have someone audit it, prioritize the fixes, and hand you a clear plan, that is exactly what we do. Message the Neurounit team on Telegram and we will take a look at your Core Web Vitals with you.