Next.js Performance Checklist: 15 Fixes Before Launch

Start with a production measurement

Run Lighthouse against a production build, then compare it with field data when the site has real traffic. Development mode, a fast laptop, and an empty cache hide the problems that mobile users experience. Record LCP, INP, CLS, total transferred bytes, JavaScript execution time, and the URL tested.

Measure the landing page, a representative content page, and the heaviest interactive page. A homepage score does not tell you whether a pricing guide, tool, or contact form is usable. Keep the baseline in a small document so every change can be compared with the same test conditions.

Reduce browser work first

Keep content-heavy routes as Server Components unless they genuinely need state, effects, or browser APIs. A client boundary pulls its dependency tree into the browser, so a small interactive widget should not make an entire article client-rendered. Split large widgets and load them only when the user needs them.

Audit third-party scripts with the same suspicion as your own code. Chat widgets, heatmaps, social embeds, A/B testing tools, and ad scripts all compete for the main thread. Remove experiments that are no longer answering a decision, and defer the ones that are not needed for the first interaction.

• Prefer Server Components for static article and marketing content.
• Lazy-load below-the-fold or interaction-only widgets.
• Remove unused analytics and duplicate tag-manager entries.
• Check bundle size after adding every visual library.

Make the main content predictable

Give the largest above-the-fold image explicit dimensions, a stable aspect ratio, a descriptive alt attribute, and an appropriate loading priority. Do not lazy-load the image that is likely to become LCP. Use responsive sources so a phone does not download a desktop asset.

Reserve space for banners, embeds, fonts, and dynamic UI before they load. Layout shift is often caused by a component that has no declared height rather than by a slow network. Skeletons and fixed aspect-ratio wrappers are useful when they reflect the final layout instead of adding decorative movement.

Treat fonts and CSS as product decisions

Use a small, intentional font set and ensure the fallback has similar metrics. Preloading too many weights can compete with the main content; loading too few makes the design fall back unexpectedly. If a page works with the system font during testing, do not make a remote font a single point of failure.

Keep critical styles close to the page and avoid shipping a large global stylesheet for a small route. CSS modules help with boundaries, but the real test is the rendered page: unused styles, oversized shadows, and animated backgrounds can cost more than a few extra declarations.

Check caching, navigation, and accessibility

Static pages should be served from the CDN with long-lived caching for hashed assets. Use framework links for internal navigation so prefetching and accessible focus behaviour work as intended, and make sure clean URLs resolve to the generated HTML files on the host.

Performance that excludes keyboard and reduced-motion users is not a complete optimisation. Test focus order, contrast, labels, heading hierarchy, tap targets, and `prefers-reduced-motion`. A page that is easier to use usually produces better engagement signals than a page that only scores well in a lab.

The launch gate

Before launch, test the production build on a mid-range Android device or throttled profile, with a cold cache and slow 4G. Check the first contentful paint, the largest element, form interaction, route changes, and the page after an error. Re-run after enabling consent, analytics, or ads; those are part of the real page experience.

Do not chase a perfect score at the expense of a useful page. A fast, clear article with working navigation, complete metadata, and a good answer is a better search asset than a stripped-down page that makes visitors search again.