Forem: Atena / Full stack developer

Why Next.js Navigation Doesn’t Work as Expected

Atena / Full stack developer — Thu, 12 Feb 2026 21:44:01 +0000

We ran into an issue where clicking a menu item sometimes did not navigate to the expected page.

The URL in the address bar would change correctly, but the content on the screen would not update. If we kept clicking the menu, navigation would occasionally work.The issue did not appear in local development, but only in the production environment.

It took some time to figure out the cause and solution, I would like to share what we learned.

Reason

Next.js Sends an RSC Request When a `<Link>` Is Clicked

In the App Router, clicking a <Link> component triggers a client-side navigation instead of a full page reload. To render the next page, Next.js sends an internal request related to React Server Components (RSC) to fetch the server-rendered data required for the transition.

It allows the page to update without reloading the entire document.

What We Found in the Network Tab

While inspecting the Network tab during navigation, we noticed the following response headers:

x-middleware-rewrite: /rate-limit-error?retryAfter=1&_rsc=xxxx
x-nextjs-rewritten-path: /rate-limit-error

x-middleware-rewrite:
The middleware rewrote the internal RSC request to the rate-limit error route.

x-nextjs-rewritten-path:
Next.js ultimately processed the request as /rate-limit-error.

This means that when an internal RSC request was triggered, the middleware rewrote it to the rate-limit error route, and Next.js ultimately processed the request as /rate-limit-error.

Flow of the Issue

The user clicks a <Link>.
Next.js sends an internal RSC request to fetch data for the next page.
The rate-limiting middleware incorrectly applies rate limiting to this internal request.
The middleware rewrites the request to /rate-limit-error.
The browser URL remains correct, but the fetched content comes from a different route.
This mismatch causes the page to appear broken or not update as expected.

This mismatch causes the page to appear broken or not update as expected.

Let's fix

Before

Our rate-limiting middleware was too broad and could apply to internal Next.js requests. As a result, RSC requests triggered by navigation were sometimes rate-limited and rewritten to /rate-limit-error, causing the URL and rendered content to mismatch.
Before (problem)

// Rate limit applied too broadly
const shouldRateLimit = true; ←too broad

// Incomplete RSC detection
const hasRscParam = requestUrl.includes('_rsc=');
const hasRscHeader = request.headers.get('rsc') === '1';
const isRSCRequest = hasRscParam || hasRscHeader;

// Internal requests were not excluded
if (shouldRateLimit && isRateLimited) {
  return NextResponse.rewrite(
    new URL('/rate-limit-error', request.url)
  );
}

Problem:
Internal RSC requests triggered by navigation could be rate-limited and rewritten.

After

We restricted rate limiting to API routes and non-GET requests only, and explicitly excluded internal Next.js requests (RSC/router requests). This prevented the middleware from rewriting navigation-related requests and restored stable client-side routing.

// Rate limit only APIs and non-GET requests
const isApiRoute = pathname.startsWith('/api/');
const isNonGetRequest = request.method !== 'GET';
const shouldRateLimit = isApiRoute || isNonGetRequest;

// Accurate RSC detection
const hasRscParam = requestUrl.includes('_rsc=');
const hasRscHeader = request.headers.get('rsc') === '1';
const hasRscAccept =
  request.headers.get('accept')?.includes('text/x-component');
const isRSCRequest = hasRscParam || hasRscHeader || hasRscAccept;

// Exclude internal navigation requests
if (shouldRateLimit && !isRSCRequest && isRateLimited) {
  return NextResponse.rewrite(
    new URL('/rate-limit-error', request.url)
  );
}

Exclude internal RSC requests from rate limiting and apply rate limits only to API and non-GET requests.

To avoid similar issues in the future

Apply rate limiting only to API routes and non-GET requests.
Explicitly exclude internal Next.js requests such as RSC and router-related requests from middleware logic.
Be cautious when using rewrites in middleware, especially with client-side navigation.
When navigation behaves inconsistently, inspect the Network tab and response headers to check for unexpected rewrites.

Keeping these points in mind helps ensure stable navigation and avoids hard-to-debug issues in production.

Boosting LCP: Next.js Performance with next/dynamic

Atena / Full stack developer — Thu, 12 Feb 2026 21:37:37 +0000

Every frontend engineer knows the pain. Your team keeps requesting you to add new features to the website, and suddenly your LCP score takes a nose dive.

This is exactly where next/dynamic saves the day. I’ve used this method to rescue performance scores.

1. What is `next/dynamic`?

It’s a tool for Lazy Loading your React components. When you do a standard import like import Header from './Header', that component gets bundled into the main JavaScript file. This means the browser has to download, parse, and execute that code before the user can really interact with the page. This kills your LCP score.
next/dynamic lets you tell the bundler: "Don't load this yet. Wait until we actually need it." It splits the code into a separate "chunks" file.

2. Two Strategies for Using It

There are two main ways I use next/dynamic, depending on what I'm trying to fix.

Strategy 1: Optimizing for Timing (Fixing LCP)

This is for things the user doesn't see immediately, like heavy components or a section way down the page. By lazy loading these, you let the browser focus 100% of its energy on rendering the Hero section. This makes the perceived load time much faster.

const HeavyComponent = dynamic(() => import('../components/Heavy'),
 {
  loading: () => <p>Loading...</p>,
 })

Strategy 2: Optimizing for Location (Server vs. Browser)

Sometimes, you have code that simply cannot run on the server. Maybe it uses window, document, or a library. By using the ssr: false option, you force the component to be rendered entirely on the client side.

const MapComponent = dynamic(() => import('../components/Map'),
 {
  ssr: false, // Skip the server entirely!
 })

3. `next/dynamic` vs. `'use client'`

This is where I got confused. If I import a component with ssr: true, but that component has 'use client', does that make it CSR?

The answer is No. It is still SSR first.
To clear up this confusion, we need to correct our mental model.

Method vs. Declaration

We must distinguish between the Method and the Declaration.

SSR/CSR is a Method. It describes when and where the rendering happens.
'use client' is a Declaration. It signals what features (like hooks or event listeners) are being used.

It can be confusing that adding 'use client' opts out of SSR. This is wrong. In the Next.js App Router, even if you mark a component with 'use client', it is still rendered on the server initially.

Then how does the 'use client' work with SSR/ CSR?

SSR with 'use client'
The server pre-renders the HTML Shell (the tags like <button> inside the server box). The 'use client' acts as Hydration to make the existing button interactive after it arrives in the browser. The HTML is born on the Server. The user sees the content immediately.
CSR with 'use client'
The server skips rendering and sends an Empty Shell. The server skips rendering and sends an Empty Shell. Here, the JavaScript bundle must build the entire UI from scratch inside the Browser. The user waits for the JS to load before seeing any content.

Performance is all about control.You need to know what is rendering, where it's rendering, and when.

Want to improve LCP?
→ Use next/dynamic to split up your heavy JS bundles.

Fixing a "window is undefined" error?
→ Use ssr: false to skip the server execution entirely.

Need a button to click?
→ Use 'use client' to add interactivity (while keeping SSR).

But remember, with'use client', the HTML is still born on the server. Learning this distinction is the key to building Next.js apps that feel instant.