Next.js Performance: A Practical Core Web Vitals Playbook
How we approach LCP, INP, and CLS on real products—without sacrificing features or shipping speed.
Users notice speed before they notice polish. On marketing sites and SaaS dashboards alike, Core Web Vitals are both a UX signal and an SEO signal—which means performance work is product work, not an optional cleanup pass.
This playbook is what we use on client builds and our own surfaces: prioritize the metrics that matter, fix root causes (not symptoms), and keep budgets visible in CI so regressions do not sneak in after launch.
Start with measurement, not guesswork
Before changing code, validate with field data where possible (Search Console, RUM, or your analytics provider). Lab tools like Lighthouse are great for iteration, but they will not tell you the whole story on slow devices or varying networks.
We snapshot the top landing URLs and the heaviest authenticated routes, then rank issues by impact: what hurts LCP for the most sessions, what drives INP spikes on interactions users actually perform, and whether CLS is coming from late-loaded media, embeds, or ad slots.
LCP: make the hero path boring
Largest Contentful Paint usually comes down to image strategy, font loading, and server response time. For Next.js, use appropriately sized images with modern formats, reserve space to avoid layout shifts, and prefer streaming where it helps TTFB.
If the LCP element is text, font swaps and subsetting matter. If it is an image, preloading can help—but only when you are certain that image is stable across breakpoints and experiments.
INP: trim main-thread work on interaction
Interaction to Next Paint rewards apps that keep clicks and keystrokes responsive. Long tasks, excessive re-renders, and large hydration footprints are common culprits.
We look for event handlers that do too much synchronously, lists that render too many items at once, and third-party scripts blocking input. Splitting work across frames, virtualizing heavy lists, and deferring non-critical JS are the usual fixes—with profiling proof, not vibes.
CLS: lock layout early
Cumulative Layout Shift is often caused by images and embeds without dimensions, dynamic banners, or fonts that reflow text after swap. Fixing CLS is usually cheaper than fixing LCP, and it is worth doing early because it compounds trust during onboarding and checkout.
We bake aspect ratio and min-height into components that wrap media and third-party widgets, and we treat ad slots as first-class layout citizens with reserved space.
Keep performance a habit
The goal is not a one-time Lighthouse trophy. It is a sustainable workflow: budgets in preview deployments, periodic field-data reviews, and a shared understanding that every feature ships with a performance contract.
If you are planning a rebuild or a major feature spike, involve performance thinking in discovery—not the week before launch.
