Discover how a tiny piece of middleware can reveal your server's hidden speed secrets!
Why Response time tracking middleware in Express? - Purpose & Use Cases
Imagine you have a busy web server and you want to know how long each request takes to respond. You try adding timers around every route handler manually.
Manually adding timers everywhere is tedious, easy to forget, and leads to inconsistent or missing data. It clutters your code and slows development.
Response time tracking middleware automatically measures how long each request takes, without changing your route code. It runs before and after every request, giving you consistent timing data effortlessly.
const start = Date.now(); app.get('/data', (req, res) => { // handle request res.send('ok'); console.log('Response time:', Date.now() - start, 'ms'); });
app.use((req, res, next) => {
const start = Date.now();
res.on('finish', () => {
console.log('Response time:', Date.now() - start, 'ms');
});
next();
});You can easily monitor and improve your server's speed by tracking response times for all requests automatically.
A website owner notices some pages load slowly. Using response time middleware, they find which routes are slow and optimize them, improving user experience.
Manual timing is error-prone and repetitive.
Middleware tracks response time automatically for all requests.
This helps monitor and improve server performance easily.
Practice
Solution
Step 1: Understand middleware role
Response time tracking middleware measures the duration of requests.Step 2: Identify main purpose
It tracks how long the server takes to respond to each request.Final Answer:
To measure how long each HTTP request takes to complete -> Option AQuick Check:
Response time tracking = measuring request duration [OK]
- Confusing response time tracking with error handling
- Thinking it modifies request data
- Assuming it serves static files
Solution
Step 1: Identify time measurement method
Date.now() returns the current timestamp in milliseconds, suitable for timing.Step 2: Check other options
new Date().toString() returns a string, not a number; process.hrtime() returns a tuple, more complex; setTimeout() is for delays, not time capture.Final Answer:
const start = Date.now(); -> Option BQuick Check:
Use Date.now() for simple timestamps [OK]
- Using new Date().toString() which returns a string
- Confusing process.hrtime() with Date.now()
- Using setTimeout() incorrectly for timing
app.use((req, res, next) => {
const start = Date.now();
res.on('finish', () => {
const duration = Date.now() - start;
console.log(`Request took ${duration}ms`);
});
next();
});Solution
Step 1: Understand event listener on 'finish'
The 'finish' event triggers after the response is sent, so timing is complete.Step 2: Calculate duration and log
Duration is current time minus start time, logged once per request.Final Answer:
Logs the time taken for each request after response finishes -> Option CQuick Check:
res.on('finish') logs after response ends [OK]
- Thinking it logs before request processing
- Assuming multiple logs during request
- Forgetting to call next() to continue middleware chain
app.use((req, res, next) => {
const start = Date.now();
res.on('finish', () => {
const duration = Date.now() - start;
console.log(`Request took ${duration}ms`);
});
});Solution
Step 1: Check middleware flow
Middleware must call next() to pass control; missing here causes request to hang.Step 2: Validate event and logging
res.on('finish') is correct event; Date.now() is valid; logging is allowed.Final Answer:
Missing call to next(), so request hangs -> Option DQuick Check:
Always call next() in middleware [OK]
- Forgetting next() call
- Confusing 'finish' with 'end' event
- Thinking Date.now() causes errors
Request took ${duration}ms. Which middleware code correctly does this?Solution
Step 1: Understand logging timing
To capture the full request processing time, record the start time, call next(), and log the duration in the 'finish' event handler which fires after the response is sent.Step 2: Analyze incorrect approaches
Logging right after starting the timer yields nearly 0ms because handlers haven't executed yet. The 'close' event relates to connection closure, not response completion, and may not fire reliably for timing.Final Answer:
Uses res.on('finish') to log accurate request duration -> Option AQuick Check:
res.on('finish') ensures complete request timing [OK]
- Logging before calling next() (duration ~0ms)
- Using 'close' event instead of 'finish'
- Not waiting for response to finish
Ready to prove it?
Pass the test and this pattern moves unknown
