Next.js Middleware prestazioni – meccanismi interni e trappole in produzione

Next.js Middleware è un meccanismo potente che consente di eseguire codice al bordo (edge) prima che la richiesta raggiunga la pagina o l'API Route corretta. Grazie a questo possiamo implementare autorizzazione, logging, redirection o modifica degli header in tempo reale, il tutto con un impatto minimo sui ritardi. In questo articolo esamineremo come funziona il Middleware in Next.js dietro le quinte, le sue implicazioni sulle prestazioni, l'impatto sulla sicurezza e le trappole più comuni che i team incontrano quando lo implementano in produzione.

Come funziona il Middleware in Next.js

Dalla versione 12 Next.js ha introdotto il supporto per Edge Runtime, ovvero l'ambiente di esecuzione del codice nella rete CDN (ad esempio Vercel Edge Network). Il Middleware viene compilato in Edge Functions e avviato nel nodo di rete più vicino al cliente. In questo modo il tempo di risposta è limitato a pochi millisecondi, e allo stesso tempo abbiamo accesso all'intero oggetto Request e Response conforme alle Web Standard API.

// middleware.ts
import { NextResponse } from 'next/server';
export function middleware(request) {
  const url = request.nextUrl;
  if (url.pathname.startsWith('/admin') && !request.cookies.get('auth')) {
    return NextResponse.redirect(new URL('/login', request.url));
  }
  return NextResponse.next();
}

Nel esempio sopra il codice viene eseguito ad ogni richiesta, e la decisione di reindirizzare viene presa prima ancora di raggiungere lo strato applicativo. Il Middleware è definito nella cartella pages o app come file middleware.ts e viene applicato automaticamente a tutte le rotte, a meno che non lo limitiamo usando matcher in next.config.js.

Architettura e costo di chiamata

Le Edge Functions sono isolate in contenitori di tipo V8 Isolate, il che significa che non hanno accesso alle API di Node.js (ad esempio fs). Ogni chiamata richiede:

• deserializzazione della richiesta in un oggetto Request,
• esecuzione del codice JavaScript (o TypeScript dopo la transpilation),
• serializzazione della eventuale risposta.

In pratica il costo di avvio è fisso – circa 0,5‑1 ms per una condizione semplice, ma cresce linearmente con il numero di operazioni I/O (ad esempio lettura dei cookies, chiamate fetch a servizi esterni). Perciò è fondamentale minimizzare la logica nel Middleware.

Next.js Middleware e sicurezza

Posizionando la logica di sicurezza nello strato edge, otteniamo due vantaggi importanti: (1) l'attaccante non raggiunge il server dell'applicazione, e (2) possiamo imporre politiche CSP o HSTS prima del rendering. Tuttavia, poiché il codice gira in un ambiente limitato, non abbiamo accesso alle tradizionali librerie crittografiche – dobbiamo fare affidamento sulle funzioni integrate crypto.subtle o su servizi esterni.

«La sicurezza nel Middleware non è solo bloccare richieste non autorizzate, ma anche ridurre la superficie di attacco eseguendo i controlli più vicino all'utente.»

Pratiche fondamentali:

• Valida tutti gli header e i parametri di input – l'edge non conosce i tipi.
• Usa token a breve vita (ad esempio JWT con TTL breve), per evitare la necessità di conservare sessioni a lungo termine in memoria.
• Non registrare dati sensibili nel Middleware – i log sono conservati nella CDN e possono essere accessibili più ampiamente.

Ottimizzazione del Middleware in un’app Next.js

L’ottimizzazione parte dalla limitazione dell’ambito di azione. matcher consente di specificare quali percorsi sono coperti dal Middleware, riducendo il numero di invocazioni. Esempio di configurazione:

// next.config.js
module.exports = {
  async redirects() {
    return [];
  },
  middleware: {
    matcher: ['/admin/:path*', '/api/protected/:path*']
  }
};

Inoltre, è consigliabile evitare operazioni fetch costose nel Middleware. Se è necessario recuperare dati, considera di cachearli in Edge Config o nella CDN. Esempio di semplice cache:

export async function middleware(request) {
  const cacheKey = `user-${request.cookies.get('auth')}`;
  const cached = await caches.default.match(cacheKey);
  if (cached) return NextResponse.next();
  // ...fetch user profile
}

Ricorda che l’Edge Cache ha limiti di dimensione (fino a 5 MB) e TTL (max 30 giorni). Perciò è possibile cacheare solo piccoli frammenti immutabili.

Quando usare il Middleware e quando no

Il Middleware è ideale in scenari che richiedono decisioni rapide prima del rendering: autorizzazione, geo‑targeting, A/B testing, modifica degli header. Non è invece un sostituto delle API Routes complete, quando è necessario:

• operazioni su database ad alta latenza,
• gestione di file, streaming o payload di grandi dimensioni,
• processi a lunga durata (ad es. generazione di PDF).

In questi casi è preferibile utilizzare le API Routes, che funzionano nel tradizionale runtime Node.js e offrono pieno accesso all'ambiente server.

Checklist: Implementazione sicura del Middleware in produzione

• ✅ Definisci un matcher preciso – limita le chiamate ai percorsi necessari.
• ✅ Evita fetch sincroni – se devi usarli, implementa la cache.
• ✅ Valida e sanitizza tutti i dati in ingresso.
• ✅ Monitora il tempo di esecuzione (ad es. con Vercel Analytics) – obiettivo < 5 ms.
• ✅ Testa in modalità development e preview prima della produzione.
• ✅ Non memorizzare chiavi segrete nel codice – utilizza le variabili d'ambiente disponibili nell'Edge Runtime.

Errori comuni e compromessi

Uno degli errori più frequenti è inserire logica di business costosa nel Middleware, il che aumenta la latenza e il consumo di risorse edge. Un'altra trappola è fare affidamento su stato globale (ad es. singleton) – nelle istanze isolate non esiste memoria condivisa, quindi ogni richiesta opera in un contesto pulito.

Compromessi di performance:

• Ridurre il numero di chiamate fetch a scapito di dati leggermente più vecchi nella cache.
• Utilizzare semplici regole regex nel matcher invece di condizioni complesse nel codice.

Se hai bisogno di una logica più avanzata, considera di suddividerla in due fasi: decisione rapida nel Middleware e verifica completa nella API Route.

In sintesi, Next.js Middleware è uno strumento potente che, con una configurazione adeguata e un approccio consapevole alle performance, può migliorare significativamente la sicurezza e la reattività dell'applicazione. Se desideri implementare un sistema Middleware ottimale nel tuo progetto, il nostro team di Coderia.it ti aiuterà a scegliere l'architettura, eseguire un audit e garantire stabilità in produzione.