What common performance issues have you faced in Next.js apps?

[LakshanHewagama]

Summary

Hi everyone, I’m doing my final year research on Next.js performance optimization and would love input from real developers.
From your experience, what common coding or architectural issues make a Next.js app slow?
Examples:

• too many use client components
• hydration issues
• large JS bundles
• client-side data fetching
• image optimization problems
• third-party scripts
• App Router performance issues

Would really appreciate hearing real problems you’ve faced and, if possible, how you fixed them. Thanks! 🙌

Additional information

No response

Example

No response

[lizuju]

The repeat offenders I see in real Next apps are usually less about one magic setting and more about accidentally moving work to the wrong side of the server/client boundary.

The biggest ones:

1. A high-level "use client" wrapper

Putting "use client" in a layout, app shell, or provider that imports a lot of UI tends to drag a large part of the tree into the client bundle. The fix is usually to keep the layout/server data work as Server Components and push interactivity into small leaf components.

2. Sequential data fetching in Server Components

This is easy to miss:

const user = await getUser()
const posts = await getPosts(user.id)
const stats = await getStats(user.id)

If posts and stats do not depend on each other, fetch them in parallel. Waterfalls in RSC are still waterfalls.

3. Making routes dynamic by accident

Calling cookies(), headers(), or auth helpers too high in the tree can make more of the route dynamic than intended. I usually try to move that work as close as possible to the component that actually needs it, instead of doing it in a root layout.

4. Client-side fetching for data that could be rendered on the server

A lot of pages ship a loading state, hydrate, then fetch data in useEffect. That adds a round trip and often hurts LCP. If the data is needed for the initial view, render it in a Server Component or pass it down as initial data.

5. Third-party scripts

Analytics, chat widgets, tag managers, A/B tools, and session replay can dominate main-thread time. Use next/script deliberately, avoid beforeInteractive unless it is genuinely required, and measure the cost instead of assuming the app code is the problem.

6. Middleware doing too much

Middleware runs more often than people expect, including for navigations and prefetches depending on matchers. Keep it cheap, and exclude static/internal paths explicitly. Doing database work there is usually a red flag.

7. Images without correct sizing

Unoptimized hero images, missing sizes, or using images far larger than their rendered dimensions still show up constantly. This is one of the easiest LCP wins.

For debugging, I would not start with guesses. I usually check, in this order:

• Web Vitals / real browser trace for LCP, INP, CLS
• @next/bundle-analyzer for client bundle surprises
• Network waterfall for RSC/API/data fetch sequencing
• whether the route is static, dynamic, or accidentally dynamic
• Chrome Performance panel for third-party script/main-thread cost

The pattern is usually visible once you separate: server time, network waterfall, client JS size, and browser main-thread work.

[reziferdiansyah]

`Some of the most common performance issues I've faced in Next.js applications are:

1. Large JavaScript bundles

   • Importing entire libraries instead of specific modules.
   • Too many client components in the App Router.

2. Unoptimized images

   • Using large images without optimization.
   • Not taking advantage of the built-in next/image component.

3. Excessive client-side rendering

   • Fetching data on the client when it could be rendered on the server.
   • Overusing useEffect for data fetching.

4. Slow API responses

   • Backend endpoints becoming bottlenecks.
   • Missing caching strategies for frequently requested data.

5. Hydration issues

   • Mismatches between server-rendered and client-rendered content.
   • Accessing browser-only APIs during SSR.

6. Unnecessary re-renders

   • Components re-rendering because of unstable props or state management patterns.

In recent projects, moving more logic to Server Components, optimizing images, code splitting, and implementing caching strategies significantly improved performance and Core Web Vitals scores.`

[wanhei1]

Great question! Here are some common performance issues I've encountered in Next.js apps:

1. Excessive Client Components (use client)

Overusing 'use client' pushes unnecessary JavaScript to the browser. Each client component adds to the bundle and requires hydration. Rule of thumb: keep components as Server Components by default, only use 'use client' when you need interactivity (event handlers, browser APIs, hooks).

2. Unoptimized Data Fetching

• Fetching in client components instead of Server Components causes extra waterfalls
• Not using React.cache() for deduplication within a single render
• Missing cache: 'force-cache' or revalidate on fetch calls, leading to redundant requests

3. Large JavaScript Bundles

• Importing entire libraries (e.g., import _ from 'lodash') instead of tree-shakeable imports
• Not using next/dynamic for heavy components below the fold
• Third-party scripts loaded without strategy="lazyOnload"

4. Image Optimization Issues

• Not using next/image with proper sizes attribute
• Missing priority on LCP images
• Serving oversized images for mobile viewports

5. Hydration Mismatches

Rendering different content on server vs client (e.g., using Date.now(), localStorage, or window without useEffect) forces React to re-render the entire tree.

Quick Diagnostic Tips

# Analyze bundle size
ANALYZE=true next build

# Check for unused dependencies
npx depcheck

# Profile React renders
# Add ?react_perf to URL in development

Hope this helps with your research! 🚀

[webperfdev]

Great thread! One angle I have not seen mentioned yet is what the data actually shows when you audit real Next.js sites in production.

I have been running automated audits on Next.js sites for a side project. Across the ones I have checked, the most common measurable issues are:

Missing or incorrect sizes on next/image — This is the #1 LCP culprit. People use next/image but omit the sizes attribute, causing the browser to download desktop-sized images on mobile. Adding sizes can improve LCP by 15-20 points.

Render-blocking third-party scripts labeled beforeInteractive — Even with next/script, analytics and chatbots are often set to beforeInteractive when they should be afterInteractive or lazyOnload. Fixing this can shave 300-800ms off LCP.

Server Components returning waterfall fetches — The RSC payload can hide a sequential chain like fetch user then fetch posts then fetch comments. Using Promise.all for independent fetches even in server components makes a big difference.

Unused JavaScript in client bundles — Full icon libraries imported when only 3-4 icons are used. A quick check with bundle-analyzer reveals 50-200KB of unnecessary client JS.

For your research, I would suggest adding actual Lighthouse/CWV scores from a sample of production Next.js sites. Knowing how many sites have each problem tells you where to focus. Hope this helps!