res.send(data);<\/code><\/p>The async version lets Node handle the file read outside the main JavaScript thread. While the file is being read, the event loop keeps handling other requests.<\/p>
Use async\/await<\/code> and promise-based Node.js APIs (like fs.promises<\/code>) as your default.<\/p>Modern database drivers like pg<\/code>, mysql2<\/code>, and Mongoose work the same way, handling I\/O asynchronously, so waiting for the database usually won’t block the event loop. Large result sets and heavy response processing can still cause blocking, though, so keep queries and payloads small.<\/p>Async code solves I\/O waiting, but not CPU-bound work. If a function spends 500ms crunching numbers, it still blocks the main thread even with await<\/code> in front of it. Worker threads handle that by running the computation on a separate thread.<\/p>If your app uses synchronous calls inside request handlers, switching them to async versions can be one of the fastest wins.<\/p>
2. Optimize Express middleware and API responses<\/h2> Trimming your Express setup and API payloads cuts response time by removing work the server shouldn’t do on every request.<\/p>
Middleware applied with app.use()<\/code> runs on every matching request. If authentication, logging, body parsing, CORS, rate limiting, and compression all run globally, some routes may do work they don’t need. Move middleware to specific routes where possible:<\/p>\/\/ Instead of applying auth to every route<\/code><\/p>app.use(authMiddleware);<\/code><\/p><\/p>
\/\/ Apply it only where needed<\/code><\/p>app.get('\/dashboard', authMiddleware, dashboardHandler);<\/code><\/p>app.get('\/public-page', publicHandler);<\/code><\/p>Now public routes skip authentication work entirely.<\/p>
Next, look at what your API accepts and returns. Set a limit on incoming JSON payload size:<\/p>
app.use(express.json({ limit: '100kb' }));<\/code><\/p>Adjust the limit based on what your API actually accepts. On the response side, return only the fields the client needs. Sending full database records when the frontend uses three fields wastes processing time and bandwidth.<\/p>
Paginate large responses so endpoints can’t return thousands of records without a limit.<\/p>
If you serve static files through Express, move them to a CDN or reverse proxy like Nginx. If a CDN or reverse proxy already handles compression, skip compression()<\/code> in Express. Compress once, at one layer.<\/p>Even with all of this trimmed, response time depends on the full request chain: middleware, validation, database queries, external APIs, data formatting, and network transfer. Profile slow routes to find which part adds the most delay.<\/p>
How can you reduce Node.js API response time?<\/h3> You reduce API response time by fixing the slowest part of each route. The highest-impact fixes are:<\/p>
\nRemove unnecessary middleware from the route<\/li>\n\n\n\n Return only required fields<\/li>\n\n\n\n Paginate large results<\/li>\n\n\n\n Cache repeated responses<\/li>\n\n\n\n Optimize database queries<\/li>\n\n\n\n Set timeouts for slow external requests<\/li>\n<\/ul>If a route waits five seconds for an external API, set a timeout and return a fallback when possible. Users get a controlled response instead of waiting until the request fails.<\/p>
3. Cache frequently requested data<\/h2> Caching reduces repeated database queries, external API calls, and expensive calculations. If a query takes 50ms and returns the same result many times, caching lets you run it once and serve later requests from cache.<\/p>
For small, short-lived values on a single server, a simple in-memory cache is often enough. Keep it limited with a TTL or maximum size so it doesn’t grow into a memory problem.<\/p>
Use Redis or Memcached when you run multiple processes, need shared cache across servers, or store session data outside the app process.<\/p>
\n
\n\t\t\t\n\t\t\t\t<\/path>\n\t\t\t<\/svg>\n\t\t<\/button><\/figure><\/div>Cache type<\/strong><\/p><\/td>Best for<\/strong><\/p><\/td>Main benefit<\/strong><\/p><\/td>Watch out for<\/strong><\/p><\/td><\/tr>In-memory<\/span><\/p><\/td>
Small, temporary values<\/span><\/p><\/td>
Fast reads, no network call<\/span><\/p><\/td>
Not shared across processes<\/span><\/p><\/td><\/tr>Redis\/Memcached<\/span><\/p><\/td>
Shared data, sessions<\/span><\/p><\/td>
Works across instances<\/span><\/p><\/td>
Adds a network hop<\/span><\/p><\/td><\/tr>CDN<\/span><\/p><\/td>
Static files, public assets<\/span><\/p><\/td>
Lower origin load and latency<\/span><\/p><\/td>
Wrong headers serve stale files<\/span><\/p><\/td><\/tr>HTTP headers<\/span><\/p><\/td>
Repeat visits, static assets<\/span><\/p><\/td>
Controls how responses are reused<\/span><\/p><\/td>
Misconfigured headers cache too much<\/span><\/p><\/td><\/tr><\/tbody><\/table><\/figure>Whichever type you use, caching needs two settings: TTL and invalidation.<\/p>
TTL (time to live) decides how long a cached value stays valid. A short TTL keeps data fresh but means more repeated work. A long TTL improves speed but risks serving stale data. Invalidation is how you remove or update cached values when the source changes.<\/p>
Track cache hit rate. If 90% of requests are served from cache, your database handles only 10% of that work. If the hit rate stays low, the TTL may be too short, the cache keys too specific, or the data may change too often to cache well.<\/p>
4. Optimize database queries and connection handling<\/h2> Database calls are often one of the biggest sources of slow API responses because your app waits for the database before it can return a response.<\/p>
Start with the highest-impact fixes:<\/p>
\nSelect only the columns you need<\/li>\n\n\n\n Avoid SELECT *<\/code><\/li>\n\n\n\nAdd indexes to frequently filtered, sorted, or joined columns<\/li>\n\n\n\n Avoid N+1 queries<\/li>\n\n\n\n Paginate large result sets<\/li>\n\n\n\n Use connection pooling<\/li>\n\n\n\n Check execution plans for slow queries<\/li>\n<\/ul>Compare an unoptimized query with a cleaner one:<\/p>
\/\/ Slow – fetches every column and every row<\/code><\/p>const users = await db.query('SELECT * FROM users');const users = await db.query(<\/code><\/p>'SELECT id, name, email FROM users ORDER BY created_at DESC LIMIT 20'<\/code><\/p>);<\/code><\/p>On a table with, say, 100,000 rows and 30 columns, the first query makes your app fetch and send far more data than needed. The second returns 20 rows with three columns. With a useful index on created_at<\/code>, the database can pull the most recent records without scanning the full table.<\/p>The query itself is only half the story. The other is how your app connects to the database. Without pooling, the app opens a new connection for each request, which adds delay and can overwhelm the database. A connection pool keeps connections ready and reuses them.<\/p>
Most Node.js drivers, including pg<\/code> and mysql2<\/code>, support pooling. Tune the pool size based on traffic, database capacity, and the number of app instances. Too few connections cause requests to queue. Too many overload the database.<\/p>How do indexes improve Node.js application performance?<\/h3> Indexes help the database find matching rows faster, which reduces query time and speeds up API responses.<\/p>
If your login route looks up users by email, for example, an index on email<\/code> helps the database find the matching row without scanning every record:<\/p>SELECT id, name, email<\/code><\/p>FROM users<\/code><\/p>WHERE email = $1;<\/code><\/p>Email values are typically unique or close to unique, so this type of index is often useful.<\/p>
For paginated queries that filter and sort, a composite index like (active, created_at)<\/code> may help, depending on the database and data distribution.<\/p>Don’t index every column. Indexes speed up reads but add write time and storage, because the database updates the index whenever rows change.<\/p>
5. Use streams for large files and large responses<\/h2> Streams process data in chunks instead of loading full files into memory. If you load a 500MB CSV file the normal way, for example, it takes 500MB of RAM. Streamed, it uses only a small buffer at any given time.<\/p>
Avoid loading large files like this:<\/p>
app.get('\/download', async (req, res) => {<\/code><\/p>const data = await fs.promises.readFile('large-file.csv');<\/code><\/p>res.send(data);<\/code><\/p>});<\/code><\/p>Use a stream instead:<\/p>
const fs = require('node:fs');<\/code><\/p>const { pipeline } = require('node:stream\/promises');<\/code><\/p><\/p>
app.get('\/download', async (req, res, next) => {<\/code><\/p>try {<\/code><\/p>await pipeline(<\/code><\/p>fs.createReadStream('large-file.csv'),<\/code><\/p>res<\/code><\/p>);<\/code><\/p>} catch (err) {<\/code><\/p>next(err);<\/code><\/p>}<\/code><\/p>});<\/code><\/p>The streamed version starts sending data immediately and keeps memory lower because Node handles the file in chunks.<\/p>
Streams also handle speed mismatches between sender and receiver, which is called backpressure. If a user has a slow connection, Node pauses reading until the response stream catches up. Use pipeline()<\/code> for production code because it handles stream errors and cleanup better than .pipe()<\/code>.<\/p>In production, also check that the file exists, set the right headers, and handle client disconnects.<\/p>
6. Reduce CPU-heavy work in the main thread<\/h2> CPU-heavy tasks block the main thread, preventing the event loop from handling other requests. Async code does not fix this because the JavaScript engine still runs the computation on one thread.<\/p>
Common CPU-heavy tasks include:<\/p>
![\"Clinic.js](\"https:\/\/www.hostinger.com\/tutorials\/wp-content\/uploads\/sites\/2\/2026\/05\/1778753978115-0.png\")