Best Practices for Performance with 1000+ Redirects (Regex, Wildcard, Path Matching)

[burakozdemir32]

Summary

Hi everyone,

We're scaling up our Next.js application and will soon need to manage a large list of over 1,000 redirects. This list is a mix of different types:

1. Simple 1:1 redirects (e.g., /old-path to /new-path)
2. Path matching (e.g., /old-products/:id to /new-shop/:id)
3. Wildcard matching (e.g., /docs/v1/:path* to /docs/v2/:path*)
4. Complex Regex matching.

My main concern is the performance impact on our server response time.

For the simple 1:1 redirects, I was considering using a Bloom filter as a quick, probabilistic check to see if a path exists in our redirect map before doing a full lookup. This seems very efficient for exact matches.

However, a Bloom filter doesn't work for path matching, wildcards, or regex patterns.

My questions are:

What is the recommended, high-performance approach for handling a large number of wildcard and regex-based redirects in Next.js?

Is the built-in next.config.js redirects array optimized to handle this scale without a significant performance hit?

Should I move this logic into middleware?

If using middleware, what's the best strategy to avoid iterating through a thousand regexes on every request? Are there specific data structures or optimized regex engines that the community recommends for this use case?

I'm trying to build a solution that is both scalable and keeps our TTFB (Time to First Byte) as low as possible. Any insights or examples would be greatly appreciated.

Thanks!

Additional information

No response

Example

No response

[ahuaiqom]

Hi @burakozdemir32 👋

TL;DR: Treat redirects in tiers.

Exact 1:1 → use redirects() in next.config.js (compiled to a manifest and matched before your app code) or handle at the CDN/reverse-proxy.

Param / wildcard / regex → use Middleware with a precompiled matcher (no per-request regex creation), indexed by prefix so you don’t iterate 1k rules every request. Avoid remote lookups on the hot path.

1) Exact 1:1 (fastest path)

next.config.js
// Thousands of simple redirects are fine; Next compiles these to a fast manifest. export async function redirects() { return [ { source: "/old-path", destination: "/new-path", permanent: true }, // ... generate from a CSV/JSON ]; }
These run before pages/middleware and add negligible TTFB. If you’re on a CDN/reverse proxy (Vercel/Cloudflare/Nginx), you can also put exact rules there.

**2) Param, wildcard, and regex (use Middleware with an indexed matcher)

Idea: Build a prefix index → only check a small subset of rules. Precompile patterns once at module scope.**
`// middleware.ts (Edge Runtime)
import { NextResponse } from "next/server";
import { match } from "path-to-regexp";

// Example rules (could be imported as JSON at build time)
const rules = [
{ src: "/old-products/:id", dst: "/new-shop/:id", code: 308 },
{ src: "/docs/v1/:path*", dst: "/docs/v2/:path*", code: 308 },
{ src: "/blog/:year(\d{4})/:slug", dst: "/articles/:year/:slug", code: 308 },
];

type Compiled = {
prefix: string; // leading static segment for indexing
exec: ReturnType;
dst: string;
code: number;
};

// Precompile once
const compiled: Record<string, Compiled[]> = {};
for (const r of rules) {
const m = match(r.src, { decode: decodeURIComponent, strict: false, end: true });
const prefix = r.src.split("/")[1] ?? ""; // first path segment
(compiled[prefix] ||= []).push({ prefix, exec: m, dst: r.dst, code: r.code });
}

export function middleware(req: Request) {
const url = new URL(req.url);
const seg1 = url.pathname.split("/")[1] ?? "";
const candidates = (compiled[seg1] || []).concat(compiled[""] || []);

for (const c of candidates) {
const res = c.exec(url.pathname);
if (res) {
// fill params into dst
let location = c.dst;
for (const [k, v] of Object.entries(res.params)) {
location = location.replace(:${k}, Array.isArray(v) ? v.join("/") : String(v));
}
return NextResponse.redirect(new URL(location, url), c.code);
}
}

return NextResponse.next();
}

export const config = {
// only run middleware where needed
matcher: ["/((?!_next|static|favicon.ico).*)"],
};
`
Why this is fast

• No per-request regex creation (precompiled at module scope).

• Prefix index slashes candidates from 1000 → handful.

• Edge runtime keeps it close to users; no I/O on hot path.

3) Data-structure tips

Prefer path-to-regexp (precompiled) over ad-hoc RegExp strings.

Index by first static segment (or longest static prefix) → O(1) bucket lookup.

If patterns share long prefixes (e.g., /docs/...), build a radix trie; libraries like find-my-way (pure JS) do this well.

4) What not to do

Don’t evaluate a thousand regexes every request.

Don’t fetch rules from a remote KV/DB on each hit—hydrate at build time or cache in module scope.

Bloom filters help exact matches, but not wildcards/regex—use them only for tier-1 lookups (or skip; the manifest/CDN is already O(1)).

5) When to use Middleware vs next.config.js

Use redirects() for exact routes (fastest, zero code).

Use Middleware only for parameterized/wildcard/regex or when redirect logic depends on request context (headers, A/B, geo).

Bottom line:

Keep exact redirects in redirects()/CDN.

Handle complex patterns in Middleware with a precompiled, prefix-indexed matcher.

Avoid per-request iteration and any network I/O.
That combination scales well past 1k+ redirects with minimal TTFB impact.