Email Validation Performance on Hot Paths

Validation lives on your busiest endpoints. If the check is slow, you either drop it or you slow the whole request. The fix is to make it cheap enough that the question never comes up.

The cost of each approach

• Regex: microseconds — but proves almost nothing.
• DNS / MX lookup: 20–200ms, cache-dependent, fails under packet loss.
• External API: 80–400ms plus rate limits and an availability dependency.
• Local dataset lookup: a single in-process operation, no I/O at all.

Why local wins on hot paths

No DNS queries, no HTTP round-trips, no rate limits, no retry logic, no circuit breaker, no timeout tuning. The check adds no tail latency, so you can safely run it on signup, comment submission, password reset, waitlist forms and coupon redemption alike.

Practical tips

• Import once at module scope so the dataset is loaded a single time per process.
• Normalise input — trim and lowercase — before checking.
• Run the cheap format check first and short-circuit obvious garbage.
• On edge runtimes, keep the module in the shared scope so it survives between invocations.

import isSpam from "spamnull";

const clean = (email) => email.trim().toLowerCase();
const blocked = isSpam(clean(input));

Serverless and cold starts

A bundled dataset adds to bundle size but removes a network dependency — usually the better trade on edge runtimes, where an outbound call can cost more than the entire cold start. The reasoning is laid out in self-hosted vs API validation, and the implementation in the Node.js signup guide.

$ npm install spamnull