Compression & Performance
compression middleware responses ko gzip/brotli karta hai — JSON aur HTML par 70-80% tak size kam ho sakta hai. Chhoti responses (1KB se kam) par compression ka overhead faayde se zyada hota hai, isliye threshold default rehne do.
Express single-threaded event loop par chalta hai — koi bhi BLOCKING kaam (sync file read, bada JSON.parse, heavy loop) POORA server rok deta hai. Heavy CPU kaam worker threads ya alag service mein bhejo, aur caching (Redis, ETag) se repeated work hatao.
app.use(require("compression")());
// BLOCKING — poora server ruk jaayega
const data = fs.readFileSync("big.json");
// NON-BLOCKING — sahi tarika
const data = await fs.promises.readFile("big.json");
res.set("Cache-Control", "public, max-age=300");- compression middleware gzip/brotli se response size 70-80% kam karta hai
- Sync/blocking calls single event loop ko rok deti hain — hamesha async
- Cache-Control aur Redis se repeated kaam hatao
Node ka event loop single-threaded hai — ek blocking operation ke dauraan koi bhi doosri request serve nahi hoti. Common culprits: fs.readFileSync, bcrypt ka sync version, bade arrays par heavy loops, aur bahut bada JSON.parse. Inhe async APIs, worker threads ya queue par shift karo.
// BLOCKING
const hash = bcrypt.hashSync(password, 12);
// NON-BLOCKING
const hash = await bcrypt.hash(password, 12);Teen level par caching soch sakte ho: HTTP caching (Cache-Control, ETag — client dobara maangta hi nahi), application caching (Redis mein computed results), aur database query caching. Sabse sasta wahi hai jo request server tak aane hi na de.
app.get("/stats", async (req, res) => {
const cached = await redis.get("stats");
if (cached) return res.json(JSON.parse(cached));
const stats = await computeStats(); // mehnga
await redis.setex("stats", 300, JSON.stringify(stats));
res.json(stats);
});