Core Web Vitals in practice: what actually moves LCP, INP and CLS on a Next.js site

Lighthouse simulates one device, one connection and one page load with no extensions installed. CrUX reports what actually happened to Chrome users over the previous 28 days, at the 75th percentile. Those two numbers can differ by a factor of two and both are correct; they answer different questions. Make decisions on CrUX and treat Lighthouse as a way of diagnosing a single change.

For ongoing visibility we poll the PageSpeed Insights API daily for the twenty most important page templates and write the results to a sheet. For deeper diagnosis we ship the web-vitals library in its attribution build, which returns not only the metric value but the element responsible for LCP and the script that blocked the main thread. Without attribution, any conversation about INP is guesswork.

In Next.js, useReportWebVitals sends this to your own endpoint. A small receiver writing into an analytics table, split by page template and device type, is enough. After two weeks you have a picture no external audit can give you, because you are looking at a distribution rather than an average that describes nobody.

LCP decomposes into four parts: time to first byte, resource load delay, resource load duration and element render delay. Splitting them tells you immediately where to look. If TTFB is 900 ms, optimising the image is pointless until the server-side caching layer is sorted. In practice the winning combination is usually incremental regeneration with a short revalidation window plus s-maxage with stale-while-revalidate at the CDN.

The second common failure is a hero image that only starts loading after hydration, because it sits in a client component or a carousel. next/image with the priority attribute sets fetchpriority to high and adds a preload, but only when the element is present in the initial HTML. A client-rendered carousel pushes the load start out by 400 to 800 ms, and no amount of format tuning recovers that.

Web fonts add 200 to 300 ms to text render when they come from a third-party host. The next/font module fetches them at build time, serves them from your own origin and generates matching fallback metrics, which removes a class of layout shift as a side effect. If you must stay with an external provider, add preconnect and set display to swap, but accept the worse result.

The good threshold for INP is 200 ms at the 75th percentile, and most shops miss it for one reason: the main thread is busy exactly when the first interactions arrive. The classic case is a user tapping a category filter two seconds after load, while a list of sixty products is still hydrating. Server components in the App Router remove a large share of this, simply because they ship no hydration code.

Third-party scripts are usually a bigger offender than your own code. A Tag Manager container with eight tags, a heatmap tool, a chat widget and a reviews script can occupy the main thread for 1.2 seconds in blocks of 150 to 300 ms. Moving chat and reviews to next/script with lazyOnload, and shifting non-critical tags onto a scroll-based trigger, typically buys 80 to 150 ms of field INP. Partytown looks attractive but breaks on scripts that use document.write or synchronous cookie access, so we treat it as an option rather than a default.

Inside the application itself, the biggest win comes from breaking up long tasks. If a filter click runs 40 ms of computation and then re-renders the entire list, separate the immediate visual response from the heavy work by yielding with scheduler.yield or startTransition. The user sees the filter tick within 30 ms and the list arrives 200 ms later, which reads as fast.

CLS on a store almost always has three sources, and all three are a day's work. The first is images with no reserved space, solved by setting an aspect ratio on the container or passing dimensions to next/image. The second is a consent banner injected into document flow rather than layered above it, which drops the whole page by 90 to 140 pixels about 600 ms in.

The third is less obvious: sections that load after hydration, such as product recommendations or a reviews strip. If the component renders nothing until the API responds and then 300 pixels of content, everything below it shifts. A skeleton with exactly the same height as the final content takes fifteen minutes to build and removes the problem entirely.

Test these on a slow connection, because on fast local networking the shifts happen before the first measurement and appear not to exist. In DevTools we throttle the network to Fast 4G and the CPU by 4x, which reasonably approximates the phones generating most mobile traffic.

Optimisation without an enforcement mechanism survives about three months. Then someone adds a 90 kB charting library, someone else drops in another marketing script, and you are back where you started. So every project ends with thresholds in the pipeline: Lighthouse CI with assertions on LCP and CLS, plus a hard limit on first-load JavaScript.

Our default numbers: first-load JavaScript under 170 kB compressed on listing pages, a 120 kB AVIF budget for the hero image, and no task longer than 200 ms in the mobile simulation. Thresholds must fail the pull request rather than print a warning, because warnings get ignored. Once a quarter we review them and tighten where there is headroom.

Core Web Vitals are part of the page experience signals, and the ranking effect is real but weak and never sufficient on its own. A page that does not answer the query will not reach the top three because its LCP improved by 400 ms. Treating these metrics as a ranking lever ends in disappointment and in budget spent where there is nothing to recover.

The conversion argument is far easier to defend. On two projects last year, moving INP from around 380 ms to under 200 ms coincided with a 6 to 9 per cent drop in abandonment at the delivery step, measured with a split test at the deployment level. Those numbers do not transfer directly to another store, but the direction repeats, and the reason is simple: an interface that does not respond to a tap reads as broken.