⚡ Performance Optimization

The Optimization Loop

Performance optimization is not a burst of cleverness — it's a disciplined cycle. You measure to find the truth, change exactly one thing, and measure again to prove it helped. Skip the measuring and you'll pour hours into "optimizations" that speed up code no user ever waits on.

There's an old saying worth burning into memory: premature optimization is the root of all evil. It doesn't mean "never optimize." It means don't optimize before you've measured, because your intuition about what's slow is usually wrong. The bottleneck is almost never the fancy algorithm you were proud of — it's the innocent-looking line that runs a database query inside a loop.

Measure Before You Touch

Node.js ships with the same performance API browsers have. Wrap a suspicious section in a mark-and-measure and let the numbers tell you where the time goes.

// Node and browsers both expose performance.mark / performance.measure
performance.mark('handler-start');

const products = await getProducts();      // suspect 1: the query
const enriched = await addReviews(products); // suspect 2: enrichment

performance.mark('handler-end');
performance.measure('handler', 'handler-start', 'handler-end');

const [entry] = performance.getEntriesByName('handler');
console.log(`Handler took ${entry.duration.toFixed(1)} ms`);
// Handler took 812.4 ms   ← now measure each suspect separately to localize it

For a quick timing during development, the console timers are even less ceremony:

console.time('db-query');
const rows = await db.query('SELECT * FROM orders WHERE user_id = $1', [userId]);
console.timeEnd('db-query');
// db-query: 640.187ms   ← the query is the problem, not the JS around it

Bottleneck: N+1 Queries

This is the number-one performance bug in web backends, and it hides in the most natural-looking code. You fetch a list of N things, then loop over them firing one more query per item — 1 query to get the list, then N queries for the details. Ten posts becomes 11 queries; a thousand posts becomes 1001.

// ❌ N+1: one extra query for every post (1 + N round trips to the DB)
const posts = await db.query('SELECT * FROM posts LIMIT 100');
for (const post of posts) {
  post.author = await db.query(
    'SELECT * FROM users WHERE id = $1', [post.author_id]
  ); // fires 100 times!
}

// ✅ Batched: fetch every needed author in ONE query, then stitch in memory
const posts = await db.query('SELECT * FROM posts LIMIT 100');
const authorIds = [...new Set(posts.map(p => p.author_id))];
const authors = await db.query(
  'SELECT * FROM users WHERE id = ANY($1)', [authorIds]
); // 1 query, no matter how many posts
const byId = new Map(authors.map(a => [a.id, a]));
for (const post of posts) post.author = byId.get(post.author_id);

Bottleneck: Missing Indexes

A database without an index on a filtered column is a library with no catalog: to find one book, a librarian walks every shelf. That's a full table scan, and it gets linearly slower as the table grows. An index is the catalog — it turns "check every row" into "jump straight to the answer."

-- This query scans every row unless email is indexed
SELECT * FROM users WHERE email = 'ada@example.com';

-- Ask the database what it's actually doing
EXPLAIN ANALYZE SELECT * FROM users WHERE email = 'ada@example.com';
-- "Seq Scan on users ... rows=2000000"  ← reading two million rows!

-- Add the index once; the query planner uses it automatically forever after
CREATE INDEX idx_users_email ON users (email);
-- Now: "Index Scan using idx_users_email"  ← microseconds, not seconds

Why it matters: the columns to index are the ones you filter (WHERE), join (ON), and sort (ORDER BY) on. EXPLAIN ANALYZE is your x-ray — a "Seq Scan" over a large table on a filtered column is a red flag pointing straight at a missing index.

Bottleneck: No Caching

The fastest query is the one you never run. If data is expensive to compute and doesn't change every second, cache the result and serve it from memory. A cache is a sticky note on your monitor: instead of walking to the filing cabinet every time, you glance at the note.

// A tiny in-memory cache with a time-to-live (TTL).
// For multi-server production, use Redis instead of a local Map.
const cache = new Map();
const TTL_MS = 60_000; // 60 seconds

async function getPopularProducts() {
  const hit = cache.get('popular');
  if (hit && Date.now() - hit.at < TTL_MS) {
    return hit.value;                 // cache hit — no DB work at all
  }
  const value = await db.query(       // cache miss — do the expensive work once
    'SELECT * FROM products ORDER BY sales DESC LIMIT 20'
  );
  cache.set('popular', { value, at: Date.now() });
  return value;
}

Bottleneck: A Blocked Event Loop

Node.js runs your JavaScript on a single thread. That thread — the event loop — juggles every request. If one request runs a long, synchronous computation, every other request waits behind it. One slow CPU task can freeze the whole server.

// ❌ Blocks the event loop: while this runs, NO other request is served
app.get('/report', (req, res) => {
  let total = 0;
  for (let i = 0; i < 5_000_000_000; i++) total += i; // synchronous, seconds long
  res.json({ total });
});

// ✅ Offload CPU-heavy work to a Worker thread; the event loop stays free
import { Worker } from 'node:worker_threads';
app.get('/report', (req, res) => {
  const worker = new Worker('./report-worker.js');
  worker.postMessage(req.query);
  worker.once('message', (result) => res.json(result)); // main thread never blocked
});

Why it matters: most Node work is I/O (database, network, files), which is already asynchronous and non-blocking — that's Node's superpower. The danger is CPU-bound work: parsing huge payloads, image processing, cryptography, giant loops. Keep those off the main thread (worker threads, a queue, or a separate service), and never reach for the synchronous versions of APIs (fs.readFileSync, crypto.pbkdf2Sync) in a request handler.

Bottleneck: Unbounded Queries

An endpoint that returns "all the orders" is a time bomb. It's fast with 50 rows in development and catastrophic with 5 million in production — slow query, huge JSON payload, and a memory spike that can crash the process. The fix is pagination: never return an unbounded set.

// ❌ Returns the entire table — grows unbounded with your data
app.get('/orders', async (req, res) => {
  const orders = await db.query('SELECT * FROM orders'); // could be millions
  res.json(orders);
});

// ✅ Page the results: bounded work, bounded payload, predictable latency
app.get('/orders', async (req, res) => {
  const limit = Math.min(Number(req.query.limit) || 20, 100); // cap it
  const page = Math.max(Number(req.query.page) || 1, 1);
  const offset = (page - 1) * limit;
  const orders = await db.query(
    'SELECT * FROM orders ORDER BY created_at DESC LIMIT $1 OFFSET $2',
    [limit, offset]
  );
  res.json({ page, limit, orders });
});

Practice & Quiz

const products = await db.query('SELECT * FROM products LIMIT 200');
for (const p of products) {
  p.category = await db.query(
    'SELECT * FROM categories WHERE id = $1', [p.category_id]
  );
}

const products = await db.query('SELECT * FROM products LIMIT 200');
const ids = [...new Set(products.map(p => p.category_id))];
const categories = await db.query(
  'SELECT * FROM categories WHERE id = ANY($1)', [ids]
);
const byId = new Map(categories.map(c => [c.id, c]));
for (const p of products) p.category = byId.get(p.category_id);
// 2 queries total instead of 201

Best Practices & Pitfalls

✅ Do

• Measure first, change one thing, then re-measure to prove the win
• Attack the biggest slice of the time budget, not the easiest-looking code
• Use EXPLAIN ANALYZE to see what the database is really doing
• Cache expensive, slowly-changing data — and set a clear TTL or invalidation rule
• Paginate every list endpoint and cap the page size
• Lock in gains with a performance budget and CI thresholds so they can't silently regress

❌ Don't

• Optimize on a hunch before profiling — you'll speed up code no one waits on
• Run queries inside loops (the N+1 trap)
• Do CPU-bound work synchronously in a request handler
• Return unbounded result sets
• Add indexes to every column — writes and storage pay the price

Summary

📚 Additional Resources

• MDN — Web Performance guide
• MDN — The Performance API
• Node.js — Don't block the event loop
• web.dev — Core Web Vitals

🚀 What's Next?

You can now measure, diagnose, and fix the bottlenecks that load tests expose. That completes the performance-testing arc. Next we zoom out to the pipeline that runs all of this automatically on every commit: CI/CD Concepts — where your tests, load thresholds, and performance budgets become gates that protect production.