Bird
Raised Fist0
NextJSframework~8 mins

Why middleware intercepts requests in NextJS - Performance Evidence

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Performance: Why middleware intercepts requests
MEDIUM IMPACT
Middleware interception affects the time before the main page content starts loading by running code on requests early in the server process.
Running middleware to check authentication on every request
NextJS
import { NextResponse } from 'next/server';

export function middleware(request) {
  // minimal quick check
  if (!request.cookies.get('auth')) {
    return NextResponse.redirect('/login');
  }
  return NextResponse.next();
}
Minimal logic avoids blocking, quickly passes request to next step or redirects early.
📈 Performance Gainreduces blocking to under 5ms, improving LCP
Running middleware to check authentication on every request
NextJS
import { NextResponse } from 'next/server';

export function middleware(request) {
  // heavy synchronous logic
  for (let i = 0; i < 1000000; i++) {}
  return NextResponse.next();
}
Heavy synchronous work blocks the request pipeline, delaying response start and LCP.
📉 Performance Costblocks rendering for 50-100ms depending on device
Performance Comparison
PatternDOM OperationsReflowsPaint CostVerdict
Heavy synchronous middleware logic0 (server-side)0Blocks initial paint[X] Bad
Minimal quick middleware checks0 (server-side)0Non-blocking initial paint[OK] Good
Rendering Pipeline
Middleware runs before the main rendering pipeline starts, intercepting requests to modify or redirect them early. This affects the server response time and delays when the browser can start rendering.
Request Handling
Server Response
Initial HTML Delivery
⚠️ BottleneckMiddleware processing time delays server response start, impacting LCP.
Core Web Vital Affected
LCP
Middleware interception affects the time before the main page content starts loading by running code on requests early in the server process.
Optimization Tips
1Keep middleware logic minimal to avoid blocking server response.
2Avoid heavy synchronous work inside middleware to improve LCP.
3Use middleware mainly for quick checks like authentication or redirects.
Performance Quiz - 3 Questions
Test your performance knowledge
How does heavy synchronous logic in Next.js middleware affect page load?
AIt has no effect on page load performance.
BIt speeds up the page load by pre-processing data.
CIt delays the server response, increasing Largest Contentful Paint time.
DIt only affects client-side rendering speed.
DevTools: Performance
How to check: Record a performance profile while loading a page with middleware. Look for long tasks in the server-side timeline before the first contentful paint.
What to look for: Long blocking tasks before the first paint indicate slow middleware delaying LCP.

Practice

(1/5)
1. What is the main reason Next.js middleware intercepts requests?
easy
A. To render React components on the server
B. To directly update the database
C. To check or modify requests before they reach the app
D. To compile CSS styles

Solution

  1. Step 1: Understand middleware role

    Middleware runs before the app processes requests, allowing inspection or modification.
  2. Step 2: Identify middleware purpose

    It is used for tasks like login checks, redirects, or adding headers before the app handles the request.
  3. Final Answer:

    To check or modify requests before they reach the app -> Option C
  4. Quick Check:

    Middleware intercepts requests = B [OK]
Hint: Middleware runs before app handles requests [OK]
Common Mistakes:
  • Thinking middleware renders UI components
  • Assuming middleware updates databases directly
  • Confusing middleware with CSS compilation
2. Which of the following is the correct way to continue request processing in Next.js middleware?
easy
A. return NextResponse.next()
B. return fetch()
C. return res.send()
D. return render()

Solution

  1. Step 1: Identify continuation method

    Next.js middleware uses NextResponse.next() to continue processing the request.
  2. Step 2: Eliminate incorrect options

    fetch() is for network calls, res.send() is Express.js syntax, render() is unrelated here.
  3. Final Answer:

    return NextResponse.next() -> Option A
  4. Quick Check:

    Continue middleware with NextResponse.next() = D [OK]
Hint: Use NextResponse.next() to continue middleware [OK]
Common Mistakes:
  • Using Express.js methods like res.send()
  • Trying to fetch inside middleware to continue
  • Calling render() which is not middleware syntax
3. Given this middleware code snippet, what happens when a request to '/dashboard' is made?
import { NextResponse } from 'next/server';
export function middleware(request) {
  if (!request.cookies.get('token')) {
    return NextResponse.redirect(new URL('/login', request.url));
  }
  return NextResponse.next();
}
medium
A. The user is redirected to '/login' if no token cookie is found
B. The request is blocked with an error
C. The request proceeds without any check
D. The middleware crashes due to syntax error

Solution

  1. Step 1: Analyze cookie check

    The middleware checks if the 'token' cookie exists in the request.
  2. Step 2: Determine behavior based on cookie

    If no token cookie, it redirects to '/login'; otherwise, it continues processing.
  3. Final Answer:

    The user is redirected to '/login' if no token cookie is found -> Option A
  4. Quick Check:

    Missing token cookie triggers redirect = A [OK]
Hint: Check cookie presence to decide redirect or continue [OK]
Common Mistakes:
  • Assuming request is blocked instead of redirected
  • Thinking middleware crashes due to syntax
  • Ignoring cookie check and assuming request proceeds
4. Identify the error in this Next.js middleware code:
import { NextResponse } from 'next/server';
export function middleware(request) {
  if (request.nextUrl.pathname === '/admin') {
    NextResponse.redirect('/login');
  }
  return NextResponse.next();
}
medium
A. Incorrect import statement for NextResponse
B. Missing return before NextResponse.redirect()
C. Using request.nextUrl.pathname instead of request.url
D. NextResponse.next() should not be called

Solution

  1. Step 1: Check redirect usage

    NextResponse.redirect() must be returned to stop further processing.
  2. Step 2: Identify missing return

    The code calls NextResponse.redirect() but does not return it, so middleware continues incorrectly.
  3. Final Answer:

    Missing return before NextResponse.redirect() -> Option B
  4. Quick Check:

    Always return redirect response in middleware = A [OK]
Hint: Always return redirect response in middleware [OK]
Common Mistakes:
  • Forgetting to return redirect response
  • Confusing request.nextUrl with request.url
  • Thinking NextResponse.next() is disallowed
5. You want to use Next.js middleware to block access to '/secret' unless a user has a valid 'auth' cookie. Which approach correctly applies this logic and continues processing other requests normally?
hard
A. Throw an error if 'auth' cookie is missing
B. Always return NextResponse.next() without checking cookies
C. Modify the request URL directly without returning a response
D. Return NextResponse.redirect('/login') if no 'auth' cookie; else return NextResponse.next()

Solution

  1. Step 1: Define blocking condition

    Check if the 'auth' cookie exists when the request is for '/secret'.
  2. Step 2: Apply redirect or continue

    If no cookie, return a redirect response to '/login'; otherwise, call NextResponse.next() to continue.
  3. Final Answer:

    Return NextResponse.redirect('/login') if no 'auth' cookie; else return NextResponse.next() -> Option D
  4. Quick Check:

    Redirect missing auth, else continue = C [OK]
Hint: Redirect missing auth cookie, else continue with NextResponse.next() [OK]
Common Mistakes:
  • Not returning redirect response
  • Throwing errors instead of redirecting
  • Modifying request without returning response