Next.js performance in production: fix the 20% users feel

A Lighthouse score on a fast laptop is a lab result. Production performance is a field result from a mid-range Android phone on a crowded network, with your analytics, chat widget, and cookie banner competing for the main thread.

Next.js gives you the tools to do well. It also makes it easy to wrap the whole app in a client provider and call it architecture. The difference shows up in the field.

Measure the right number

• Core Web Vitals at the 75th percentile, mobile, per route group.
• LCP: largest contentful paint.
• INP: interaction to next paint.
• CLS: cumulative layout shift.
• Real-user data from CrUX or your own useReportWebVitals stream.

Set a budget before you optimize: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1. If you’re far off, fix the biggest contributor, not every item on a checklist. A page can score 95 in the lab and still feel slow on a train.

The usual suspects

• A hero image that isn’t prioritised or is served at the wrong size.
• A client component at the root that pulls the whole tree into the browser.
• A 3D scene or animation library on the critical path.
• Third-party scripts loading before the copy.
• Custom fonts without a swap strategy.
• A data-fetching waterfall that delays the first useful paint.

Fix LCP first

Find the LCP element in DevTools. If it’s the hero image, make it priority, give it accurate dimensions, and provide a sizes value that matches the layout. A priority image inside a client component that waits for a context provider is still late.

<Image
  src="/hero.webp"
  alt="Team reviewing a product dashboard"
  width={1600}
  height={900}
  priority
  sizes="(max-width: 768px) 100vw, 60vw"
/>

• Don’t lazy-load the hero.
• Don’t animate the hero from opacity 0; it delays the visual paint.
• Use AVIF/WebP through the image pipeline and set a sensible cache TTL.
• Preload only what the first viewport needs.
• Test the actual mobile viewport, not a resized desktop window.

Stop shipping the whole client

Every use client boundary is a place where React has to ship, parse, and execute code. Keep formatting, data shaping, and static content on the server. Put state where it’s needed, not at the root.

const SplineScene = dynamic(
  () => import("@/components/spline-scene"),
  {
    ssr: false,
    loading: () => <div className="h-[420px]" aria-hidden />,
  }
);

Heavy visual libraries are fine when they’re behind a user action or below the fold. They’re expensive when they block the hero. The same rule applies to map libraries, charting packages, and rich text editors.

Streaming beats a spinner

Server Components let you send the shell early and stream the slow parts. Use Suspense around product recommendations, reviews, or dashboard widgets. Don’t suspend the hero copy for a personalization call.

• Render the static shell immediately.
• Stream below-the-fold data inside Suspense.
• Show a stable skeleton with reserved space.
• Avoid a global loading screen that hides everything.

Caching is a product decision

Static pages are cheap. Personalized pages need a clear cache key. Decide what can be stale for five minutes, what must be real-time, and who is allowed to see a cached response.

• Marketing pages: static or long revalidation.
• Catalogue pages: short revalidation plus tag-based invalidation.
• User dashboards: no shared cache.
• CMS content: invalidate by tag after publish.
• API responses: explicit cache headers and a key that includes tenant or user scope.

Third-party scripts are a tax

Every tag manager, chat widget, heatmap, A/B tool, and review widget adds network and main-thread work. Load them after interaction or consent, self-host where possible, and remove what nobody uses.

• Audit every script quarterly and name an owner.
• Load chat and feedback widgets on interaction, not on page load.
• Delay marketing tags until consent or idle time.
• Self-host fonts and critical scripts where licences allow.
• Check what the tag manager is injecting after a “small” update.

A two-week sprint

What good looks like

Not a 100 Lighthouse score. A fast first screen, a page that responds when tapped, and no layout jump when the cookie banner appears. The rest is decoration.

The most useful question is not “is this fast?”. It’s “which part would our users notice if we fixed it tomorrow?”. Usually it’s one image, one script, and one component.