Skip to content
Vezqor Group logoVezqor Group logo

INP and Core Web Vitals: A Plain-English Guide to Site Speed

INP replaced FID as a Core Web Vital. Learn what it measures, what a good score is and the fixes that actually move it.

Core Web Vitals are Google's three measures of how a page feels to real visitors: loading speed (LCP), responsiveness (INP) and visual stability (CLS). A page passes when at least 75% of real visits meet the "good" threshold for each. INP, Interaction to Next Paint, replaced First Input Delay as the responsiveness metric in March 2024, and it is the one most sites now fail.

The three numbers to know

  • LCP (Largest Contentful Paint): how long until the main content appears. Good is 2.5 seconds or less.
  • INP (Interaction to Next Paint): how long the page takes to visibly respond after a tap, click or key press. Good is 200 milliseconds or less.
  • CLS (Cumulative Layout Shift): how much the layout jumps while loading. Good is 0.1 or less.

What INP actually measures

FID only looked at the first interaction, and only the delay before the browser started handling it. INP looks at nearly every interaction during the visit and measures the full time until the screen updates. A menu that freezes for half a second on the fifth tap now counts against you.

Why speed matters for business

Speed affects both rankings and revenue. Google uses Core Web Vitals as a page experience signal, and slow, janky pages lose visitors before they read your offer. On mobile, where most Pakistani traffic arrives, on mid-range phones and variable networks, the effect is larger.

How to check your site

  1. Open PageSpeed Insights and test your home page and a service page on mobile.
  2. Look at the "Discover what your real users are experiencing" section. That is field data from real visitors and it is what Google uses.
  3. Open the Core Web Vitals report in Google Search Console to see which groups of URLs fail.

Fixes that move INP

  • Ship less JavaScript. Remove unused libraries and split code so each page loads only what it needs. Heavy animation libraries and smooth-scroll scripts should load only where they are used.
  • Break up long tasks. Any script that blocks the main thread for more than 50 ms delays the next tap. Defer non-critical work until the browser is idle.
  • Keep event handlers light. Do the minimum on click, show the result, then do the rest.
  • Limit third-party scripts. Chat widgets, trackers and tag managers are common causes. Load them after interaction or remove the ones nobody uses.
  • Avoid giant DOMs. Thousands of elements make every update slower.

Fixes that move LCP and CLS

  • Compress and properly size the hero image, and serve modern formats like WebP or AVIF.
  • Preload the main font and use font-display: swap.
  • Set width and height on images and embeds so nothing jumps.
  • Use a CDN and server caching so the first byte arrives quickly.

A note on frameworks

Next.js gives you server rendering, image optimisation and automatic code splitting, which help LCP. But it does not fix a heavy client bundle: INP depends on what you ship to the browser, so it needs deliberate attention.

Where to start

Test mobile, fix the biggest offender first, and re-test after 28 days, because field data updates on a rolling window. If you want a prioritised speed plan, talk to our web team.

  • #INP
  • #CoreWebVitals
  • #InteractiontoNextPaint
  • #LCP
  • #CLS
  • #websitespeed
  • #Next.jsperformance
INP and Core Web Vitals: A Plain-English Guide to Site Speed