How to Optimize Core Web Vitals in Next.js App Router

Core Web Vitals measure real user experience

Core Web Vitals focus on loading speed, responsiveness and visual stability. The current metrics are Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS).

• LCP should be 2.5 seconds or less

• INP should be 200 milliseconds or less

• CLS should be 0.1 or less

Google evaluates these thresholds at the 75th percentile of page loads, split by mobile and desktop. That means an occasional fast test is not enough. Most real visitors need a good experience.

Use Google's Core Web Vitals documentation for the current definitions and thresholds.

Start with field data, then use lab tools to diagnose

PageSpeed Insights and Lighthouse are useful, but they answer different questions. Field data shows what real users experienced over time. Lab data runs a controlled test and helps you reproduce individual problems.

Before changing code, record:

• Which page groups fail in field data

• Whether the problem affects mobile, desktop or both

• Which metric is failing

• Whether results differ by geography, traffic source or device class

• Which templates, scripts and releases are shared by the affected pages

Measure by page type instead of testing only the homepage. Product pages, campaign landing pages, articles and logged-in screens often have different bottlenecks.

Improve Largest Contentful Paint

LCP measures when the main visible content finishes rendering. In a Next.js application, a slow LCP usually comes from server response time, render-blocking resources, late discovery of the main asset or too much work before the hero can render.

Make the main content discoverable early

• Render the primary heading and hero content in the initial server response

• Use next/image with correct dimensions and responsive sizes

• Prioritize only the true LCP image instead of preloading several competing assets

• Avoid loading the hero image through client-side effects

• Use a suitable image format and do not send a desktop-sized asset to a small screen

Reduce time spent waiting for the page

• Cache data and rendered output where the content model allows it

• Move slow, nonessential data behind the initial response

• Stream secondary sections instead of blocking the entire route

• Keep redirects and middleware work to a minimum

• Measure origin and CDN response time separately

React Server Components can reduce the amount of JavaScript sent to the browser, but only when client boundaries are kept intentional. Turning a large layout into a Client Component can pull much more code into the browser than expected.

Improve Interaction to Next Paint

INP measures how quickly the page responds after a user interacts. A page can appear loaded and still feel slow because the main thread is processing JavaScript, third-party tags or a large React update.

• Reduce unnecessary Client Components and browser-side dependencies

• Split long tasks so the browser can respond between units of work

• Keep state close to the component that needs it

• Virtualize or paginate genuinely large lists

• Delay nonessential widgets until they are requested or visible

• Inspect expensive event handlers and avoid doing unrelated work in them

• Test interactions such as opening navigation, typing, filtering and submitting forms

Do not optimize INP by removing useful feedback. Immediate visual acknowledgement, followed by asynchronous work, often feels better than making the user wait for a complete operation.

Prevent Cumulative Layout Shift

CLS increases when visible content moves unexpectedly. Most fixes are straightforward once the shifting element is identified.

• Give images and video explicit dimensions or a stable aspect ratio

• Reserve space for banners, embeds and consent interfaces

• Do not insert content above what the visitor is already reading

• Use next/font or self-hosted fonts with sensible fallbacks

• Keep skeletons and final components the same approximate size

• Animate with transforms rather than layout-changing properties

Control fonts and third-party scripts

Marketing sites often lose performance through accumulated scripts rather than application code. Audit every analytics tag, chat tool, personalization widget and advertising pixel. Load each script only on the routes and at the time it is needed.

Next.js recommends including third-party scripts only in the pages or layouts that use them. The framework's Script component lets you control loading strategy, while built-in font handling reduces external requests and layout movement.

A tag manager is not a performance exemption. Custom HTML tags and duplicated vendor scripts still execute in the browser and can block the main thread.

Use the App Router features deliberately

• Keep static content in Server Components

• Place client boundaries around actual interactive islands

• Use next/image for responsive image delivery and layout stability

• Use next/font for controlled font loading

• Use next/script for explicit third-party loading strategies

• Measure route changes and virtual page views in analytics

• Review bundle composition after adding client libraries

The Next.js production checklist is a useful baseline, but real field data should determine the order of work.

Set up continuous monitoring

Performance work regresses when it is treated as a one-off launch task. Track field data by page group, run repeatable lab tests in continuous delivery and assign budgets for JavaScript, images and third-party scripts.

• Record the baseline before each project

• Set budgets for important templates

• Watch mobile results separately

• Investigate changes after releases and marketing campaigns

• Keep a named owner for each third-party script

• Remove tags and libraries that no longer serve a purpose

When an audit is more efficient than guesswork

If several metrics fail, begin with a short performance audit. It should connect user data to page templates, identify the elements responsible, rank fixes by impact and distinguish quick wins from architectural work.

Makers' Den provides web performance and growth engineering for teams that need the diagnosis and the implementation, including Core Web Vitals, Next.js performance, analytics and third-party script cleanup. Our Perk performance rebuild case study shows how a broader platform change can be approached when incremental fixes are no longer enough.