Interaction to Next Paint (INP) is the metric that actually measures what users feel: how long until the page responds to their tap. It replaced FID for a reason — responsiveness is the new speed. Every millisecond of main-thread jank is a user deciding your app is broken.
Our checklist starts before the HTML: critical CSS inlined, fonts preloaded with size-adjusted fallbacks, and zero third-party scripts that can't be deferred. If a script doesn't contribute to the first paint, it doesn't run before it.
For interactivity, the rule is simple: keep the main thread free. Image decoding on a worker, heavy computation in web workers or server-side, and hydration strategies that let the page respond before React finishes loading. Islands architecture has quietly become default for content-heavy sites.
Finally, measure in production, not in lab. Field data from real users is the only truth — lab scores are a smoke test. We wire CrUX data into CI so a regression in field INP fails the build before it fails your users.
Interaction to Next Paint replaced First Input Delay as the responsiveness metric, and it is a far harsher grader. INP measures the full latency of the worst interactions, not just the first one, which means the long task hiding behind your third button click finally counts. The practical fix is the same as it ever was: less JavaScript on the main thread, and whatever remains gets chunked, deferred and yielded.
Largest Contentful Paint is usually an image problem wearing a performance costume. Serve correctly sized images, preload the hero, put bytes on a CDN, and stop loading three font families you barely use. Get the file close to the user and the paint early, and most budgets pass without heroic engineering.
Cumulative Layout Shift is solved by reserving space. Explicit width and height on media, fixed aspect-ratio boxes for embeds, and font-display swap turn the page from a moving target into something a finger can reliably tap. Zero-point-one layout shift is a choice, not an accident.
Measure the field, not the lab. Lighthouse scores are directional, but rankings use real-user data from the Chrome UX Report. A lab score of 100 on your laptop with a warm cache means little if the seventy-fifth-percentile user on a mid-range Android device on 4G is waiting four seconds. Build a small RUM pipeline and optimise for the users you actually have.
The commercial case keeps strengthening. Core Web Vitals act as a tiebreaker between comparable results, and every field study shows conversion improving as latency falls. Fast is not a feature you ship once. It is a budget you defend in every pull request.
Enjoyed this? Let's talk about applying it to your product.
