Why Your Next.js Site Is Slow & How to Fix It

Next.js was built to solve performance problems that plagued early React apps: blank white screens, oversized client bundles, weak SEO from purely client-side rendering. Server-side rendering, static generation, automatic code splitting, and the App Router's streaming model all exist specifically to make pages load faster.

None of that happens automatically once a project scales past a demo. Add enough client components, third-party scripts, and unoptimized images, and a Next.js site regresses right back into the problems it was designed to prevent. The framework provides the capability; the implementation decides the outcome.

Before fixing anything, confirm what's actually broken. "Feels slow" and "measurably slow" are two different problems, and they call for different tools.

Google measures site speed and user experience through three Core Web Vitals: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). LCP measures how long the largest visible element — usually a hero image or headline — takes to render. INP measures how responsive the page feels across every click, tap, and keystroke during the visit, not just the first one. CLS measures how much content unexpectedly shifts while the page loads.

Google grades these thresholds at the 75th percentile of real visitor sessions over a rolling 28-day window, using Chrome UX Report (CrUX) field data — not a single test run in a dev environment. A page can look fast in Lighthouse and still fail in the real world if a meaningful share of visitors on older phones or slower connections has a worse experience.

The Tools Worth Using:

• Google PageSpeed Insights: Combines field data (CrUX) with lab data (Lighthouse) for both mobile and desktop.
• Search Console's Core Web Vitals report: Shows real-world pass/fail status by URL group.
• Chrome DevTools Performance panel: For pinpointing specific bottlenecks during development.
• WebPageTest: Deeper waterfall analysis, useful for diagnosing TTFB and render-blocking resources.
• Vercel Analytics or RUM tools: For continuous, real-user monitoring instead of one-off snapshots.

Lab data tells you what's wrong in a controlled test. Field data tells you what your actual visitors experience. Teams that only check Lighthouse routinely miss the mobile and low-bandwidth users failing in the real world — use both.

Once the diagnosis confirms a real problem, the fix depends on which of six root causes is driving it. Most slow Next.js sites have more than one at the same time:

1. The Wrong Rendering Strategy for the Content

Next.js supports several rendering strategies, and choosing the wrong one for a given page is one of the most common — and most expensive — mistakes we see.

A dashboard rendered with SSR on every request will always be slower than it needs to be if the underlying data only changes once an hour. Switch that dashboard to ISR, and TTFB often drops sharply without losing the content freshness that actually matters to users. Read our headless CMS architecture guide for deeper rendering strategy patterns.

2. Client-Side Hydration Overhead

Hydration is the process where React attaches interactivity to the static HTML the server already sent. Until hydration finishes, buttons look clickable but aren't. On JavaScript-heavy pages with dozens of client components, that gap becomes noticeable, and it disproportionately hurts INP.

React Server Components, introduced with the App Router, reduce this problem by keeping non-interactive parts of a page on the server entirely. A page stuffed with client components that don't actually need interactivity is paying a hydration tax for nothing.

3. Oversized JavaScript Bundles

Every unnecessary import, unused library, and duplicated dependency adds weight the browser has to download, parse, and execute before the page becomes usable. Common culprits: importing an entire icon library for three icons, bundling a heavy date library when native Intl formatting would do, and shipping admin-only code to every visitor.

Code splitting and dynamic imports (`next/dynamic`) let a heavy component — a modal, a chart, a rich text editor — load only when it's actually needed, rather than on initial page load. `@next/bundle-analyzer` makes it easy to see exactly what's bloating the bundle before deciding what to cut.

4. Unoptimized Images and Fonts

Images are still the single largest asset on most web pages, and Next.js ships a purpose-built `next/image` component specifically to solve this: automatic resizing, lazy loading, and modern format conversion to WebP or AVIF. The catch is that it only helps when it's used correctly. Missing `priority` on above-the-fold hero images, missing explicit `width` and `height` causing layout shift, and images served from an unoptimized external source all defeat the tool's purpose. For deep-dive image techniques, read our guide on 7 Practical Techniques to Improve LCP in Next.js.

Fonts cause a related problem. Without a defined loading strategy, custom fonts create a flash of unstyled or invisible text as they load, hurting both CLS and perceived speed. `next/font` self-hosts and preloads font files automatically, removing the render-blocking request to a third-party font provider.

5. Slow Time to First Byte and Missing Caching

TTFB measures how long the server takes to respond before the browser can even start rendering. A slow TTFB compounds every metric downstream — a five-second, failing LCP is often a symptom of a two-second server response problem, not a front-end one.

Common causes include uncached SSR requests, cold-start serverless functions, missing CDN edge caching, and database queries that run synchronously on every page load. Proper `Cache-Control` headers, CDN edge caching through a platform like Vercel's Edge Network or Cloudflare, and moving expensive work off the request path with ISR or background jobs address most of this.

6. Third-Party Scripts and Unoptimized Database Queries

Analytics pixels, chat widgets, ad tags, and marketing tools each add their own JavaScript, and each one competes with the site's own code for the main thread. A page can have a perfectly optimized codebase and still fail INP because one unoptimized third-party script blocks interaction for half a second at a time.

On the backend, N+1 query problems and missing database indexes slow down SSR and API routes even when the front end is well-built. If a page queries the database ten times to render one list, no amount of front-end optimization fixes that — the fix has to happen at the ORM or query level.

Migrating to the App Router alone doesn't guarantee a faster site, even though that assumption is common. The App Router's real performance advantage — React Server Components, streaming, and more granular caching — only shows up when it's used deliberately. A project that migrates routers but marks every component "use client" out of habit keeps the exact hydration overhead it had before, just wrapped in newer syntax.

The router matters less than the architecture decisions made inside it.

At Belk Digital, we follow a systematic 7-step remediation framework to get slow sites back under control:

1. Baseline the current state: Run PageSpeed Insights and Search Console's Core Web Vitals report to establish real, field-data numbers before touching any code.
2. Identify the dominant bottleneck: TTFB, bundle size, hydration, images, or some combination. Fixing the wrong thing first wastes an entire sprint.
3. Fix server response time first: Rendering strategy corrections and caching typically produce the largest single improvement, since everything downstream depends on it.
4. Optimize images and fonts: Usually the fastest wins with the least risk of breaking anything else on the page.
5. Reduce and split the JavaScript bundle: Audit dependencies, convert unnecessary client components to server components, and add dynamic imports for heavy, non-critical UI.
6. Audit third-party scripts: Defer, lazy-load, or remove scripts that aren't earning the weight they add to the page.
7. Re-test and set up continuous monitoring: A one-time fix degrades as new features ship; RUM catches regressions before users start reporting them.

Teams with in-house engineering capacity can usually handle image optimization, font loading, and basic bundle trimming without outside help — these are well-documented, relatively low-risk fixes. Rendering strategy changes, App Router migrations, and database query optimization carry more risk, since they touch architecture rather than isolated components, and a wrong move can introduce new bugs while chasing speed gains.

If a site has been slow for months despite internal attempts to fix it, or the fix requires re-architecting how data flows through the app, an outside audit is usually the faster and cheaper path. For pricing and vetting guidance on making that call, see our guide on choosing the right digital partner.

Site speed doesn't stay contained in the DevTools tab. Core Web Vitals are a confirmed Google ranking signal, and slow, unstable pages tend to see higher bounce rates and lower engagement than pages that pass all three metrics comfortably. Google has documented individual case studies of retailers improving Core Web Vitals scores alongside measurable gains in ad revenue, session duration, and organic traffic — though results vary by site and shouldn't be treated as a guaranteed formula.

The deeper point is that performance work compounds with the SEO, UX, and conversion work covered in our piece on how website performance affects revenue. Treating speed as a one-time technical project, instead of an ongoing discipline, is the most common reason a fixed site regresses six months later.