Core Web Vitals: What INP Means

Google's Core Web Vitals are three numbers that measure how a page feels to a real visitor — how fast it shows up, how stable it is, and how quickly it responds. They influence search ranking, but more importantly they correlate with whether people stay. In 2024 one of the three changed, so it is worth a fresh look.

The three metrics

Core Web Vitals boil the messy question of "is this page good to use?" down to three measurable things:

• LCP — Largest Contentful Paint. How long until the biggest visible element (usually the hero image or headline) has loaded. It measures perceived load speed. Aim for under 2.5 seconds.
• INP — Interaction to Next Paint. How quickly the page responds when you tap or click — the delay between your action and the screen visibly updating. It measures responsiveness. Aim for under 200 milliseconds.
• CLS — Cumulative Layout Shift. How much the page jumps around as it loads. It measures visual stability. Aim for under 0.1.

A page that loads fast, reacts instantly and does not shift under your thumb scores well on all three.

The big change: INP replaced FID

Until recently the responsiveness metric was FID (First Input Delay), which only measured the delay on your first interaction, and only the input delay part. It was too easy to pass — most pages did, even ones that felt sluggish.

INP replaced it as a Core Web Vital in March 2024. INP is tougher: it looks at interactions throughout the whole visit, and it measures the full time until the screen updates, not just the initial delay. If a page janks every time you open a menu or filter a list, INP catches it where FID shrugged. For many sites, INP is now the hardest of the three to pass.

What drags each metric down

• LCP suffers from slow servers, huge unoptimised images, render-blocking scripts and fonts. The fixes: compress and correctly size images, serve modern formats, cache aggressively, and preload the key resources.
• INP suffers from heavy JavaScript. When the main thread is busy running scripts, it cannot respond to your tap. The fixes: do less work on the main thread, break up long tasks, and defer non-essential code.
• CLS suffers from images without declared dimensions, ads and embeds that push content down, and web fonts that reflow text. The fixes: always set width and height on images, reserve space for dynamic content, and load fonts carefully.

Lab data vs real users

An important subtlety: a lab test runs once, on one machine, under controlled conditions. Core Web Vitals, as Google uses them for ranking, come from real visitors on real devices and networks (field data). A page can look perfect in a lab test and still fail in the field because actual users are on mid-range phones and patchy connections. Treat lab tools as a fast debugging aid, but trust field data for the real verdict.

Where to start

Measure first — you cannot improve what you have not quantified. Then fix in order of impact: images are usually the quickest LCP win, declared dimensions the quickest CLS win, and trimming JavaScript the main INP lever.

Running an automated audit of a page's SEO and performance signals, checking that it renders well across screen sizes, confirming compression is switched on, and inspecting the response headers that control caching all run from your browser. They point you at the specific weaknesses behind a poor score, so you can turn three abstract numbers into a concrete list of fixes — and watch them improve.