Why Is My Next.js App Slow? Common Causes and How to Fix Them

Hook

Your Next.js app takes forever to load. Users are bouncing. Google's PageSpeed score is embarrassingly low. And the worst part? Next.js was supposed to be the fast framework.

I hear this from founders at least twice a month. They invested in Next.js because someone told them it was "built for performance," and now their site loads like it's 2009. The framework itself is not the problem. How it's configured and what you put inside it usually is.

I've been building with Next.js since version 9, and my own site (the one you're reading right now) runs on it. Over 250+ projects and 16 years of engineering, I've tracked down the same handful of performance problems again and again. This guide covers the seven most common reasons your Next.js app feels slow, written so you can understand each one even if you've never written a line of code. You'll know what to ask your developer to fix and, just as important, what to fix first.

---

TL;DR Summary

• Next.js is fast by default, but misconfiguration and bloated dependencies can make it crawl
• The top offenders: too much JavaScript shipped to the browser, unoptimized images, missing or broken caching, and rendering strategy mismatches
• Most fixes take hours, not weeks. A performance audit typically pays for itself in improved conversion rates within 30 days
• Google's Core Web Vitals directly affect your search rankings. Slow pages lose both visitors and organic traffic
• You do not need to rebuild your app. Targeted fixes can cut load times by 40-70%

---

Table of Contents

1. The Real Cost of a Slow Next.js App
2. Problem 1: Shipping Too Much JavaScript
3. Problem 2: Images That Aren't Optimized
4. Problem 3: The Wrong Rendering Strategy
5. Problem 4: Third-Party Scripts Blocking Your Page
6. Problem 5: No Caching (or Broken Caching)
7. Problem 6: Fetching Data on Every Single Request
8. Problem 7: Your Hosting Setup Is the Bottleneck
9. How to Diagnose Your Next.js Performance Issues
10. FAQ
11. What to Do Next

---

The Real Cost of a Slow Next.js App

Before we get into the technical fixes, let's talk about what slow actually costs you.

Google published data showing that when page load time goes from 1 second to 3 seconds, the probability of a user bouncing increases by 32%. At 5 seconds, that number jumps to 90%. For an e-commerce site doing $100,000 per month, a 1-second delay in load time can translate to roughly $7,000 in lost revenue per month, based on industry conversion rate studies.

It goes beyond revenue. Since 2021, Google has used Core Web Vitals (a set of three speed and responsiveness measurements) as a ranking factor. A slow Next.js app doesn't just lose visitors who arrive. It also loses visitors who never find you in search results because Google deprioritized your pages.

I ran into this with my own site. After adding several analytics tools and a CRM tracking script, my Lighthouse score dropped noticeably. That prompted me to audit everything, defer non-critical scripts, and reconfigure how third-party code loads. The result? My pages went back to scoring above 90 on PageSpeed Insights. The lesson was clear: even a well-built Next.js app can slow down incrementally if you're not paying attention.

If you want a broader look at how speed affects your bottom line, I wrote a detailed breakdown in Website Speed Optimization: Why Every Second Costs You Money.

---

Problem 1: Shipping Too Much JavaScript

This is the single most common reason Next.js apps feel slow. Your developer installs libraries for a date picker, charts, animations, form validation. Each one ships JavaScript to the user's browser. The browser downloads, parses, and executes all of it before the page becomes interactive.

Think of it like ordering a meal and having the kitchen send out every pot, pan, and ingredient they used to make it. You just wanted the plate.

How to spot it: Run your site through PageSpeed Insights. Warnings about "Reduce unused JavaScript" or Total Blocking Time above 200 milliseconds point here.

What to do about it:

• Audit your dependencies. Ask your developer to run npx @next/bundle-analyzer. I've seen a single charting library add 400KB for a page displaying one bar chart.
• Replace heavy libraries with lighter alternatives. Swapping Moment.js (300KB) with date-fns or the browser's built-in date formatting cuts that to under 10KB.
• Use dynamic imports. That date picker on your contact form shouldn't load on your homepage. Dynamic imports ("code splitting") tell the browser: only download this when the user navigates to the page that needs it.

A Next.js app I optimized last year had 1.8MB of JavaScript on initial load. After cleanup and code splitting, that dropped to 380KB. LCP (time until main content appears) went from 4.2 seconds to 1.1 seconds.

---

Problem 2: Images That Aren't Optimized

Images typically account for 40-60% of a page's total weight. Next.js has a built-in <Image> component that converts images to modern formats like WebP, resizes for different screens, and lazy-loads images below the fold. The problem: many developers use standard HTML <img> tags instead, so the browser downloads a 3MB hero image at full resolution even on a phone.

What to do about it:

• Use the Next.js Image component everywhere. Single highest-return fix for most sites. Can reduce image payload by 60-80%.
• Set explicit width and height. This prevents Cumulative Layout Shift (CLS), where content jumps around as images load. Google penalizes this.
• Use priority loading for above-the-fold images. Your hero image should load immediately. The Image component has a priority prop for this.

I compared how frameworks handle built-in features like image optimization in Best Web Frameworks 2026.

---

Problem 3: The Wrong Rendering Strategy

Next.js gives you multiple ways to build a page. Choosing the wrong one is a common performance mistake. The three main options in plain terms:

1. Static Generation (SSG): The page is built once at deploy time. Like printing a brochure. Fastest option.
2. Server-Side Rendering (SSR): Built fresh on the server every time someone visits. Like cooking to order. Slower, but always shows the latest data.
3. Client-Side Rendering (CSR): The browser gets a mostly empty page and JavaScript builds the content on the user's device. Slowest perceived experience because users stare at a loading screen.

The mistake I see most often: pages that could be static (About, pricing, blog posts) are server-rendered on every request, adding 200-500 milliseconds of latency for zero benefit.

What to do about it:

• Default to static. If a page's content doesn't change based on who's viewing it, it should be statically generated.
• Use Incremental Static Regeneration (ISR) for semi-dynamic content. ISR lets you set a revalidation period (say, every 60 seconds). The page stays static but refreshes in the background.
• Reserve SSR for truly dynamic pages. User dashboards, personalized content, real-time data.

I've seen apps where every page was SSR. Switching marketing pages to static generation cut their Time to First Byte (TTFB) from 800ms to under 50ms. Same pages. Only the timing of HTML generation changed.

---

Problem 4: Third-Party Scripts Blocking Your Page

Analytics. Chat widgets. CRM tracking. Heatmaps. Ad pixels. Each one adds a script that competes with your page content for bandwidth and processing time.

I deal with this on my own site. I run Google Analytics, Vercel Analytics, Microsoft Clarity, Plausible, Ahrefs, and HubSpot. The only reason my site still loads fast: every one of those scripts loads after the page content, using specific loading strategies.

What to do about it:

• Use the Next.js Script component with the right strategy. afterInteractive loads scripts after the page becomes usable; lazyOnload loads during idle time. Most tracking scripts should use one of these two.
• Audit every script. I've audited sites where a chat widget loaded before the page content, adding 1.5 seconds to every page load.
• Remove scripts you don't use. That A/B testing tool from six months ago? That social login you never launched? Still loading on every visit.

---

Problem 5: No Caching (or Broken Caching)

Caching means saving a copy of your page so the next visitor gets the saved copy instead of the server rebuilding it from scratch. When caching works, repeat visitors get near-instant responses. When it's broken, every visit triggers a full page build.

Next.js has three caching layers: the visitor's browser stores files locally, a CDN (Content Delivery Network) stores page copies on servers worldwide, and Next.js itself can cache API responses and database queries.

What to do about it:

• Check your cache headers. A common mistake: setting no-cache on pages that should be cached, forcing every visitor to wait for a fresh build.
• Review data caching config. In the App Router, fetch requests are cached by default. But if your developer added cache: 'no-store' to API calls that don't need real-time data, every page load hits the API fresh. I've seen this add 1-3 seconds to page loads.
• Verify CDN behavior. If you deploy on Vercel, static pages should be served from their edge network. Misconfigured routing or middleware can bypass this entirely.

---

Problem 6: Fetching Data on Every Single Request

A common pattern in Next.js apps: the page makes 5-10 API calls to assemble content. Navigation, hero section, featured products, testimonials, footer. Each call takes 100-300 milliseconds. If they run in sequence, that's seconds of wait time before the page appears.

What to do about it:

• Parallelize data fetching. Five simultaneous requests take as long as the slowest single one, not the sum of all five. This alone can cut data fetching from 1.5 seconds to 300 milliseconds.
• Move static data to the build step. If the data doesn't change between visitors (services, team bios, pricing), fetch it once at deploy time and bake it into the page. My own site works this way. All service descriptions, case studies, and pricing live in a constants file built into the pages. Zero API calls at runtime.
• Use React Server Components. Next.js 14+ supports Server Components that fetch data on the server and send only rendered HTML to the browser. The user's device never makes those API calls or even knows they happened.

---

Problem 7: Your Hosting Setup Is the Bottleneck

Sometimes the app is fine but the infrastructure underneath is the problem. I've seen Next.js apps on $5/month shared hosting struggling with 200 concurrent visitors. Next.js with SSR needs more server resources than static HTML. A cheap shared server with 512MB of RAM and a single CPU core will buckle under real traffic.

What to do about it:

• Use a platform built for Next.js. Vercel (built by the creators of Next.js), Netlify, AWS Amplify, or Cloudflare Pages handle edge caching, serverless functions, and scaling automatically.
• Right-size your server. Self-hosting? Budget at least 1GB of RAM for a basic Next.js app, more for heavy SSR. Monitor CPU and memory during traffic spikes.
• Check geographic distance. If your server is in Virginia and your customers are in Europe, every request crosses the Atlantic. A CDN or edge deployment fixes this.

For custom web applications, hosting strategy should be part of the architecture conversation from day one, not an afterthought when things get slow.

---

How to Diagnose Your Next.js Performance Issues

You don't need to be technical to start. Go to PageSpeed Insights and enter your URL. Focus on three Core Web Vitals numbers:

• LCP (Largest Contentful Paint): Time until main content appears. Target: under 2.5 seconds.
• INP (Interaction to Next Paint): Response time when a user clicks or taps. Target: under 200 milliseconds.
• CLS (Cumulative Layout Shift): How much the layout jumps while loading. Target: under 0.1.

The report also shows a "filmstrip" of your page loading. A blank white screen for the first 2-3 seconds points to a JavaScript or rendering problem. Images loading late and pushing content around means image optimization is needed.

Share these results with your developer. The PageSpeed report gives them a ranked list of what to fix. A competent Next.js developer can usually resolve the top issues in 1-2 days.

---

FAQ

Is Next.js actually fast, or is that just marketing?

Next.js is genuinely fast when configured correctly. It supports static generation, server-side rendering, edge functions, and automatic image optimization out of the box. The framework gives you the tools for high performance, but it won't fix poor architecture or bloated dependencies on its own. Think of it as a sports car that still needs a competent driver.

How do I know if my Next.js app has a performance problem?

Run your site through Google PageSpeed Insights. If your Performance score is below 70 on mobile, or your Largest Contentful Paint exceeds 2.5 seconds, you have measurable performance issues. Also watch your Google Search Console for Core Web Vitals warnings, as Google flags pages that fail their thresholds.

Can I fix Next.js performance without rebuilding the whole app?

Yes, and that's the approach I recommend in most cases. Targeted fixes like enabling the Image component, adding code splitting, correcting your rendering strategy, and cleaning up third-party scripts can improve load times by 40-70% without touching your core business logic. A full rebuild is rarely necessary for performance alone.

How much does it cost to optimize a slow Next.js app?

For a typical Next.js application, a focused performance audit and implementation of fixes ranges from $2,000 to $8,000 depending on the size of the app and the severity of the issues. The ROI is usually measurable within 30 days through improved conversion rates and search rankings. Compare that to the ongoing cost of lost visitors and lower rankings.

Should I switch from Next.js to another framework for better performance?

In almost every case, no. Switching frameworks is expensive (often $20,000-$50,000 or more for a full rewrite) and the new framework will have its own performance pitfalls. The issues making your Next.js app slow are likely configuration problems, not framework limitations. Fix the configuration first. If you're evaluating frameworks for a new project, I compared the top options in Best Web Frameworks 2026.

---

What to Do Next

If your Next.js app is slow, you now know what to look for. Start with the free PageSpeed Insights test to identify which of these seven problems apply to your situation. Then prioritize: JavaScript bloat and image optimization typically deliver the biggest improvements with the least effort.

If you've been dealing with performance issues and want a professional assessment, that's something I do regularly. I'll audit your Next.js application, identify the specific bottlenecks, and tell you exactly what to fix and in what order, with a clear cost estimate before any work begins. No surprises.

Get in touch here and tell me about your app. I'll let you know if I can help and what it would take.