DEV Community: Loknath Patel

Why Your Node.js API Is Slow in Production: 10 Mistakes That Pass Code Review

Loknath Patel — Mon, 12 Oct 2026 04:29:39 +0000

Spot the bug in 10 seconds:

const controller = new AbortController();
const timer = setTimeout(() => controller.abort(), 1000);

const res = await fetch(url, { signal: controller.signal });
clearTimeout(timer);
const body = await res.text();

The timeout is 1 second. The server sends its headers right away, then stalls the body for 3 seconds. I ran this on Node.js 22 and it waited 3.06 seconds. No error. No timeout. Nothing in the logs.

Found it? The answer is in Mistake 8. First, a picture of why bugs like this hurt so much.

Imagine a chai tapri with one counter and one person serving. A customer reaches the counter and spends five minutes counting coins. Everyone behind him waits too, even the person who only wants a 10-rupee chai. Nobody crashes. Nobody shouts. The line just gets longer.

That is your Node.js event loop. Your JavaScript runs on one thread, and one slow operation delays every request in the queue. Most mistakes below are variations of that picture: some block the counter, some wait forever with no timeout, some send the same order to the kitchen 100 times.

I reproduced ten mistakes like these on Node.js 22. They look fine in code review, they throw no errors, and they only hurt under real traffic. A few results from my tests:

A /fast route that took 190 ms instead of 0.7 ms because a different request was running (Mistake 1).
A cache that read the same file 100 times for 100 concurrent requests instead of once (Mistake 7).
An event-loop monitor that printed 20365311 ms of lag on a completely idle server (explained in the next section).

Every snippet marked Tested has a script you can run in the companion repo. Database and framework snippets are illustrative: names like pool, app and getUser stand in for your own code, and they were not run against a real database.

The golden rule: measure first

Optimizing without measuring is guessing. Start with a timer around suspicious code:

const { performance } = require('node:perf_hooks');

async function timedRoute(label, fn) {
  const start = performance.now();
  const result = await fn();
  console.log(`[PERF] ${label}: ${(performance.now() - start).toFixed(1)}ms`);
  return result;
}

Node ships more in perf_hooks: performance.now(), PerformanceObserver, performance.eventLoopUtilization() and monitorEventLoopDelay().

Timers only tell you how long something took. For the bigger picture, use a profiler and a load test:

node --cpu-prof server.js writes a .cpuprofile file when the process exits. Open it in Chrome DevTools.
Clinic.js draws flame graphs from a running app.
npx autocannon -c 100 -d 30 http://localhost:3000/your-route shows latency under 100 concurrent connections. Many bugs below only show up under concurrency.

The 20365311 gotcha

The docs say monitorEventLoopDelay() reports delays in nanoseconds. On an idle Node 22 process with resolution: 20, my p99 was 20,316,159. That is nanoseconds, about 20.3 ms. Print it with an ms label and you get twenty million milliseconds of lag, over five hours, on a server doing nothing. That was the number in the intro.

The 20 ms is not real lag. The values appear to include the sampling interval, so convert to milliseconds and subtract the resolution:

const { monitorEventLoopDelay } = require('node:perf_hooks');

const RESOLUTION_MS = 20;
const h = monitorEventLoopDelay({ resolution: RESOLUTION_MS });
h.enable();

setInterval(() => {
  const toMs = (ns) => ns / 1e6;
  const p99 = Math.max(0, toMs(h.percentile(99)) - RESOLUTION_MS);
  const max = Math.max(0, toMs(h.max) - RESOLUTION_MS);
  console.log(`event loop lag: p99 ~ ${p99.toFixed(1)}ms, max ~ ${max.toFixed(1)}ms`);
  h.reset();
}, 10_000).unref();

Tested: with this 10-second window and one deliberate 300 ms synchronous block, p99 stayed around 0.6 ms while max reported about 297 ms. The window held about 476 samples, so a single stall is one sample and p99 can miss it. Watch max (or use a shorter window) as well, and pick alert thresholds from your own baseline.

Each mistake below has an Impact tag. These are my judgment, not a measurement: Outage-level can take the whole service down, High means large latency or load that grows with your data or traffic, and Medium is wasteful and noticeable at scale.

1. One slow function freezes every request

Impact: Outage-level.

Node runs your JavaScript on one thread. A synchronous operation inside a request handler delays every other request, not just the current one. Typical culprits are fs.readFileSync(), crypto.pbkdf2Sync(), huge JSON.parse() / JSON.stringify() calls, and heavy loops or regexes.

Tested: I ran a server in one process and a load generator in another. A pbkdf2Sync call took about 235 ms by itself. While it ran, requests to an unrelated /fast route had a median latency of 190 ms and a worst case of 233 ms. With the async pbkdf2, the same /fast route stayed at a median of 0.7 ms. Same work, same machine. The only difference is whether the counter was blocked.

Fixes

Do synchronous work once at startup. readFileSync at boot is fine.
At runtime, use the async APIs. crypto.pbkdf2, fs.promises, zlib and similar calls run on libuv's thread pool (4 threads by default, so it is small, not unlimited).
For CPU-bound work you cannot make async, move it to worker_threads. Do not spawn a worker per request; use a pool such as Piscina.

const { Worker } = require('node:worker_threads');

function runInWorker(file, data) {
  return new Promise((resolve, reject) => {
    const w = new Worker(file, { workerData: data });
    w.once('message', resolve);
    w.once('error', reject);
    w.once('exit', (code) => {
      if (code !== 0) reject(new Error(`worker exited with code ${code}`));
    });
  });
}

A caveat: reading a small file synchronously from a local disk is cheap. Blocking becomes a real problem with large files, slow or network disks, and heavy CPU work, so measure before you rewrite.

Blocking is the famous one. The next one is the most common bug in database-backed APIs, and it hides behind code that reads well.

2. The N+1 query: one endpoint, one query per row

Impact: High.

You load a list, then run one more query per item. The code looks clean and the database suffers.

// N+1: 1 query for orders + 1 query per order
async function getUserOrders(userId) {
  const { rows: orders } = await pool.query(
    'SELECT * FROM orders WHERE user_id = $1', [userId]
  );
  for (const order of orders) {
    const { rows } = await pool.query(
      'SELECT * FROM order_items WHERE order_id = $1', [order.id]
    );
    order.items = rows;
  }
  return orders;
}

Batch the child lookup so the query count stays at two, however many orders there are:

async function getUserOrders(userId) {
  const { rows: orders } = await pool.query(
    'SELECT id, status, total FROM orders WHERE user_id = $1', [userId]
  );
  if (orders.length === 0) return [];

  const { rows: items } = await pool.query(
    'SELECT * FROM order_items WHERE order_id = ANY($1)',
    [orders.map((o) => o.id)]
  );

  const byOrder = new Map();
  for (const item of items) {
    if (!byOrder.has(item.order_id)) byOrder.set(item.order_id, []);
    byOrder.get(item.order_id).push(item);
  }
  return orders.map((o) => ({ ...o, items: byOrder.get(o.id) ?? [] }));
}

A single JOIN also works, but it repeats parent columns on every child row, so you have to regroup the rows. In GraphQL servers, DataLoader batches per-tick lookups for you.

With an ORM, N+1 hides behind property access: order.items looks like a field but fires a query. Use eager loading (include in Prisma and Sequelize) and read the SQL log once to confirm.

How to find it: log how many queries each request runs. A request that suddenly runs hundreds is the signal. Some APM tools flag repeated query patterns automatically, and this Scout write-up shows one way to detect it with Prisma.

3. Sending columns nobody reads

Impact: Medium.

SELECT *, or returning a whole ORM document, sends columns the client never uses. That costs database I/O, network bytes and serialization time, and it can leak fields you never meant to expose.

app.get('/api/users/:id', async (req, res) => {
  const { rows } = await pool.query(
    'SELECT id, username, profile_image_url, created_at FROM users WHERE id = $1',
    [req.params.id]
  );
  res.json(rows[0] ?? null);
});

I did not measure the database side, but I can measure what the extra columns do to the response. Tested with synthetic rows: 10,000 rows with 4 fields serialize to 1.27 MB in about 3 ms. The same rows with 30 fields are 11.7 MB and take about 55 ms. That is roughly 9 times the bytes and 19 times the event-loop time, and the client only needed 4 fields.

That serialization time is the bridge to Mistake 10. First, a mistake that costs you latency without blocking anything.

4. Serial await that should run in parallel

Impact: Medium.

Independent calls should run together. Sequential:

// Total time is the sum of all three
const user = await getUser(id);
const orders = await getOrders(id);
const prefs = await getPreferences(id);

Parallel:

// Total time is about the slowest one
const [user, orders, prefs] = await Promise.all([
  getUser(id), getOrders(id), getPreferences(id),
]);

Tested with three simulated 200 ms calls: sequential took about 602 ms, Promise.all about 201 ms.

Things to watch:

Only parallelize independent work. A checkout flow like validate cart, calculate totals, create order, charge payment is dependent: each step needs the previous result, so it must stay sequential.
await does not block the event loop. The cost of serial awaits is latency for that one request.
Promise.all rejects as soon as one promise rejects, and the others keep running (they are not cancelled). Use Promise.allSettled when you need every result.
Parallel queries each take a pool connection, so a high fan-out can exhaust a small pool (Mistake 6).

Three of these ten can take a whole service down, not just slow it. You have already seen one: Mistake 1. The other two are Mistake 6 and Mistake 8. But the next one is the one that gets quietly worse every month, until the day it does not.

5. The query that was fine at 100 rows

Impact: High.

A query that filters, joins or sorts on an unindexed column scans the whole table. That is fine at 100 rows and painful at millions. Confirm with EXPLAIN ANALYZE:

EXPLAIN ANALYZE SELECT id, status, total FROM orders WHERE customer_id = 42;
-- Seq Scan on orders  -> consider an index

CREATE INDEX CONCURRENTLY idx_orders_customer_id ON orders (customer_id);
-- run EXPLAIN ANALYZE again: look for an Index Scan

Indexes are not free. They use disk space and slow down writes, so add the ones your real queries need and verify they are used.

CONCURRENTLY avoids blocking writes while building an index on a live table, but it cannot run inside a transaction block (see the PostgreSQL docs). Many migration tools wrap each migration in a transaction, so mark that migration as non-transactional.

Also remember that EXPLAIN ANALYZE actually runs the query. For INSERT, UPDATE or DELETE, use plain EXPLAIN or run it inside a transaction you roll back.

6. A new database connection per request

Impact: Outage-level.

PostgreSQL (pg): create one pool at startup and reuse it. Never create a Client or Pool per request. And set the timeouts, because the defaults wait forever.

const { Pool } = require('pg');

const pool = new Pool({
  max: 10,                        // per process. See the math below
  connectionTimeoutMillis: 5_000, // fail fast if no connection is free (default 0 = wait forever)
  statement_timeout: 10_000,      // the server cancels any query running longer than 10 s
});

// An idle client can error (for example when the database restarts).
// Without a listener, that unhandled 'error' event can crash the process.
pool.on('error', (err) => console.error('idle pg client error:', err.message));

app.get('/data', async (req, res) => {
  const { rows } = await pool.query('SELECT id, name FROM users LIMIT 50');
  res.json(rows);
});

For transactions or multi-statement work, check out a client and always release it. If ROLLBACK itself fails, the connection is in an unknown state. The node-postgres docs say that passing true to release() makes the pool destroy that client instead of reusing it:

async function transfer(a, b, amount) {
  const client = await pool.connect();
  let destroy = false;
  try {
    await client.query('BEGIN');
    // ... statements ...
    await client.query('COMMIT');
  } catch (err) {
    try {
      await client.query('ROLLBACK');
    } catch (rollbackErr) {
      destroy = true; // do not return a broken client to the pool
      console.error('ROLLBACK failed:', rollbackErr.message);
    }
    throw err; // always surface the original error
  } finally {
    client.release(destroy);
  }
}

The production math nobody does in dev

The pool limit is per process. Postgres has one global limit. If you run 10 instances with max: 20, that is 200 connections, and Postgres' default max_connections is typically 100 (it can be lower on some systems). Autoscaling multiplies the problem exactly when traffic is highest. Pick max so that instances x max stays under the database limit with headroom, or put a pooler like PgBouncer in front.

Connections are not free on the server either: each one is a separate Postgres process, and memory per connection depends on your workload (see this PGConf talk). Keep the count bounded and pooled. See the node-postgres pool docs for every option.

MongoDB: every MongoClient already contains a connection pool (default maxPoolSize is 100). The mistake is creating a new client per request. The driver docs say to create one client and reuse it for all operations in a process.

Two of the three outage-level mistakes are behind us. The third is the puzzle from the top. But first, a mistake that makes everything above cheaper.

7. Recomputing the same thing on every request

Impact: Medium.

If every request recomputes or refetches the same data, you pay for it on every request. Cache in layers:

In-process for small, hot, read-mostly data such as config and reference tables.
A shared cache (for example Redis) when several instances need the same data.
HTTP caching (Cache-Control, ETag) for browsers and CDNs.

But the obvious in-process cache has a trap. Here is a feature-flag loader that looks correct:

let cache = null;

async function loadFlags() {
  if (cache) return cache;
  cache = JSON.parse(await fs.readFile('/etc/app/feature-flags.json', 'utf8'));
  return cache;
}

The value is stored only after the await. Every request that arrives while the first read is still running starts its own read. This is a cache stampede. Tested: 100 concurrent callers on a cold cache caused 100 file reads. Caching the promise instead caused 1.

Here is a small in-process cache that caches the promise, de-duplicates in-flight calls, evicts the least recently used entry, bounds its own size, and stops sharing a call that never finishes (pendingMs, which you should set above your function's own timeout from Mistake 8):

function cached(fn, ttlMs, { maxEntries = 1000, pendingMs = 30_000 } = {}) {
  const store = new Map(); // insertion order = least recently used first

  return (key) => {
    const now = Date.now();
    const hit = store.get(key);
    if (hit && hit.expires > now) {            // pending entries expire after pendingMs
      store.delete(key); store.set(key, hit);  // touch: move to most recently used
      return hit.promise;
    }

    const entry = { promise: null, expires: now + pendingMs };
    // new Promise(...) also turns a synchronous throw from fn into a rejection
    entry.promise = new Promise((resolve) => resolve(fn(key))).then((value) => {
      entry.expires = Date.now() + ttlMs;      // the TTL starts when the call finishes
      return value;
    });

    store.delete(key);
    store.set(key, entry);
    if (store.size > maxEntries) store.delete(store.keys().next().value); // evict LRU

    // never cache failures, and never delete a newer entry for the same key
    entry.promise.catch(() => { if (store.get(key) === entry) store.delete(key); });
    return entry.promise;
  };
}

const getUserCached = cached(loadUserFromDb, 5_000);

Tested:

100 concurrent calls for the same key triggered 1 underlying call.
After 10,000 distinct keys with maxEntries: 100, only the last 100 were still cached.
A hot key that is read again survives eviction; a cold key does not (LRU, not FIFO).
With a 600 ms call and a 400 ms TTL, a second call right after completion was a cache hit. If the TTL started when the call started, any call slower than its TTL would be expired the moment it finished.
A failed call is not cached, and a slow old failure does not delete a newer entry for the same key.
A call that never finishes is shared only for pendingMs. After that, the next caller starts a fresh call instead of waiting on a hung promise forever.

Caching has costs. Decide how stale data may be, how entries are invalidated, and how big the cache may grow. With several instances, in-process caches can disagree with each other.

Caching protects you from slow dependencies. The next mistake is about dependencies that never answer at all.

8. Outbound calls with no timeout, or a leaky one

Impact: Outage-level.

Here is the answer to the puzzle at the top. If you call clearTimeout as soon as fetch resolves, the timeout no longer covers reading the body:

// Timer is cleared when headers arrive, so a stalled body is NOT covered
const controller = new AbortController();
const timer = setTimeout(() => controller.abort(), 1000);
const res = await fetch(url, { signal: controller.signal });
clearTimeout(timer);
await res.text();

fetch() resolves when the headers arrive. The body is a separate stream, and it is still being read after your timer is gone.

Tested against a server that sends headers, then stalls the body for 3 seconds, with a 1-second timeout:

Pattern	Result
Manual timer, cleared right after `fetch`	finished after 3.06 s, no timeout applied
`AbortSignal.timeout(1000)`	aborted after 1.00 s with a `TimeoutError`
Manual timer, cleared in `finally` after the body	aborted after 1.00 s with an `AbortError`

The simplest fix is the built-in signal:

const res = await fetch('https://api.example.com/data', {
  signal: AbortSignal.timeout(5_000),
});
const data = await res.json();

If you prefer a manual AbortController, clear the timer only after the body is fully read:

async function fetchText(url, ms = 5_000) {
  const controller = new AbortController();
  const timer = setTimeout(() => controller.abort(), ms);
  try {
    const res = await fetch(url, { signal: controller.signal });
    return await res.text(); // the timer still covers reading the body
  } finally {
    clearTimeout(timer);
  }
}

Every outbound call means the database too. Mistake 6 showed connectionTimeoutMillis and statement_timeout. A query without a timeout is the same bug as a fetch without one.

Good to know: Node's built-in fetch (undici) defaults to 300 s for both the headers timeout and the body timeout, so a stuck request will not hang forever, but five minutes is far too long for most APIs. On the server side, Node 22's http.createServer() defaults to requestTimeout 300000 ms and headersTimeout 60000 ms. Review them for your traffic.

That was the last outage-level one. The remaining mistakes are about memory and CPU, starting with a very common way to waste both.

9. Loading a whole file into memory just to send it

Impact: Medium.

This looks harmless:

app.get('/download', async (req, res) => {
  const data = await fs.promises.readFile('./large-file.zip'); // whole file in memory, per request
  res.send(data);
});

readFile is asynchronous, so it does not block the event loop, but it loads the whole file into memory for every concurrent request. If you are just serving a file from disk, Express's res.sendFile() and res.download() already stream it. When you need your own logic, stream with pipeline() so errors are handled and streams are cleaned up:

const fs = require('node:fs');
const { pipeline } = require('node:stream/promises');

app.get('/download', async (req, res, next) => {
  try {
    await fs.promises.stat('./large-file.zip'); // 404 before streaming starts
    res.setHeader('Content-Type', 'application/zip');
    await pipeline(fs.createReadStream('./large-file.zip'), res);
  } catch (err) {
    if (res.headersSent) {
      // too late for a status code; pipeline already closed the response.
      // A client closing the tab mid-download is normal, so do not log it as an error.
      if (err.code !== 'ERR_STREAM_PREMATURE_CLOSE') console.error('stream failed:', err.code);
      return;
    }
    if (err.code === 'ENOENT') return res.status(404).end('not found');
    next(err);
  }
});

Tested with a plain Node http server:

A missing file returned 404, and a 5 MB file streamed completely (5,242,880 bytes).
When the client disconnected mid-download, pipeline() rejected with ERR_STREAM_PREMATURE_CLOSE after the headers had already been sent. That is why the catch checks res.headersSent before trying to send a status.
With fs.createReadStream(missing).pipe(res), the same missing file crashed the process with an unhandled ENOENT error event, because pipe() does not forward errors. pipeline() does.

Both pipe() and pipeline() handle backpressure for you. Checking the return value of write() is only needed when you call write() manually.

Streaming helps with big files. Big JSON has the same shape of problem, but it blocks the loop instead of filling memory.

10. Serializing big JSON on the event loop

Impact: Medium.

JSON.stringify() is synchronous. A very large response blocks the event loop for the whole time it serializes, which is Mistake 1 in disguise. Tested, median of several runs on a 1 vCPU test box:

Payload	Rows	`JSON.stringify` time
0.12 MB	1,000 rows, 4 fields	0.2 ms
1.27 MB	10,000 rows, 4 fields	2.9 ms
11.7 MB	10,000 rows, 30 fields	54.5 ms
13.0 MB	100,000 rows, 4 fields	43 ms
119.9 MB	100,000 rows, 30 fields	573 ms

That is roughly 3 to 5 ms of blocked event loop per MB on this machine. Your hardware will differ, so run the script on yours. A 120 MB response blocks the counter for over half a second, and every other request waits.

The first fixes are boring, and they work:

Return fewer fields (Mistake 3).
Paginate. Do not return 100,000 rows from a list endpoint.
For exports, stream the rows (for example as NDJSON) instead of building one giant array.
For rare, genuinely huge payloads, serialize in a worker thread.

Schema-based serializers such as fast-json-stringify (used by Fastify for response schemas) are often suggested. In my test, with one simple 4-field schema, it was slower than plain JSON.stringify at every size I tried, for example about 196 ms against 29 ms at 100,000 rows. That does not mean it is slow in general. It means one schema on one machine did not show a gain, so benchmark your own payloads before adopting it.

Bonus 1: AsyncLocalStorage is not free

AsyncLocalStorage is the standard way to carry request context (request IDs, tenants, tracing) without passing it through every function. Do not trust a client-supplied ID blindly: it ends up in your logs, so validate its shape and length.

const { AsyncLocalStorage } = require('node:async_hooks');
const crypto = require('node:crypto');

const requestContext = new AsyncLocalStorage();
const SAFE_ID = /^[A-Za-z0-9._-]{1,64}$/;

app.use((req, res, next) => {
  const incoming = req.headers['x-request-id'];
  const requestId = typeof incoming === 'string' && SAFE_ID.test(incoming)
    ? incoming
    : crypto.randomUUID();
  requestContext.run({ requestId }, next);
});

function log(message) {
  const ctx = requestContext.getStore();
  console.log(`[${ctx?.requestId}] ${message}`);
}

Tested: two concurrent requests each logged their own request ID, and a header containing spaces and a tab was replaced with a generated UUID.

On cost, benchmark conditions matter. Platformatic's benchmark (a simple HTTP server, 100 connections) measured AsyncLocalStorage at about 93% of baseline throughput on Node 24.4.1, roughly 7% overhead, and about 90% on Node 22.17.1, roughly 10%. I did not reproduce those numbers. A micro-benchmark that isolates the primitive will show a larger percentage. Measure it inside your own app before deciding.

Bonus 2: Async errors in Express 4 vs Express 5

In Express 5, a rejected promise from an async handler is passed to your error handler automatically (see the migration guide). Express 4 does not do that.

Tested on Node 22 with Express 4: an async handler that throws did not reach the error middleware. The client got a dropped connection, and the whole server process exited with code 1, because Node terminates the process on an unhandled promise rejection by default. If you installed an unhandledRejection listener, you would see the other symptom instead: a request that hangs until a timeout.

On Express 4, wrap your async handlers:

const asyncHandler = (fn) => (req, res, next) =>
  Promise.resolve(fn(req, res, next)).catch(next);

app.get('/users/:id', asyncHandler(async (req, res) => {
  const user = await getUser(req.params.id);
  if (!user) return res.status(404).json({ error: 'not_found' });
  res.json(user);
}));

Bonus 3: Framework benchmarks are not your benchmarks

Fastify's README says its headline throughput numbers come from a synthetic hello-world benchmark that measures framework overhead only. Those numbers say little about an endpoint that spends its time waiting on a database. Benchmark your own routes before switching frameworks.

Back to the puzzle

The 1-second timeout that waited 3.06 seconds was Mistake 8: the timer was cleared as soon as the headers arrived. The 20365311 "milliseconds" of lag was nanoseconds, about 20.3 ms, mostly the sampling interval. The cache that read a file 100 times was Mistake 7. And the /fast route that took 190 ms instead of 0.7 ms was one synchronous call in someone else's handler.

If you only have an hour in your own codebase, here is the order I would check them, based on my impact tags and not on any benchmark of your system:

Timeouts (8 and 6). Search for every fetch, HTTP client and database call. Does each one have a timeout that covers the whole response?
Pool math (6). Multiply instances by max and compare it with the database limit.
Event loop lag (1). Add the monitor from the start of this article and alert on max, not only p99.

Quick checklist

No synchronous I/O or heavy CPU work in request handlers. Monitor event loop max.
Batch child queries (no N+1), including the ones your ORM hides.
Select only the columns you return.
Parallelize only independent work.
Index what you filter, join and sort on, and verify with EXPLAIN ANALYZE.
One pool or client per process, with pool.on('error'), connectionTimeoutMillis, statement_timeout, and instances x max under the database limit.
Cache the promise, not just the value: TTL, in-flight de-duplication, LRU and a size cap, plus a plan for staleness and invalidation.
A timeout on every outbound call, including the body and including the database.
Stream large responses with pipeline().
Paginate big responses and benchmark serializers on your own data.

Do you still install uuid, qs or Moment out of habit? I checked 10 built-in browser APIs against MDN and tested the examples in Chrome, and noted when to keep the package.

Loknath Patel — Sun, 11 Oct 2026 03:56:30 +0000

Loknath Patel

Oct 11

10 Browser APIs That Can Replace npm Packages (and When They Can't)

#javascript #webdev #frontend #tutorial

8 min read

10 Browser APIs That Can Replace npm Packages (and When They Can't)

Loknath Patel — Sun, 11 Oct 2026 03:53:43 +0000

Many of us type npm install without thinking twice. But browsers keep adding built-in APIs that can handle tasks we once needed a package for. Sometimes, those packages stay in our projects simply because nobody stopped to check whether we still need them.

I checked these 10 APIs against MDN and the web-platform-dx web-features data. I also tested the key parts of each example in the Chrome DevTools console on desktop. For each API, you'll see what it can replace, how to use it, where it falls short, and its Baseline support status.

A quick note on Baseline: "Newly available" means a feature works in the latest versions of all major browsers. "Widely available" means it's been supported across those browsers for a while.

This isn't an argument against using dependencies. It's about knowing what's already available before adding another package to your project.

Check the platform first, then decide.

1. `structuredClone()` replaces lodash `cloneDeep`

Deep cloning JavaScript objects used to mean either reaching for JSON.parse(JSON.stringify(obj)) or installing lodash. The JSON approach has its own problems: Dates become strings, Maps and Sets lose their contents, and circular references cause errors.

For supported data types, structuredClone() offers a built-in alternative.

// Before
import cloneDeep from 'lodash/cloneDeep';
const copy = cloneDeep(user);

// After
const copy = structuredClone(user);

It can clone Dates, Maps, Sets, Blobs, ArrayBuffers, typed arrays, and circular references.

Caveat: Functions and DOM nodes can't be cloned. If a value can't be structured-cloned, the method throws a DataCloneError. Class instances also lose their custom prototype, so their prototype methods won't be preserved. If your code depends on those behaviors, keep cloneDeep.

Support: Baseline since March 2022 (Chrome 98, Firefox 94, Safari 15.4).

2. `crypto.randomUUID()` replaces `uuid`

The uuid package is useful, but if all you need is a random v4 UUID, the browser already has a method for that.

// Before
import { v4 as uuidv4 } from 'uuid';
const id = uuidv4();

// After
const id = crypto.randomUUID();
// e.g. '36b8f84d-df4e-4d49-b662-bcde71a8764f'

That's all you need for a standard v4 UUID.

Caveat: crypto.randomUUID() only generates v4 UUIDs and requires a secure context, such as HTTPS or localhost. If you need other versions, such as v1, v5, or v7, the uuid package may still be the better choice.

Support: Baseline since March 2022.

3. `fetch()` + `AbortSignal.timeout()` replaces axios for simple requests

For straightforward HTTP requests, the built-in fetch() API can do the job without axios. You can also use AbortSignal.timeout() to set a timeout without creating your own timer.

Here's what the difference looks like:

// Before
const { data } = await axios.get('/api/users', { timeout: 5000 });

// After
try {
  const res = await fetch('/api/users', {
    signal: AbortSignal.timeout(5000),
  });
  if (!res.ok) throw new Error(`HTTP ${res.status}`);
  const data = await res.json();
} catch (err) {
  if (err.name === 'TimeoutError') {
    // the request took longer than 5 seconds
  } else {
    throw err;
  }
}

There are a few differences worth knowing before switching.

Caveats:

fetch() doesn't reject its promise just because the server returns a 404 or 500 response. Check res.ok to handle HTTP errors yourself.
A timeout normally produces a TimeoutError. In Chrome 103 through 123, however, it produced an AbortError, so the TimeoutError check above won't match those versions.
If your application relies on axios interceptors, replacing axios with fetch() means implementing that behavior yourself.

Support: AbortSignal.timeout() is Baseline Newly available since April 2024 (Chrome 124, Firefox 100, Safari 16). The web-features data expects it to become Widely available on 18 October 2026.

4. `Intl.RelativeTimeFormat` replaces Moment for "time ago"

Moment is a large date library, and its own website describes it as a legacy project in maintenance mode. If you only need to display text such as "3 minutes ago", a browser API can handle the formatting.

The catch is that Intl.RelativeTimeFormat doesn't calculate the time difference or choose the right unit for you. You'll need a small helper for that.

const DIVISIONS = [
  { amount: 60, unit: 'second' },
  { amount: 60, unit: 'minute' },
  { amount: 24, unit: 'hour' },
  { amount: 7, unit: 'day' },
  { amount: 4.34524, unit: 'week' },
  { amount: 12, unit: 'month' },
  { amount: Infinity, unit: 'year' },
];

const rtf = new Intl.RelativeTimeFormat('en', { numeric: 'auto' });

function timeAgo(date) {
  let duration = (date - Date.now()) / 1000;
  for (const { amount, unit } of DIVISIONS) {
    if (Math.abs(duration) < amount) {
      return rtf.format(Math.round(duration), unit);
    }
    duration /= amount;
  }
}

timeAgo(new Date(Date.now() - 3 * 60 * 1000)); // '3 minutes ago'

Setting numeric: 'auto' gives you natural phrases such as "yesterday" instead of "1 day ago". The formatter also supports localization.

Caveat: This only handles relative-time formatting. If you need date parsing, date arithmetic, or time-zone handling, a dedicated library is still useful. Moment's own team recommends considering alternatives such as Luxon, Day.js, and date-fns.

Support: Baseline Widely available since March 2023.

5. `URLSearchParams` replaces `qs` and `query-string` for flat query strings

If you're building or reading simple URL query strings, you may not need a separate package.

// Before
import qs from 'qs';
const query = qs.stringify({ q: 'web apis', page: 2 });

// After
const params = new URLSearchParams({ q: 'web apis', page: 2 });
params.toString(); // 'q=web+apis&page=2'

const url = new URL('https://example.com/search?q=web+apis&page=2');
url.searchParams.get('q'); // 'web apis'

URLSearchParams handles encoding and decoding query parameters for you. You can also use it through a URL object's searchParams property to read or update an existing URL.

Caveat: It doesn't serialize nested objects or arrays in the same way as qs. If your API expects bracket notation or a particular nested-query format, keep the package that handles it.

Support: Baseline Widely available.

6. `IntersectionObserver` replaces scroll listeners for visibility checks

You don't always need to listen for every scroll event just to find out whether an element is visible. IntersectionObserver notifies you when an element enters or leaves a viewport, or another observation area, without requiring you to calculate its position on every scroll.

const observer = new IntersectionObserver((entries) => {
  entries.forEach((entry) => {
    if (entry.isIntersecting) {
      entry.target.classList.add('visible');
      observer.unobserve(entry.target);
    }
  });
}, { threshold: 0.2 });

document.querySelectorAll('.card').forEach((el) => observer.observe(el));

This example adds a visible class when a card intersects the viewport, then stops observing that card.

The threshold: 0.2 option controls when the callback runs, and entry.isIntersecting only tells you the element intersects the viewport. If you need "at least 20% visible", check entry.intersectionRatio >= 0.2 instead.

You can use the same API for infinite scrolling, scroll-triggered animations, lazy loading, and visibility analytics.

Caveat: If all you need is lazy-loaded images, the native loading="lazy" attribute on an <img> element may be enough. And if you're working with React or another framework, a wrapper library can still save you some setup.

Support: Baseline Widely available since September 2021 (Chrome 58, Firefox 55, Safari 12.1).

7. `ResizeObserver` replaces window `resize` listeners for element sizes

The window's resize event tells you when the window changes size. It doesn't tell you whenever a particular element changes size.

That's where ResizeObserver comes in. It watches an element directly, making it useful for charts, dashboards, and responsive components whose dimensions can change even when the window stays the same.

const ro = new ResizeObserver((entries) => {
  for (const entry of entries) {
    console.log(entry.contentRect.width);
  }
});

ro.observe(element);

Here, the observer logs the content width whenever the observed element's size changes.

Caveat: Be careful when changing an element's dimensions inside its own resize callback. That can trigger further observations and cause a "ResizeObserver loop" warning. Handle layout updates carefully to avoid repeated changes.

Support: Baseline Widely available since January 2023 (Chrome 64, Firefox 69, Safari 13.1).

8. Page Visibility API replaces small tab-visibility helper libraries

People often leave a tab open while working somewhere else. If your application keeps polling an API or running unnecessary tasks in the background, you may be wasting resources.

The Page Visibility API lets you respond when a document becomes hidden or visible.

const video = document.querySelector('video');

document.addEventListener('visibilitychange', () => {
  if (document.hidden) {
    video.pause();
    // also stop polling here
  } else {
    // the tab is visible again: resume or refresh data
  }
});

You can use this event to pause videos, stop polling, and reduce unnecessary CPU and battery use while the page isn't visible.

Caveat: A hidden tab doesn't necessarily mean the user has left your application. They might simply be looking at another tab. Use this API to manage background work, not to decide whether a session has ended.

Support: Long established and supported in all major browsers.

9. `BroadcastChannel` replaces the `localStorage` event trick for cross-tab messages

One way to synchronize browser tabs is to write data to localStorage and listen for the storage event. It works, but there's a built-in API designed specifically for messaging between contexts: BroadcastChannel.

// Tab 1
const channel = new BroadcastChannel('app-sync');
channel.postMessage({ type: 'theme-changed', theme: 'dark' });

// Tab 2
const channel = new BroadcastChannel('app-sync');
channel.onmessage = (event) => {
  console.log(event.data); // { type: 'theme-changed', theme: 'dark' }
};

Contexts using the same channel name can exchange messages. This works across tabs, windows, iframes, and workers, provided they share the relevant origin and storage partition.

One practical example is logging a user out across all open tabs when their session ends.

Caveat: Messages only reach contexts that share the same storage partition. For example, an iframe from another site embedded in your page can't communicate through this API with a regular tab of that other site, even if both have the same origin.

Support: Baseline since March 2022 (Chrome 54, Firefox 38, Safari 15.4).

10. Clipboard API replaces `document.execCommand('copy')` and clipboard.js for copying text

If your application needs a simple "Copy" button, the modern Clipboard API can handle it without a separate library.

copyButton.addEventListener('click', async () => {
  try {
    await navigator.clipboard.writeText('Copied!');
  } catch (err) {
    console.error('Copy failed:', err);
  }
});

The writeText() method copies the supplied string to the clipboard and returns a promise, so you can handle success or failure asynchronously.

Caveat: The API requires a secure context, such as HTTPS or localhost. Clipboard access is also subject to browser permission rules and user-activation requirements. Calling it from a click handler, as shown above, is a practical approach.

Support: writeText() is Baseline Widely available since March 2020.

Quick summary

You may be installing	Built-in alternative	Keep the package if
lodash `cloneDeep`	`structuredClone()`	You need to clone functions or preserve class prototypes
`uuid`	`crypto.randomUUID()`	You need UUID versions other than v4
axios	`fetch()` + `AbortSignal.timeout()`	You rely on interceptors
Moment (time ago)	`Intl.RelativeTimeFormat`	You need parsing, date math, or time-zone support
`qs`	`URLSearchParams`	You need nested objects or arrays
Scroll listeners	`IntersectionObserver`	You want a ready-made framework wrapper
Window resize hacks	`ResizeObserver`	You need to support very old browsers
Visibility helper libraries	Page Visibility API	You need richer idle or activity detection
`localStorage` event trick	`BroadcastChannel`	You need to synchronize across devices, which requires a server
clipboard.js	Clipboard API	You must support non-HTTPS pages

These APIs aren't always direct replacements for the packages listed here. But for many everyday tasks, the browser already provides what you need. Removing an unnecessary dependency also means one less package to maintain and audit.

What this doesn't cover

Older browsers: I've included Baseline support information, but if your project targets older browsers, check caniuse.com against your actual browser requirements.
Other browsers: I tested the examples in Chrome on desktop only. Test them in the browsers your project supports before shipping.
Performance and bundle size: I haven't benchmarked these alternatives. Check Bundlephobia or your own build output if you want actual bundle-size numbers.
Why these packages exist: qs supports nested query strings, axios offers interceptors, and date libraries handle parsing and time zones. The point isn't to remove every dependency. It's to understand what you're installing and why.

Which package have you replaced with a browser API recently? And did the native alternative cover everything you needed, or did you run into a limitation? Let me know in the comments.

7 Node.js Built-in Features That Can Replace npm Packages

Loknath Patel — Sat, 10 Oct 2026 11:04:08 +0000

Fewer dependencies, faster installs, and less third-party code to trust.

Every package you install is also a package you have to update, audit and trust, along with everything that package depends on. Many popular packages were created to fill gaps that Node.js had at the time. Some of those gaps have since closed.

This article covers seven built-in features that handle the most common jobs of well-known packages. For each one you get the package it replaces, a short working example, and the cases where the package is still the better choice.

Which Node.js version? The examples target Node.js 24 (LTS). Node.js 26 enters LTS in October 2026, and Node.js 22 stays in maintenance until April 30, 2027. When a feature differs on Node.js 22, I say so.

A quick note on stability. Node.js marks every API with a stability index. Stability 2 means stable. Stability 1 means experimental, which means it can change in a minor release. I only picked features that are stable on recent Node.js 24 releases (24.12 or later).

1. `fetch()` instead of `axios` or `node-fetch`

For years, making an HTTP request in Node.js meant installing a package. Now the same fetch() you use in the browser is available as a global:

const res = await fetch('https://api.github.com/repos/nodejs/node', {
  headers: { Accept: 'application/vnd.github+json' },
  signal: AbortSignal.timeout(5000), // give up after 5 seconds
});

if (!res.ok) {
  throw new Error(`Request failed with status ${res.status}`);
}

const repo = await res.json();
console.log(repo.full_name, repo.stargazers_count);

Where the package still wins: fetch() does not throw on a 404 or 500 response, so you have to check res.ok yourself, as in the example above. There is also no built-in equivalent of axios interceptors or automatic retries. If you attach an auth header to every request in one place, a small wrapper function or axios is still convenient.

Version note: stable since Node.js 21.0.0.

2. `node:test` instead of Jest or Mocha

Node.js ships with a test runner and an assertion library, so your first test needs no config file and no install.

Suppose you have a small helper:

// slugify.js
export function slugify(text) {
  return text
    .toLowerCase()
    .trim()
    .replace(/[^a-z0-9]+/g, '-')
    .replace(/^-+|-+$/g, '');
}

And a test file next to it:

// slugify.test.js
import { describe, it } from 'node:test';
import assert from 'node:assert/strict';
import { slugify } from './slugify.js';

describe('slugify', () => {
  it('lowercases text and joins words with dashes', () => {
    assert.equal(slugify('Hello Node World'), 'hello-node-world');
  });

  it('removes leading and trailing separators', () => {
    assert.equal(slugify('  --Hi!--  '), 'hi');
  });
});

Run it with:

node --test

Node.js finds files named like *.test.js on its own. (These examples use ES modules, so set "type": "module" in your package.json or use the .mjs extension.)

Where the package still wins: code coverage is enabled with the --experimental-test-coverage flag, and mocking whole modules with mock.module() is still experimental (Stability 1.0) and needs the --experimental-test-module-mocks flag. If your test suite depends heavily on module mocking, keep Jest for now.

Version note: stable since Node.js 20.0.0.

3. `node --watch` instead of `nodemon`

Restarting your server every time you save a file is one of the oldest reasons to install nodemon. Node.js now does this with one flag.

// server.js
import { createServer } from 'node:http';

createServer((req, res) => {
  res.end('Hello from Node.js');
}).listen(3000);

{
  "scripts": {
    "dev": "node --watch server.js"
  }
}

Run npm run dev, edit server.js, and the process restarts automatically.

Where the package still wins: by default, Node.js watches the entry file and the modules it imports. A JSON file, a template or a .env file that you read at runtime will not trigger a restart. The --watch-path flag lets you choose which paths are watched, but it replaces the default module watching instead of adding to it. The official docs also list --watch-path as supported only on macOS and Windows, so test it on your platform. --watch also needs a file to run, so it cannot be combined with --run. nodemon lets you configure extensions, ignore lists and delays.

Version note: stable since Node.js 22.0.0 (and 20.13.0).

4. `--env-file` instead of `dotenv`

Loading a .env file used to be the job of dotenv. Node.js can read it before your code even starts.

# .env
PORT=3000
API_BASE_URL=https://api.example.com

// app.js
console.log(`Starting on port ${process.env.PORT}`);
console.log(`Calling ${process.env.API_BASE_URL}`);

node --env-file=.env app.js

If you prefer to load it from code, which is closer to how dotenv works, call process.loadEnvFile():

process.loadEnvFile(); // reads ./.env by default

Remember to add .env to your .gitignore.

Where the package still wins: Node.js does not expand variables inside values, so URL=http://${HOST}:3000 stays a literal string. --env-file throws an error if the file is missing (use --env-file-if-exists for optional files). And a variable that is already set in your shell takes priority over the file.

Version note: stable since Node.js 24.10.0 (and 22.21.0). Before those releases, the flag and the function were still marked experimental.

5. `util.parseArgs()` instead of `minimist`, `yargs` or `commander`

Small scripts often need two or three command line flags. You do not need a package for that.

// cli.js
import { parseArgs } from 'node:util';

const { values, positionals } = parseArgs({
  options: {
    port: { type: 'string', short: 'p', default: '3000' },
    verbose: { type: 'boolean', short: 'v', default: false },
  },
  allowPositionals: true,
});

console.log(values, positionals);

Running node cli.js --port 8080 -v build prints:

[Object: null prototype] { port: '8080', verbose: true } [ 'build' ]

(values is an object without a prototype, which is why Node.js prints that prefix.)

Where the package still wins: option types can only be 'string' or 'boolean', so you convert the port with Number(values.port) yourself. parseArgs only parses: it does not generate --help output or handle subcommands for you. By default an unknown option throws an error, unless you set strict: false. For a CLI that other people will install, commander is still worth it. For your own script with three flags, parseArgs is enough.

Version note: stable since Node.js 20.0.0.

6. TypeScript type stripping instead of `ts-node` or `tsx`

You can now run a .ts file directly. Node.js removes the type annotations and runs the JavaScript that is left.

// tasks.ts
type Task = { id: number; title: string; done: boolean };

const tasks: Task[] = [
  { id: 1, title: 'Write the article', done: false },
  { id: 2, title: 'Publish on dev.to', done: false },
];

function pending(list: Task[]): Task[] {
  return list.filter((task) => !task.done);
}

console.log(pending(tasks));

node tasks.ts

One important point: Node.js only strips the types, it does not check them. Type checking stays with the TypeScript compiler, so keep running tsc --noEmit in your editor or CI.

Where the package still wins: only syntax that can simply be erased is supported. Features that need real JavaScript to be generated, such as enum, namespace with runtime code and constructor parameter properties, fail with an error. Import specifiers need the file extension (./lib.ts, not ./lib), tsconfig.json settings such as paths are ignored, and .tsx files are not supported. The Node.js docs recommend TypeScript 5.8 or newer, and setting erasableSyntaxOnly: true in tsconfig.json makes tsc warn you about unsupported syntax before Node.js does.

Version note: stable in Node.js 24.12.0 and 25.2.0, and enabled by default since 22.18.0 (and 23.6.0).

7. `fs.glob()` instead of `glob`

Finding files by pattern used to mean installing glob or fast-glob. Now it lives in node:fs.

import { glob } from 'node:fs/promises';

const markdownFiles = await Array.fromAsync(
  glob('content/**/*.md', { exclude: ['content/drafts/**'] })
);

console.log(markdownFiles);

There is also a synchronous globSync() in node:fs that returns an array, and brace patterns like **/*.{md,mdx} work.

Where the package still wins: the promise version returns an async iterator, which is why the example wraps it in Array.fromAsync(). The option for skipping files is named exclude, not ignore, and negation patterns such as !foo.js are not supported in it. In Node.js 24, the documented options are cwd, exclude, withFileTypes and, from 24.16.0, followSymlinks. If you rely on advanced features of the glob package, check that they exist here before switching. For typical build scripts, the built-in is enough.

Version note: stable since Node.js 24.0.0 and 22.17.0. Earlier 22.x releases still mark it experimental. Passing an array of patterns to exclude needs Node.js 22.14.0 or newer (or 23.7.0+); on older versions, pass a function instead.

Quick reference

Package	Built-in replacement	Stable since
`axios`, `node-fetch`	`fetch()`	21.0.0
`jest`, `mocha`	`node:test` + `node:assert`	20.0.0
`nodemon`	`node --watch`	22.0.0 (20.13.0)
`dotenv`	`--env-file`, `process.loadEnvFile()`	24.10.0 (22.21.0)
`minimist`, `yargs`, `commander`	`util.parseArgs()`	20.0.0
`ts-node`, `tsx`	TypeScript type stripping	24.12.0 / 25.2.0
`glob`	`fs.glob()`	24.0.0 (22.17.0)

Final thoughts

Removing a dependency is not about purity. Each built-in above covers the common case and then stops, and the old package is still useful for whatever the built-in leaves out. Before you remove a package, read the "where the package still wins" part and ask whether you actually hit that case. In many projects you will not, and the dependency goes away together with its updates and its install time.

One last tip: pin the runtime so nobody has to guess which features are available.

{
  "engines": {
    "node": ">=24.12"
  }
}

A few more built-ins worth exploring in the Node.js docs: util.styleText() (a chalk alternative), crypto.randomUUID() (instead of uuid), the WebSocket global (the client side of ws), and the recursive option of fs.rm() and fs.mkdir() (instead of rimraf and mkdirp).

Which dependency did you remove from your last project? Tell me in the comments.

DEV Community: Loknath Patel

Why Your Node.js API Is Slow in Production: 10 Mistakes That Pass Code Review

The golden rule: measure first

The 20365311 gotcha

1. One slow function freezes every request

Fixes

2. The N+1 query: one endpoint, one query per row

3. Sending columns nobody reads

4. Serial await that should run in parallel

5. The query that was fine at 100 rows

6. A new database connection per request

The production math nobody does in dev

7. Recomputing the same thing on every request

8. Outbound calls with no timeout, or a leaky one

9. Loading a whole file into memory just to send it

10. Serializing big JSON on the event loop

Bonus 1: AsyncLocalStorage is not free

Bonus 2: Async errors in Express 4 vs Express 5

Bonus 3: Framework benchmarks are not your benchmarks

Back to the puzzle

Quick checklist

Do you still install uuid, qs or Moment out of habit? I checked 10 built-in browser APIs against MDN and tested the examples in Chrome, and noted when to keep the package.

10 Browser APIs That Can Replace npm Packages (and When They Can't)

10 Browser APIs That Can Replace npm Packages (and When They Can't)

1. structuredClone() replaces lodash cloneDeep

2. crypto.randomUUID() replaces uuid

3. fetch() + AbortSignal.timeout() replaces axios for simple requests

4. Intl.RelativeTimeFormat replaces Moment for "time ago"

5. URLSearchParams replaces qs and query-string for flat query strings

6. IntersectionObserver replaces scroll listeners for visibility checks

7. ResizeObserver replaces window resize listeners for element sizes

8. Page Visibility API replaces small tab-visibility helper libraries

9. BroadcastChannel replaces the localStorage event trick for cross-tab messages

10. Clipboard API replaces document.execCommand('copy') and clipboard.js for copying text

Quick summary

What this doesn't cover

7 Node.js Built-in Features That Can Replace npm Packages

1. fetch() instead of axios or node-fetch

2. node:test instead of Jest or Mocha

3. node --watch instead of nodemon

4. --env-file instead of dotenv

5. util.parseArgs() instead of minimist, yargs or commander

6. TypeScript type stripping instead of ts-node or tsx

7. fs.glob() instead of glob

Quick reference

Final thoughts

1. `structuredClone()` replaces lodash `cloneDeep`

2. `crypto.randomUUID()` replaces `uuid`

3. `fetch()` + `AbortSignal.timeout()` replaces axios for simple requests

4. `Intl.RelativeTimeFormat` replaces Moment for "time ago"

5. `URLSearchParams` replaces `qs` and `query-string` for flat query strings

6. `IntersectionObserver` replaces scroll listeners for visibility checks

7. `ResizeObserver` replaces window `resize` listeners for element sizes

9. `BroadcastChannel` replaces the `localStorage` event trick for cross-tab messages

10. Clipboard API replaces `document.execCommand('copy')` and clipboard.js for copying text

1. `fetch()` instead of `axios` or `node-fetch`

2. `node:test` instead of Jest or Mocha

3. `node --watch` instead of `nodemon`

4. `--env-file` instead of `dotenv`

5. `util.parseArgs()` instead of `minimist`, `yargs` or `commander`

6. TypeScript type stripping instead of `ts-node` or `tsx`

7. `fs.glob()` instead of `glob`