Next.js performance: diagnose the slow part first

Investigate Next.js performance through server work, client JavaScript, rendering boundaries, image delivery and production-build measurements.

A slow Next.js page can be delayed by server work, resource delivery, client JavaScript or a combination of all three. Begin with a production build and a reproducible journey. Development-mode behaviour is useful for debugging but is not a reliable production baseline. Record the route, device, network conditions and whether the visit is cold, cached or a client-side navigation.

Separate waiting from browser work

Inspect the initial response and the data requests required to render the page. Trace slow database queries or external calls rather than assuming that the framework is the bottleneck. Then inspect downloaded JavaScript and main-thread activity. A fast HTML response can still produce a sluggish interaction if a large client component performs expensive work. Conversely, reducing a bundle will not fix a server request blocked on a remote service.

Review rendering and data boundaries

Use the project’s Next.js version and routing model when evaluating caching and rendering. Do not apply a rule copied from another version without checking its behaviour. Keep interactive client boundaries as small as practical and avoid sending data or dependencies to the browser when they are only needed on the server. Review serial request chains and whether independent work can run concurrently. Any cache change needs explicit freshness and invalidation expectations for the affected data.

Inspect assets and third parties

• Check image dimensions, responsive sizes and whether important images are discovered early without loading every image eagerly.
• Inspect fonts and layout stability, including fallback behaviour while resources load.
• Analyse large dependencies and client imports before replacing them or introducing dynamic loading.
• Test analytics, chat and marketing scripts separately to understand their contribution to loading and interaction work.

Validate the real journey after each change

Measure the same production scenario again and verify content, accessibility, authentication and cache correctness. A fast page showing stale prices or another user’s data is not a successful optimisation. Compare cold and warm requests, direct visits and navigation from another page. Document what changed, the observed improvement and the remaining constraint. Keep the result tied to user experience and operating cost rather than an isolated bundle-size target. Finally, add an appropriate regression check for the shared template or critical journey.

• Performance and modernization →
• Core Web Vitals Audit: Turning Measurements into Fixes →
• API Performance Audit: Latency, Database Work and Queues →