Response time optimization in Node.js - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is response time optimization in Node.js?

Response time optimization means making your Node.js app respond faster to user requests by reducing delays and improving efficiency.

beginner

Why is non-blocking I/O important for response time in Node.js?

Non-blocking I/O lets Node.js handle many tasks at once without waiting, so it can respond to users faster and avoid delays.

intermediate

How does caching improve response time?

Caching stores data temporarily so the app can reuse it quickly instead of fetching or calculating it again, which speeds up responses.

intermediate

What role does clustering play in Node.js response time optimization?

Clustering runs multiple Node.js processes to use all CPU cores, helping the app handle more requests at the same time and respond faster.

beginner

How can minimizing synchronous code improve response time?

Synchronous code blocks the app from doing other work until it finishes, so minimizing it helps Node.js stay responsive and serve users faster.

Which Node.js feature helps handle many requests without waiting for each to finish?

A Non-blocking I/O

B Synchronous functions

C Global variables

D Blocking calls

Non-blocking I/O allows Node.js to process multiple requests at once without waiting, improving response time.

What does caching do to improve response time?

A Stores data temporarily for quick reuse

B Deletes old data immediately

C Slows down data retrieval

D Runs code synchronously

Caching stores data temporarily so it can be reused quickly, reducing the time to respond.

How does clustering help Node.js apps?

A Disables caching

B Makes code synchronous

C Blocks requests until ready

D Runs multiple processes to use all CPU cores

Clustering runs multiple Node.js processes to use all CPU cores, improving the ability to handle many requests.

Which practice can slow down Node.js response time?

A Using non-blocking I/O

B Using synchronous code heavily

C Implementing caching

D Using clustering

Heavy use of synchronous code blocks the event loop, slowing down response time.

What is a simple way to check your Node.js app's response time?

A Only check server logs

B Ignore performance metrics

C Use browser DevTools network tab

D Restart the server frequently

Browser DevTools network tab shows how long requests take, helping you measure response time.

Explain how non-blocking I/O and clustering together help improve Node.js response time.

Think about how Node.js handles tasks and uses CPU power.

Describe three practical ways to optimize response time in a Node.js application.

Focus on code style, data handling, and server setup.

Practice

1. Which of the following is a common technique to improve response time in a Node.js application?

easy

A. Writing all code synchronously to keep it simple

B. Using only synchronous file system calls

C. Increasing the number of console.log statements

D. Using asynchronous functions to avoid blocking the event loop

Solution

1. Step 1: Understand Node.js event loop behavior

   Node.js uses an event loop that runs best when tasks are asynchronous, avoiding blocking operations.

2. Step 2: Identify the impact of async functions

   Using asynchronous functions allows Node.js to handle other requests while waiting, improving response time.

3. Final Answer:

   Using asynchronous functions to avoid blocking the event loop -> Option D

4. Quick Check:

   Async = faster response [OK]

Hint: Async code keeps Node.js responsive and fast [OK]

Common Mistakes:

• Thinking synchronous code is faster
• Ignoring event loop blocking
• Believing console.log improves speed

2. Which syntax correctly uses caching middleware in an Express.js app to improve response time?

easy

A. app.use(cacheMiddleware);

B. app.cacheMiddleware();

C. cacheMiddleware(app);

D. app.cache.useMiddleware();

Solution

1. Step 1: Recall Express middleware usage

   Middleware is added using app.use(middlewareFunction) to apply it to requests.

2. Step 2: Match correct syntax

   Only app.use(cacheMiddleware); correctly applies the middleware function.

3. Final Answer:

   app.use(cacheMiddleware); -> Option A

4. Quick Check:

   Middleware added with app.use() [OK]

Hint: Use app.use() to add middleware in Express [OK]

Common Mistakes:

• Calling middleware as a method on app
• Passing app as argument to middleware
• Using incorrect method names

3. What will be the output response time behavior of this Node.js code snippet?

const express = require('express');
const app = express();

app.get('/data', async (req, res) => {
  const data = await fetchDataFromDb();
  res.send(data);
});

function fetchDataFromDb() {
  return new Promise(resolve => setTimeout(() => resolve('DB Data'), 2000));
}

app.listen(3000);

medium

A. Responds after 2 seconds with 'DB Data'

B. Responds immediately with 'DB Data'

C. Responds immediately with an empty response

D. Throws an error due to missing callback

Solution

1. Step 1: Analyze fetchDataFromDb function

   This function returns a promise that resolves after 2 seconds with 'DB Data'.

2. Step 2: Understand async/await in route handler

   The route waits for fetchDataFromDb to finish before sending response, causing 2 seconds delay.

3. Final Answer:

   Responds after 2 seconds with 'DB Data' -> Option A

4. Quick Check:

   Await delays response by 2 seconds [OK]

Hint: Await pauses response until promise resolves [OK]

Common Mistakes:

• Assuming immediate response despite await
• Confusing async with synchronous code
• Expecting error without callback in async

4. Identify the bug in this Node.js code that aims to optimize response time using caching:

const cache = {};
app.get('/user/:id', (req, res) => {
  if (cache[req.params.id]) {
    res.send(cache[req.params.id]);
    return;
  }
  const userData = getUserFromDb(req.params.id);
  cache[req.params.id] = userData;
  res.send(userData);
});

medium

A. Cache is cleared after every request

B. res.send is called twice causing error

C. getUserFromDb is asynchronous but used synchronously

D. Cache keys are not strings

Solution

1. Step 1: Check res.send calls in both branches

   If cache hit, res.send is called, but code continues and calls res.send again after fetching data.

2. Step 2: Understand Express response behavior

   Calling res.send twice causes an error because response is already sent.

3. Final Answer:

   res.send is called twice causing error -> Option B

4. Quick Check:

   Only one res.send per request allowed [OK]

Hint: Return after sending cached response to avoid double send [OK]

Common Mistakes:

• Ignoring multiple res.send calls
• Assuming synchronous DB call is fine
• Not returning after cache hit

5. You want to optimize response time by streaming a large file in Node.js instead of loading it fully into memory. Which code snippet correctly implements this using Express?

hard

A. app.get('/file', (req, res) => { const fs = require('fs'); res.sendFile(fs.readFileSync('large.txt')); });

B. app.get('/file', (req, res) => { const data = fs.readFileSync('large.txt'); res.send(data); });

C. app.get('/file', (req, res) => { const fs = require('fs'); const stream = fs.createReadStream('large.txt'); stream.pipe(res); });

D. app.get('/file', (req, res) => { const data = fs.readFile('large.txt', (err, data) => { res.send(data); }); });

Solution

1. Step 1: Understand streaming vs full read

   Streaming sends file data in chunks, reducing memory use and improving response time for large files.

2. Step 2: Identify correct streaming code

   Using fs.createReadStream and piping to res streams data efficiently; other options load full file or use callbacks.

3. Final Answer:

   app.get('/file', (req, res) => { const fs = require('fs'); const stream = fs.createReadStream('large.txt'); stream.pipe(res); }); -> Option C

4. Quick Check:

   Stream large files with createReadStream + pipe [OK]

Hint: Use createReadStream and pipe to stream files [OK]

Common Mistakes:

• Using readFileSync blocks event loop
• Using readFile loads entire file before response
• Assuming sendFile streams automatically