Bird
Raised Fist0
NextJSframework~8 mins

Authentication in middleware in NextJS - Performance & Optimization

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: Authentication in middleware
MEDIUM IMPACT
This affects the initial page load speed and interaction responsiveness by adding server-side checks before rendering content.
Protecting pages by checking user authentication
NextJS
import { NextResponse } from 'next/server';

export function middleware(request) {
  const token = request.cookies.get('token');
  if (!token) {
    return NextResponse.redirect(new URL('/login', request.url));
  }
  return NextResponse.next();
}
Middleware runs once per request before rendering, centralizing auth and reducing redundant server calls.
📈 Performance GainReduces repeated server processing; improves LCP by handling auth early
Protecting pages by checking user authentication
NextJS
export async function getServerSideProps(context) {
  const user = await getUserFromSession(context.req);
  if (!user) {
    return {
      redirect: {
        destination: '/login',
        permanent: false
      }
    };
  }
  return { props: { user } };
}
This runs authentication on every page request, causing slower page loads and duplicated logic across pages.
📉 Performance CostBlocks rendering until server-side auth completes; adds latency to LCP
Performance Comparison
PatternDOM OperationsReflowsPaint CostVerdict
Auth in getServerSidePropsN/A (server-side)N/ABlocks initial paint until auth completes[X] Bad
Auth in middlewareN/A (server-side)N/AMinimal blocking, early redirect improves paint timing[OK] Good
Rendering Pipeline
Middleware runs in the server before the rendering pipeline starts, intercepting requests to check authentication and redirect if needed.
Server Request Handling
Routing
Rendering Start
⚠️ BottleneckServer Request Handling stage due to synchronous auth checks
Core Web Vital Affected
LCP
This affects the initial page load speed and interaction responsiveness by adding server-side checks before rendering content.
Optimization Tips
1Run authentication early in middleware to reduce redundant server calls.
2Keep middleware logic minimal to avoid blocking rendering.
3Avoid heavy computations or database calls inside middleware.
Performance Quiz - 3 Questions
Test your performance knowledge
How does authentication in Next.js middleware affect page load?
AIt increases DOM nodes causing more reflows.
BIt runs after page render, so it does not affect load time.
CIt runs before rendering, potentially delaying LCP but centralizes auth logic.
DIt adds large JavaScript bundles to the client.
DevTools: Performance
How to check: Record a page load with and without middleware auth; look for server blocking time and LCP timing.
What to look for: Lower server blocking time and faster LCP indicate better middleware auth performance.

Practice

(1/5)
1. What is the main purpose of using middleware for authentication in Next.js?
easy
A. To fetch data from an external API before rendering
B. To check if a user is logged in before allowing access to certain pages
C. To style the pages dynamically based on user preferences
D. To optimize images for faster loading

Solution

  1. Step 1: Understand middleware role

    Middleware runs before page rendering to control access.
  2. Step 2: Identify authentication use

    Middleware checks if user is logged in to allow or block access.
  3. Final Answer:

    To check if a user is logged in before allowing access to certain pages -> Option B
  4. Quick Check:

    Middleware controls access = C [OK]
Hint: Middleware runs before pages to check login [OK]
Common Mistakes:
  • Thinking middleware styles pages
  • Confusing middleware with data fetching
  • Assuming middleware optimizes images
2. Which of the following is the correct way to import middleware in Next.js 14+ for authentication?
easy
A. import { NextResponse } from 'next/server';
B. import { middleware } from 'next/auth';
C. import middleware from 'next/middleware';
D. import { useMiddleware } from 'next/hooks';

Solution

  1. Step 1: Check Next.js middleware import

    Next.js middleware uses 'next/server' for NextResponse and request handling.
  2. Step 2: Identify correct import

    Only 'import { NextResponse } from "next/server";' is valid for middleware response.
  3. Final Answer:

    import { NextResponse } from 'next/server'; -> Option A
  4. Quick Check:

    Middleware uses NextResponse from next/server [OK]
Hint: Middleware uses NextResponse from 'next/server' [OK]
Common Mistakes:
  • Importing middleware from 'next/auth' which doesn't exist
  • Using default import from 'next/middleware' which is invalid
  • Trying to import hooks for middleware
3. Given this middleware code snippet, what happens when a user is not authenticated?
import { NextResponse } from 'next/server';
export function middleware(request) {
  const token = request.cookies.get('token');
  if (!token) {
    return NextResponse.redirect(new URL('/login', request.url));
  }
  return NextResponse.next();
}
medium
A. The middleware throws an error
B. The user stays on the current page without changes
C. The user is redirected to the /login page
D. The user is redirected to the homepage

Solution

  1. Step 1: Check token presence

    The code checks if 'token' cookie exists; if not, it redirects.
  2. Step 2: Understand redirect behavior

    Without token, middleware returns redirect to '/login' URL.
  3. Final Answer:

    The user is redirected to the /login page -> Option C
  4. Quick Check:

    No token means redirect to /login [OK]
Hint: No token cookie triggers redirect to /login [OK]
Common Mistakes:
  • Assuming user stays on page without token
  • Thinking middleware throws error on missing token
  • Confusing redirect to homepage instead of /login
4. Identify the error in this Next.js middleware code for authentication:
import { NextResponse } from 'next/server';
export function middleware(request) {
  const token = request.cookies.token;
  if (!token) {
    return NextResponse.redirect('/login');
  }
  return NextResponse.next();
}
medium
A. Accessing cookies should use request.cookies.get('token') instead of request.cookies.token
B. NextResponse.redirect requires a full URL, not just '/login'
C. Middleware function must be async
D. NextResponse.next() should be replaced with NextResponse.continue()

Solution

  1. Step 1: Check cookie access method

    In Next.js middleware, cookies are accessed with request.cookies.get('token'), not as a property.
  2. Step 2: Verify redirect argument

    NextResponse.redirect accepts a URL object or string, but string '/login' is allowed; full URL preferred but not mandatory.
  3. Final Answer:

    Accessing cookies should use request.cookies.get('token') instead of request.cookies.token -> Option A
  4. Quick Check:

    Use cookies.get('token') to read cookie [OK]
Hint: Use cookies.get('token') to read cookies in middleware [OK]
Common Mistakes:
  • Accessing cookies as properties instead of using get()
  • Thinking redirect needs full URL always
  • Assuming middleware must be async
  • Confusing NextResponse.next() with continue()
5. You want to protect only the /dashboard and /profile pages using middleware authentication. Which matcher configuration correctly applies middleware only to these paths?
export const config = {
  matcher: ???
};
hard
A. ['/dashboard', '/profile']
B. '/dashboard|/profile'
C. '/dashboard/*,/profile/*'
D. ['/dashboard*', '/profile*']

Solution

  1. Step 1: Understand matcher syntax

    Matcher accepts array of path patterns; '*' matches subpaths.
  2. Step 2: Choose correct pattern for pages

    Using ['/dashboard*', '/profile*'] matches both exact and nested routes under these paths.
  3. Final Answer:

    ['/dashboard*', '/profile*'] -> Option D
  4. Quick Check:

    Use array with wildcard for matcher [OK]
Hint: Use array with '*' wildcard for matcher paths [OK]
Common Mistakes:
  • Using string with pipe '|' instead of array
  • Omitting '*' wildcard to match subpaths
  • Using comma-separated string instead of array