Improve Core Web Vitals by identifying the request, interaction, or layout change responsible for a poor experience. Next.js has useful rendering and image tools, but they do not remove the need to measure the deployed page. Start with real visitor data where available, reproduce the problem in a controlled test, and verify the specific change you make.
Measure the three different problems
Core Web Vitals cover loading, responsiveness, and visual stability. Their good-experience thresholds are shown below, using the 75th percentile of visits and reviewing mobile and desktop separately. Thresholds checked against web.dev in October 2026.
| Metric | What it describes | Good threshold |
|---|---|---|
| Largest Contentful Paint, LCP | When the largest eligible visible content appears | 2.5 seconds or less |
| Interaction to Next Paint, INP | Responsiveness across qualifying interactions | 200 milliseconds or less |
| Cumulative Layout Shift, CLS | Unexpected movement of visible content | 0.1 or less |
These measurements answer different questions. A page can display its hero promptly and still respond slowly to a filter click. It can respond quickly while shifting the enquiry button when a late embed loads.
Use the metrics to identify work rather than treating an aggregate score as the objective. Record the affected template, device context, and observed behavior. A single score does not tell a developer what to fix.
Distinguish field evidence from a lab run
Field data describes actual visits across varying devices and conditions. A lab test controls a scenario so you can reproduce and inspect it. Both are useful, but they should not be expected to match perfectly.
Begin with the affected page group in your available field reports. Then reproduce a representative visit in browser performance tools. For an interaction issue, include the interaction in the recording; a load-only run cannot tell you how a search control behaves after a minute of use.
If there is insufficient public field data, say so. Use repeatable lab checks and, where appropriate, your own real-user instrumentation while traffic accumulates. Do not describe one local run as proof of the experience of all visitors.
Save the before measurement with its conditions. Note the build, URL, viewport, connection settings, and user action. This makes later comparisons useful rather than relying on screenshots taken under unknown conditions.
Diagnose LCP along the delivery path
Identify the actual LCP element first. It might be an image, but it can also be a text block. Optimizing an image that is not responsible for the metric can consume time without addressing the delay.
For an image-led page, inspect when the browser discovers the resource and when it begins downloading. Is the image hidden behind a client-side request? Does a stylesheet have to arrive before the browser can discover a background image? Is the downloaded file much larger than its displayed size?
Next.js image tooling can resize images and serve suitable formats. It still needs an accurate layout and source strategy. Review the generated image request at several viewport widths rather than assuming the component name proves the right asset was delivered.
Do not lazy-load the image that needs to appear immediately as the main visible content. Check the current image API when choosing loading and preload behavior, and avoid giving every image the same urgency.
If server delivery dominates the delay, investigate upstream requests and rendering dependencies. A smaller image will not fix a long wait before the HTML starts arriving. The rendering guide helps separate freshness needs from avoidable request-time work.
Diagnose INP with a real interaction
Choose a reported slow action: opening the mobile menu, typing into search, changing a filter, or submitting a form. Record it while the page contains realistic content. An empty demo list may conceal the cost of the actual result set.
Inspect what occupies the main thread before the event handler starts, during the handler, and before the next visible update. The delay might come from unrelated script work, expensive filtering, broad component updates, or layout calculation.
Use the trace to choose a change. Reduce unnecessary computation, narrow the component state that changes, or move suitable heavy work away from the immediate interaction. Show timely feedback while longer work continues, but avoid treating a spinner as proof that the underlying task is efficient.
Review third-party scripts as part of the page. A tracking tag, chat widget, or embedded scheduler can run work at the moment someone tries to interact. Test with and without a suspected script to establish causality before removing useful product functionality.
Diagnose CLS beyond the first screen
Reserve space for images, embeds, and components whose content arrives later. A correctly sized image is only one source of stability. Consent notices, validation messages, promotional banners, and changing font metrics can also move surrounding content.
Record the page while scrolling and using it. A load-only test may miss movement caused by an expandable panel, a late widget, or a result list that changes height. Match the reproduction to the visitor journey that reports the problem.
Look at which elements moved and what changed immediately before them. The shifted heading may be a victim of an inserted banner above it. Fixing its margin will not address the source of the movement.
Design loading states with the final layout in mind. A tiny placeholder that becomes a large card can create a jump even when all network requests succeed. Stable dimensions should be part of the component's design contract.
Prioritize fixes by affected journeys
Group findings by shared template and dependency. One article-image fix may help many articles; an unusual campaign widget may affect only one route. Consider the importance of the affected journey alongside the number of pages.
For each change, record the suspected cause, evidence, proposed fix, and result. Change one cause at a time where practical. When several changes ship together, be honest about which improvement you can attribute to which change.
Recheck reading, keyboard use, and the primary conversion action after optimization. The semantic HTML guide explains why preserving native controls and clear structure matters during frontend changes. Include the performance results in your release checklist, with any remaining limitations stated plainly.