Exception mapping interceptor in NestJS - Performance & Optimization

Performance: Exception mapping interceptor

MEDIUM IMPACT

This affects server response time and client perceived latency by how exceptions are caught and transformed before sending responses.

Handling exceptions to send user-friendly error responses

NestJS

import { CallHandler, ExecutionContext, Injectable, NestInterceptor } from '@nestjs/common';
import { Observable, throwError } from 'rxjs';
import { catchError } from 'rxjs/operators';

@Injectable()
export class GoodExceptionInterceptor implements NestInterceptor {
  intercept(context: ExecutionContext, next: CallHandler): Observable<any> {
    return next.handle().pipe(
      catchError(err => {
        // Non-blocking error mapping
        const mappedError = new Error('Mapped error');
        return throwError(() => mappedError);
      }),
    );
  }
}

Avoids blocking operations, allowing the event loop to remain free and responses to be sent faster.

📈 Performance GainNon-blocking error handling improves INP and reduces server response delays

Handling exceptions to send user-friendly error responses

NestJS

import { CallHandler, ExecutionContext, Injectable, NestInterceptor } from '@nestjs/common';
import { Observable, throwError } from 'rxjs';
import { catchError } from 'rxjs/operators';

@Injectable()
export class BadExceptionInterceptor implements NestInterceptor {
  intercept(context: ExecutionContext, next: CallHandler): Observable<any> {
    return next.handle().pipe(
      catchError(err => {
        // Synchronously blocking operation
        const end = Date.now() + 100;
        while (Date.now() < end) {}
        return throwError(() => new Error('Mapped error'));
      }),
    );
  }
}

Blocking the event loop inside the interceptor delays all other requests and increases server response time.

📉 Performance CostBlocks event loop for 100ms per error, increasing INP and overall latency

Performance Comparison

Pattern	Event Loop Blocking	Response Delay	Server Load	Verdict
Blocking synchronous error mapping	Yes, blocks event loop	High delay per error	Increases under load	[X] Bad
Non-blocking asynchronous error mapping	No blocking	Minimal delay	Efficient under load	[OK] Good

Rendering Pipeline

Exception mapping interceptors run on the server before sending the HTTP response. They catch errors from request handlers and transform them. Blocking operations here delay the server's response, increasing client wait time.

→Server Processing

→Response Generation

⚠️ BottleneckBlocking synchronous code inside the interceptor delays response generation

Core Web Vital Affected

INP

This affects server response time and client perceived latency by how exceptions are caught and transformed before sending responses.

Optimization Tips

1Never block the Node.js event loop inside interceptors.

2Use asynchronous error handling to keep server responses fast.

3Monitor server response times to catch slow exception mapping.

Performance Quiz - 3 Questions

What is the main performance risk of blocking synchronous code inside an exception mapping interceptor?

A It causes layout shifts in the browser

B It blocks the event loop, delaying all server responses

C It increases CSS paint time on the client

D It reduces the bundle size

DevTools: Network and Performance panels

How to check: Use Network panel to measure response times for requests that trigger errors. Use Performance panel to check if server responses are delayed due to blocking code.

What to look for: Look for long server response times and event loop blocking indicators in Performance traces.