Claude Code से धीमे Node.js को ठीक करें: अनुमान नहीं, पहले मापें

आपका Node.js report API धीमा है, release पास है, और पहली सलाह आती है कि “index जोड़ दो।” यह सही भी हो सकता है, लेकिन जब तक समय मापा नहीं गया, यह अनुमान ही है। धीमे code में सबसे बड़ा जोखिम यही है कि team आधा दिन उस जगह सुधारती है जो असल bottleneck नहीं है।

यह guide Claude Code को coding assistant मानती है, भविष्य बताने वाला tool नहीं। Bottleneck वह सबसे धीमा भाग है जो पूरी request की गति रोकता है। Profiling का मतलब runtime मापना है, ताकि bottleneck दिखे। सुरक्षित क्रम है: छोटे timer जोड़ें, synthetic data के साथ repeatable command चलाएं, सबसे धीमे हिस्से को ही ठीक करें, फिर वही command दोबारा चलाकर जांचें।

यह लेख server-side Node.js के लिए है: API handler, batch script, CSV export और data processing job. Browser rendering, image loading या layout shift अलग समस्या है; उसके लिए Core Web Vitals performance guide देखें। अगर समय SQL query में जा रहा है, तो SQL optimization guide अगला कदम है।

पहले क्या करें

सबसे छोटे काम से शुरू करें: एक route, एक script, एक fixture, या एक CSV export command. जब तक धीमापन दिखाने वाली command नहीं है, Claude Code से “पूरा project तेज कर दो” न कहें। छोटा scope कम files पढ़वाता है और final evidence review करना आसान बनाता है।

शब्द साफ रखें। N+1 problem का मतलब है list एक बार लेना और फिर हर item के लिए related data अलग से लेना। Serial await का मतलब है independent async काम को एक-एक करके wait कराना। Memoization का मतलब है same input के result को दोबारा इस्तेमाल करना, फिर से calculate नहीं करना।

पहला prompt measurement और permission को अलग करे:

claude -p "src/api/report.ts is slow. Do not rewrite it yet.
Add timing around database fetch, API fetch, transform, and response formatting.
Use synthetic fixture data only. Return the changed files, command to run, and the slowest measured section.
Do not change production settings, billing limits, credentials, or customer-data handling without human approval."

Copy-paste measurement code

पहला change boring होना चाहिए: time print करें, service redesign नहीं। Node.js official node:perf_hooks documentation में performance.now() देता है, इसलिए नया package install करने की जरूरत नहीं है।

Test branch या temporary folder में measured-report.mjs बनाएं और Node से चलाएं। Data synthetic है: इसमें secret, token, production URL या customer row नहीं है।

import { performance } from "node:perf_hooks";

const wait = (ms) => new Promise((resolve) => setTimeout(resolve, ms));

function createTimer() {
  const records = [];
  return {
    async measure(label, fn) {
      const start = performance.now();
      const value = await fn();
      records.push({ label, ms: Number((performance.now() - start).toFixed(1)) });
      return value;
    },
    report() {
      return records.sort((a, b) => b.ms - a.ms);
    },
  };
}

async function fetchUsers() {
  await wait(60);
  return Array.from({ length: 6 }, (_, index) => ({ id: index + 1 }));
}

async function fetchOrdersOneByOne(users) {
  const orders = [];
  for (const user of users) {
    await wait(45);
    orders.push({ userId: user.id, total: user.id * 10 });
  }
  return orders;
}

async function fetchOrdersInBatch(users) {
  await wait(55);
  return users.map((user) => ({ userId: user.id, total: user.id * 10 }));
}

function buildReport(users, orders) {
  const ordersByUser = new Map(orders.map((order) => [order.userId, order]));
  return users.map((user) => ({ ...user, orderTotal: ordersByUser.get(user.id)?.total ?? 0 }));
}

async function run(fetchOrders) {
  const timer = createTimer();
  const users = await timer.measure("users", fetchUsers);
  const orders = await timer.measure("orders", () => fetchOrders(users));
  await timer.measure("report", () => buildReport(users, orders));
  console.table(timer.report());
}

console.log("slow version");
await run(fetchOrdersOneByOne);

console.log("batch version");
await run(fetchOrdersInBatch);

Command इस तरह चलाएं:

node measured-report.mjs
node --prof measured-report.mjs
node --prof-process isolate-*.log > profile.txt

node --prof built-in profiler है और official Node.js CLI reference में लिखा है। Simple timer से CPU bottleneck साफ न दिखे तो इसे चलाएं। कई API और batch job में छोटी timing table ही पहला target बता देती है।

तीन उपयोग के मामले

मामला 1: धीमा API response

Input: API handler, route test और synthetic request payload. Claude Code database fetch, external fetch, transform और serialization के आसपास timer जोड़ सकता है। Production credential, authentication, traffic limit या customer data retention बदलने से पहले human approval जरूरी है।

Output: छोटी timing table और सबसे धीमे हिस्से पर focused patch. अगर slow हिस्सा query है, तो random index जोड़ने से पहले SQL checklist देखें। अगर slow हिस्सा JSON formatting है, तो fix application code में रखें।

मामला 2: batch CSV export

Input: fake rows वाली local fixture और CSV बनाने वाली command. Claude Code row loading, join, formatting और file write माप सकता है। Fixture से production export पर जाने से पहले इंसान को approve करना चाहिए, क्योंकि वहां customer data और compute cost आ सकते हैं।

Output: evidence कि समस्या N+1 read, serial call या repeated formatting में से किसमें है। आम correction batching, concurrency limit या formatter memoization होता है; पूरे job को rewrite करना पहला कदम नहीं है।

मामला 3: release से पहले pull request review

Input: pull request diff, existing performance test और expected response budget. Claude Code diff पढ़कर extra timing suggest कर सकता है। Release decision, rollback plan और customer-facing SLA claim इंसान को approve करना चाहिए।

Output: review note जिसमें measured risk, चलाई गई command और unmeasured area लिखे हों। यह “लगता है तेज है” से ज्यादा उपयोगी है।

मापने के बाद सुधार pattern

मापा गया लक्षण	संभव कारण	सुरक्षित पहला correction
बहुत सारी similar query या API call	N+1	IDs batch करें, relation bulk में load करें, या bulk endpoint लें
independent call का time जुड़ रहा है	serial await	सिर्फ independent काम पर Promise.all लगाएं
वही transform बार-बार चल रहा है	unnecessary recalculation	input के हिसाब से cache करें या setup loop से बाहर करें
rows बढ़ते ही time बहुत बढ़ता है	nested scan	एक बार Map बनाएं, या index से पहले query plan देखें

यह table measurement का replacement नहीं है। यह timing result को smallest safe patch में बदलने के लिए है। अगर correction security, production traffic, billing या customer data को छूता है, तो fixture से बाहर चलाने से पहले रुकें और approval लें।

गलतियां और सुधार

गलती: Claude Code से बिना command “इस endpoint को optimize करो” कहना। सुधार: पहले reproduction command, fixture और timing table मांगें, फिर rewrite की अनुमति दें।

गलती: synthetic number को production benchmark मान लेना। सुधार: local data को synthetic label दें और उसे सिर्फ possible bottleneck ढूंढने के लिए इस्तेमाल करें। Production conclusion के लिए अपने system का approved observability data चाहिए।

गलती: serial loop को unlimited Promise.all में बदल देना। सुधार: पहले independence confirm करें, फिर database, paid API या rate-limited service के लिए concurrency limit रखें।

गलती: slow path में “database” दिखते ही index जोड़ना। सुधार: query plan देखें और read benefit, write cost और storage cost लिखें।

Claude Code की सीमा और human approval

Claude Code को repeatable engineering काम दें: temporary timer जोड़ना, synthetic fixture बनाना, loop के अंदर query ढूंढना, batching suggest करना, test update करना और before-after evidence summarize करना। ये changes reversible और review-friendly होते हैं।

Human approval production और business risk के लिए रखें: authentication, customer record, external service को data भेजना, paid API concurrency बढ़ाना, billing limit बदलना, production deploy, या SLA claim. Agent diff और checklist बना सकता है; risk decision इंसान लेता है।

Prompt में साफ line डालें: “Claude local measurement और tests बदल सकता है। Production data इस्तेमाल करने, secrets बदलने, billing control बदलने या deploy करने से पहले human approval चाहिए।”

मुख्य CTA

जो team इस flow को shared habit बनाना चाहती है, वह Claude Code training और consultation page देख सकती है। लक्ष्य कोई magic speed promise नहीं है; लक्ष्य है repeatable review जिसमें command, fixture, measured bottleneck, patch और remaining risk दर्ज हों।

हाथ से की गई verification

इस refresh में मैंने check किया कि internal links /hi/ use करते हैं, external links official Node.js documentation पर जाते हैं, code fences executable JavaScript और commands हैं, example सिर्फ synthetic data use करता है, और CTA Hindi training page पर जाता है।

मैंने production benchmark नहीं चलाया, कोई real customer incident नहीं देखा, और किसी live service की speedup claim नहीं की। हाथ से की गई जांच article content, code block syntax shape, link locality, और Claude Code बनाम human approval separation तक सीमित थी।