পারফরম্যান্স, memory leak আর DevTools — মেপে দ্রুত করা

১ · পারফরম্যান্স মানে ব্যবহারকারীর অভিজ্ঞতা — আর আগে মাপা

“সাইটটা ধীর” — এর ভেতরে আসলে চারটি আলাদা অভিযোগ লুকিয়ে থাকে। (১) দেখতে দেরি: লিংকে চাপার পর অনেকক্ষণ সাদা পাতা, বা পণ্যের ছবি আসতেই চায় না। (২) সাড়া দিতে দেরি: “কার্টে যোগ করুন” চাপলাম, কিছুই হলো না, আবার চাপলাম — দুটো যোগ হয়ে গেল। (৩) পাতা লাফানো: পড়ছিলাম, হঠাৎ একটি ব্যানার এসে লেখা নিচে ঠেলে দিল, আর ভুল বোতামে চাপ পড়ল। (৪) সময়ের সাথে ধীর হওয়া: শুরুতে ঠিক ছিল, আধা ঘণ্টা ব্যবহারের পর ফোন গরম, পাতা থেমে থেমে চলে। প্রতিটির কারণ আলাদা, মাপার উপায় আলাদা, সমাধানও আলাদা।

তাই এই পর্বের মূল মন্ত্র একটি চক্র: মাপুন → খুঁজুন → ঠিক করুন → আবার মাপুন। মাপার দুটি উৎস। এক, আসল ব্যবহারকারীদের যন্ত্র থেকে আসা সংখ্যা — যাকে বলে field data. দুই, নিজের কম্পিউটারে DevTools দিয়ে নিয়ন্ত্রিত পরীক্ষা — lab data. Field data বলে কোথায় সমস্যা; lab-এ profiling করে বোঝা যায় কেন।

কেন অনুমানে কাজ হয় না? কারণ প্রোগ্রামের সময় সমানভাবে ছড়ানো থাকে না। প্রায় সবসময় অল্প কয়েকটি জায়গায় বেশিরভাগ সময় যায়। ধরুন একটি ক্লিকে ৫০০ ms লাগে, যার ৪৫০ ms যায় ২,০০০টি কার্ড আঁকায়, আর ১০ ms একটি লুপে। আপনি লুপটিকে দ্বিগুণ দ্রুত করলেন — বাঁচল ৫ ms, ১%. অথচ কার্ড আঁকা অর্ধেক করলে বাঁচে ২২৫ ms. কোন অংশ বড়, তা শুধু মেপেই জানা যায় (ভাবনার প্রশ্ন ৫-এ Amdahl-এর যুক্তি দেখুন)।

২ · Core Web Vitals — ব্যবহারকারীর অনুভূতিকে সংখ্যায় মাপা

“দ্রুত লাগছে” কথাটিকে সংখ্যায় আনতে Google ২০২০ সালে Core Web Vitals নামে তিনটি মেট্রিক ঘোষণা করে। প্রতিটি উপরের একটি অভিযোগের সাথে মেলে। সাথে দুটি সহায়ক মেট্রিক আছে, যা সমস্যার উৎস খুঁজতে সাহায্য করে:

দুটি খুঁটিনাটি মনে রাখুন। প্রথমত, এই সীমা গড়ের ওপর নয় — বিচার হয় ৭৫তম percentile-এ। অর্থাৎ ভিজিটগুলোর অন্তত ৭৫% সীমার মধ্যে থাকলে তবেই “ভালো” — গড়ে ধীর ফোনের ব্যবহারকারীরা হারিয়ে যান, percentile-এ যান না। মোবাইল আর ডেস্কটপের হিসাব আলাদা। দ্বিতীয়ত, INP এসেছে ২০২৪ সালের মার্চে, আগের মেট্রিক FID-এর জায়গায়। পর্ব ৩১-এ দেখেছেন, INP-এর তিন ভাগ: input delay, processing আর presentation delay.

CLS-এর দুটি চেনা অপরাধী

একটি খবরের সাইটের কথা ভাবুন। লেখার মাঝে একটি ছবি আছে, কিন্তু <img>-এ width আর height দেওয়া নেই। ব্রাউজার প্রথমে জানে না ছবিটি কত বড়, তাই শূন্য জায়গা রেখে লেখা সাজায়। ছবি নামার পর হঠাৎ ৩০০ pixel জায়গা লাগে — নিচের সব লেখা ঝাঁকি খেয়ে সরে যায়। দ্বিতীয় অপরাধী দেরিতে আসা ব্যানার: পাতা দেখানোর এক সেকেন্ড পর JavaScript ওপরে “অ্যাপ নামান” ব্যানার ঢোকায়, আর পুরো পাতা নিচে নামে। সমাধান দুটোই সরল:

<!-- ছবির মাপ আগেই জানান — ব্রাউজার ঠিক জায়গা রেখে দেয় -->
<img src="padma-bridge.webp" width="800" height="450" alt="পদ্মা সেতু">

<!-- দেরিতে আসা ব্যানারের জন্য আগে থেকেই জায়গা সংরক্ষণ -->
<div class="promo-slot" style="min-height: 64px"></div>

Lab বনাম field — দুই রকম সত্য

Lighthouse (DevTools-এর ভেতরে, বা PageSpeed Insights-এ) একটি নিয়ন্ত্রিত পরিবেশে পাতা একবার লোড করে স্কোর দেয় — এটি lab data. যখন খুশি চালানো যায়, কিন্তু যন্ত্র আর নেটওয়ার্ক নকল, আর কোনো আসল ক্লিক নেই — তাই lab-এ INP মাপা যায় না, Lighthouse তার বদলে Total Blocking Time দেখায়। অন্যদিকে field data আসে আসল মানুষের আসল ফোন থেকে। Chrome ব্যবহারকারীদের (যাঁরা অনুমতি দিয়েছেন) সমষ্টিগত তথ্য Google প্রকাশ করে CrUX (Chrome User Experience Report) নামে, যা PageSpeed Insights আর Search Console-এ দেখা যায়। নিজের সাইটে নিজেই মাপতে চাইলে RUM (Real User Monitoring) — সবচেয়ে সহজ উপায় Google-এর ছোট web-vitals library:

import { onLCP, onINP, onCLS } from "web-vitals";

function send(metric) {
  // যেমন { name: "INP", value: 312, rating: "needs-improvement" }
  navigator.sendBeacon("/analytics", JSON.stringify(metric));
}
onLCP(send);
onINP(send);
onCLS(send);

৩ · নেটওয়ার্কের খরচ — JavaScript সবচেয়ে দামি byte

১০০ KB-র একটি JPEG ছবি আর ১০০ KB-র JavaScript — নামানোর খরচ সমান, তারপরের খরচ নয়। ছবি decode করে আঁকলেই শেষ, প্রায়ই main thread-এর বাইরে। JavaScript-কে নামানোর পর parse করতে হয়, compile করতে হয়, তারপর চালাতে হয় — আর এর বড় অংশ main thread-এ (পর্ব ০৫-এর engine pipeline মনে করুন)। কম দামের ফোনে এই কাজ দামি ফোনের কয়েক গুণ সময় নিতে পারে। তাই bundle size — পাতা যত KB JavaScript পাঠায় — পারফরম্যান্সের সবচেয়ে বড় নির্ধারকগুলোর একটি।

বাস্তব ঘটনা: ২ MB JavaScript-এর পণ্য-তালিকা

একটি অনলাইন দোকানের পণ্য-তালিকার পাতা মোবাইলে খুলতে অনেক সময় নিচ্ছিল; field data-য় LCP ছিল “খারাপ” সীমার অনেক ওপরে। DevTools-এর Network প্যানেলে দেখা গেল, পাতা মোট প্রায় ২ MB (খোলা আকারে) JavaScript নামাচ্ছে। Bundle বিশ্লেষণে তিনটি বড় অংশ: একটি চার্ট library (শুধু “দামের ইতিহাস” ট্যাবে লাগে, যা খুব কম লোক খোলেন), পুরো একটি তারিখ-library (দুটি function ব্যবহারের জন্য), আর সব পাতার কোড একসাথে। সমাধান তিন ধাপে: চার্ট দেরিতে আনা, তারিখ-library-র বদলে ব্রাউজারের নিজের Intl (পর্ব ২০), আর বাইরের library-গুলো আলাদা vendor chunk-এ রাখা, যাতে অ্যাপের কোড বদলালেও ব্যবহারকারীর cache-এ থাকা library আবার নামাতে না হয়।

// আগে: import { renderChart } from "./price-chart.js";  ← সবার জন্য, শুরুতেই
historyTab.addEventListener("click", async () => {
  historyTab.disabled = true;
  const { renderChart } = await import("./price-chart.js");  // প্রথম ক্লিকে নামে
  renderChart(chartBox, priceHistory);
}, { once: true });

ছবি আর font

বেশিরভাগ পাতায় LCP element একটি ছবি। তিনটি নিয়ম বড় পার্থক্য আনে। (১) আধুনিক ফরম্যাট — WebP আর AVIF সাধারণত একই মানের JPEG বা PNG-এর চেয়ে বেশ ছোট। (২) পর্দার মাপ অনুযায়ী ছবি — srcset আর sizes দিলে ফোন ছোট ছবিটি নেয়, ৪K মনিটর বড়টি। (৩) পর্দার বাইরের ছবিতে loading="lazy" (lazy loading) — কিন্তু LCP ছবিতে কখনো নয়; সেটিকে বরং fetchpriority="high" দিয়ে আগে আনুন।

<!-- ওপরের বড় ছবি (LCP): আগে আনুন, lazy নয় -->
<img src="hero-800.avif" srcset="hero-400.avif 400w, hero-800.avif 800w, hero-1600.avif 1600w"
     sizes="100vw" width="1600" height="900" fetchpriority="high" alt="ঈদের অফার">

<!-- নিচের পণ্যের ছবি: দেখার কাছাকাছি এলে নামবে -->
<img src="shirt.webp" width="300" height="300" loading="lazy" alt="সুতির শার্ট">

Web font নামার আগে ব্রাউজার লেখা লুকিয়ে রাখতে পারে — বাংলা font প্রায়ই বড় ফাইল, তাই এটা আরও চোখে পড়ে। CSS-এর @font-face-এ font-display: swap দিলে আগে system font-এ লেখা দেখা যায়, font নামলে বদলে যায়; শুধু দরকারি weight আর অক্ষর-সীমা (subset) রাখলে ফাইলও ছোট হয়।

Critical rendering path আর render-blocking resource

ব্রাউজার HTML থেকে DOM, CSS থেকে CSSOM বানায়, দুটো মিলিয়ে render tree, তারপর layout আর paint — এই ধারাকে বলে critical rendering path. <head>-এর সাধারণ <link rel="stylesheet"> আর defer/async ছাড়া <script> এই ধারা থামিয়ে দেয় — এরা render-blocking. পর্ব ৩৭-এ দেখা নিয়মটাই এখানে পারফরম্যান্সের হাতিয়ার: নিজের script-এ defer (বা type="module", যা নিজেই defer), স্বাধীন বাইরের script-এ (যেমন analytics) async, আর শুধু প্রথম পর্দার জন্য দরকারি অল্প CSS.

৪ · Runtime — ট্যাপে সাড়া দেওয়া পাতা

পাতা লোড হয়ে গেলেই কাজ শেষ নয়। এরপর আসে INP-এর প্রশ্ন: ব্যবহারকারী চাপলে পাতা কত দ্রুত সাড়া দেয়? পর্ব ৩১-এ দেখেছেন, main thread একসাথে একটিই কাজ করে, আর ৫০ ms-এর বেশি একটানা কাজ হলো long task. Runtime-এর সমস্যার প্রায় সবই শেষ পর্যন্ত এক জায়গায় দাঁড়ায় — main thread খুব বেশি সময় ব্যস্ত। চলুন একটি আসল ধাঁচের তদন্ত ধাপে ধাপে দেখি: একটি পণ্য-তালিকায় “দাম অনুযায়ী সাজান” বোতাম ফোনে ধীর।

Runtime-এর পাঁচটি পরিচিত সমাধান

• Long task ভাঙুন: বড় লুপ টুকরো করে মাঝে main thread ছেড়ে দিন — scheduler.yield() বা setTimeout দিয়ে (পর্ব ৩১-এর chunking). আগে পর্দায় সাড়া দেখান (“সাজানো হচ্ছে…”), তারপর ভারী কাজ।
• Layout thrashing এড়ান: লুপে DOM-এ লেখা আর offsetHeight, getBoundingClientRect()-এর মতো মাপ পড়া মিশিয়ে ফেললে ব্রাউজার প্রতিবার নতুন করে layout হিসাব করে — layout thrashing (পর্ব ৩৭)। সব পড়া একসাথে, তারপর সব লেখা।
• লম্বা তালিকা virtualize করুন: ১০,০০০ সারির তালিকায় ১০,০০০ DOM node রাখবেন না। শুধু দৃশ্যমান সারিগুলো আঁকুন, scroll করলে সেগুলোতেই নতুন ডেটা বসান — list virtualization. সহজ বিকল্প হিসেবে CSS-এর content-visibility: auto পর্দার বাইরের অংশের rendering পিছিয়ে দেয়।
• ঘন ঘন ঘটা event সামলান: প্রতিটি অক্ষরে খোঁজার request নয় — debounce; scroll-এ প্রতি pixel-এ হিসাব নয় — throttle (পর্ব ৩৬)।
• সত্যিকারের ভারী হিসাব সরিয়ে দিন: CSV parse, ছবি প্রসেসিং, বড় রিপোর্ট — Web Worker-এ (পর্ব ৪২)। Worker দ্রুত করে না, main thread খালি রাখে।

৫ · অ্যালগরিদম আগে, micro-optimization পরে

একটি অনলাইন দোকানের অ্যাডমিন পাতায় “পেমেন্ট মিলানো” ফিচার। এক তালিকায় আজকের অর্ডারের id, আরেক তালিকায় পেমেন্ট গেটওয়ে থেকে আসা পরিশোধিত id. কোন অর্ডারের টাকা এসেছে? প্রথম যে কোডটা মাথায় আসে (আর AI-ও প্রায়ই দেয়):

const paidOrders = orders.filter((id) => paidIds.includes(id));

এক লাইন, পরিষ্কার — আর ১০টি অর্ডারে একদম ঠিক। কিন্তু includes নিজেও একটি লুপ: সে paidIds-এর শুরু থেকে একটি একটি করে মেলায়। অর্থাৎ একটি লুপের ভেতরে আরেকটি লুপ। জিনিসের সংখ্যা n হলে কাজ বাড়ে প্রায় n × n হারে — time complexity-র ভাষায় O(n²). সমাধান পর্ব ১৮-এর Set: একবার Set বানালে প্রতিটি has() গড়ে প্রায় এক ধাপে উত্তর দেয়, কারণ ভেতরে আছে hash table.

নিজে চালিয়ে দেখুন। এখানে সময় মাপা হচ্ছে না (সময় যন্ত্র অনুযায়ী বদলায়), গোনা হচ্ছে কাজ — কয়টি তুলনা বা ধাপ লাগল:

function countWork(n) {
  const orders = Array.from({ length: n }, (_, i) => i + 1);
  const paid = orders.toReversed();            // একই id, উল্টো ক্রমে
  let slow = 0;                                // includes-এর মতো খোঁজা
  for (const id of orders) {
    for (const p of paid) { slow++; if (p === id) break; }
  }
  let fast = 0, found = 0;
  const paidSet = new Set();
  for (const p of paid) { paidSet.add(p); fast++; }      // একবার Set বানানো
  for (const id of orders) { fast++; if (paidSet.has(id)) found++; }
  return { slow, fast, found };
}
const fmt = (x) => x.toLocaleString("en-US");
for (const n of [100, 1000, 10000]) {
  const { slow, fast, found } = countWork(n);
  console.log(`n=${fmt(n)} → includes-লুপ: ${fmt(slow)} তুলনা · Set: ${fmt(fast)} ধাপ · মিলেছে ${fmt(found)}`);
}
const r = countWork(1000);
console.log("n=1,000-এ কাজ কমেছে প্রায়", Math.round(r.slow / r.fast), "গুণ");

Memoization — একই হিসাব দ্বিতীয়বার নয়

পর্ব ২২-এ দেখা memoization: একটি pure function-এর ফল input অনুযায়ী মনে রাখা, যাতে একই input-এ আবার হিসাব না লাগে। যেমন একটি ড্যাশবোর্ড প্রতিবার আঁকার সময় একই মাসের বিক্রির সারাংশ নতুন করে হিসাব করে — memoize করলে মাসপ্রতি একবার। কিন্তু memoization বিনামূল্যে নয়: cache মেমরি খায়, সস্তা হিসাবে cache খোঁজাই বেশি দামি হতে পারে, আর সীমাহীন cache নিজেই memory leak (অংশ ৬)। নিয়ম: profiler-এ যে হিসাব বারবার আর ভারী দেখায়, শুধু সেটাই memoize করুন।

V8-বান্ধব কোড — জানুন, কিন্তু মাথায় চড়াবেন না

পর্ব ০৫-এ দেখেছেন, V8 একই আকারের object-এর জন্য একটি hidden class বানায়, আর inline cache দিয়ে property খোঁজা দ্রুত করে। কিছু অভ্যাস engine-কে সাহায্য করে: সব object একই ক্রমে একই property দিয়ে তৈরি করা (constructor বা class-এ), গরম লুপের object থেকে delete না করা (property-তে undefined বসানো ভালো, কারণ delete object-কে ধীর “dictionary” ধাঁচে নিয়ে যেতে পারে), আর একটি function-কে সবসময় একই ধরনের মান দিয়ে ডাকা — যাকে বলে monomorphic. এগুলো ভাঙলে deoptimization হতে পারে। তবে এর প্রভাব চোখে পড়ে শুধু লাখোবার চলা গরম কোডে; সাধারণ অ্যাপে বড় লাভ থাকে bundle size, rendering আর অ্যালগরিদমে। Micro-optimization শেষ ধাপ, প্রথম নয়।

৬ · Memory — garbage collector কী মোছে, আর কী মুছতে পারে না

পর্ব ০৫ আর ১৮-এ দেখেছেন, JavaScript-এ মেমরি নিজে মুক্ত করতে হয় না — garbage collector (GC) তা করে। GC-র নিয়ম একটাই: reachability. Root (global object, call stack-এর variable, চলমান timer আর listener) থেকে reference ধরে ধরে যে object-এ পৌঁছানো যায়, সেটি জীবিত; যেটিতে যায় না, সেটি মুছে ফেলা হয়। Heap-কে V8 ভাগ করে রাখে দুই প্রজন্মে — একে বলে generational GC. বেশিরভাগ object জন্মের অল্প পরেই অপ্রয়োজনীয় হয় (একটি function-এর ভেতরের অস্থায়ী array, একটি request-এর ডেটা)। তাই নতুন object-এর ছোট জায়গাটি ঘন ঘন আর দ্রুত পরিষ্কার হয়; যারা কয়েকবার টিকে যায়, তারা পুরোনো প্রজন্মে যায়, যা কম ঘন ঘন পরিষ্কার হয়। আধুনিক V8 এই কাজের বড় অংশ অন্য thread-এ, আপনার কোডের পাশাপাশি করে (ভাবনার প্রশ্ন ৪)।

এখান থেকেই memory leak-এর সংজ্ঞা আসে। JavaScript-এ leak মানে GC-র ভুল নয়; মানে আপনার আর দরকার নেই, কিন্তু কোনো root থেকে এখনো পৌঁছানো যায় এমন জিনিস। GC বুঝতে পারে না আপনার “দরকার” আছে কি না — সে শুধু দেখে পৌঁছানো যায় কি না। Leak ধীরে ধীরে জমে: এক ঘণ্টা পর মেমরি কয়েকশো MB, GC বারবার চলে, পাতা থেমে থেমে চলে। Single-page app আর দিনভর খোলা থাকা ড্যাশবোর্ড বা চ্যাট অ্যাপে এটি সবচেয়ে বেশি দেখা যায়; Node.js সার্ভারে এর মানে কয়েক দিন পর মেমরি শেষ হয়ে crash.

বাস্তব ঘটনা: infinite scroll-এর leak

একটি খবরের অ্যাপে প্রতিটি “পাতা” (route) খুললে একটি তালিকা component তৈরি হয়, যা scroll-এ নতুন খবর আনে। কয়েকবার এদিক-ওদিক ঘোরার পর ফোনে অ্যাপ ধীর হয়ে যায়। কোডটি ছিল এমন:

// ভুল: component সরানো হয়, কিন্তু window-এর listener আর timer থেকে যায়
function mountFeed(container) {
  const cards = [];                                  // সব খবরের কার্ড
  window.addEventListener("scroll", () => {
    if (nearBottom()) cards.push(...appendMoreCards(container));
  });
  setInterval(() => refreshTimes(cards), 60_000);   // "৫ মিনিট আগে" হালনাগাদ
}

// ঠিক: একটি AbortController দিয়ে সব listener, আর timer-এর id রেখে পরিষ্কার
function mountFeed(container) {
  const cards = [];
  const controller = new AbortController();
  window.addEventListener("scroll", () => {
    if (nearBottom()) cards.push(...appendMoreCards(container));
  }, { signal: controller.signal });
  const timer = setInterval(() => refreshTimes(cards), 60_000);
  return function unmount() {                        // route ছাড়ার সময় ডাকুন
    controller.abort();                              // signal-যুক্ত সব listener সরে যায়
    clearInterval(timer);
    cards.length = 0;
  };
}

বাস্তব ঘটনা: চ্যাট অ্যাপের চিরকাল বাড়তে থাকা cache

একটি চ্যাট অ্যাপ প্রতিটি খোলা কথোপকথনের বার্তা একটি Map-এ রাখত, যাতে আবার খুললে সার্ভারে যেতে না হয়। কিন্তু কিছুই কখনো বের করা হতো না — সারাদিন অ্যাপ খোলা রাখা একজন সাপোর্ট কর্মীর ব্রাউজারে সন্ধ্যার মধ্যে কয়েকশো কথোপকথন জমত। সমাধান: একটি সীমা — LRU cache (Least Recently Used). সীমা পার হলে সবচেয়ে বেশি দিন ব্যবহার না হওয়া entry বাদ যায়। JavaScript-এর Map ঢোকানোর ক্রম মনে রাখে (পর্ব ১৮), তাই LRU বানানো সহজ: ব্যবহারের সময় entry মুছে আবার শেষে বসান, আর বাদ দিন সবচেয়ে প্রথমটি। নিচে দুটি cache পাশাপাশি — সংখ্যাগুলো সময় নয়, size:

class LRUCache {
  #max; #map = new Map();
  constructor(max) { this.#max = max; }
  get(key) {
    if (!this.#map.has(key)) return undefined;
    const value = this.#map.get(key);
    this.set(key, value);                    // মুছে আবার বসানো → সদ্য ব্যবহৃত, শেষে
    return value;
  }
  set(key, value) {
    this.#map.delete(key); this.#map.set(key, value);
    if (this.#map.size > this.#max) this.#map.delete(this.#map.keys().next().value); // সবচেয়ে পুরোনোটি বাদ
  }
  get size() { return this.#map.size; }
}
const forever = new Map();          // ভুল: যা ঢোকে, কখনো বের হয় না
const recent = new LRUCache(50);    // ঠিক: সর্বোচ্চ ৫০টি চ্যাট
let hits = 0;
for (let i = 1; i <= 1000; i++) {
  const messages = Array(200).fill("…");      // একটি চ্যাটের ২০০টি বার্তা
  forever.set(`chat-${i}`, messages); recent.set(`chat-${i}`, messages);
  if (i > 3 && recent.get(`chat-${i - 3}`)) hits++;  // সাম্প্রতিক চ্যাটে ফেরা
  if (i % 250 === 0) console.log(`${i}টি চ্যাট খোলার পর → Map: ${forever.size}, LRU: ${recent.size}`);
}
console.log("সাম্প্রতিক চ্যাটে ফেরা:", hits, "বার — LRU-তে প্রতিবারই পাওয়া গেছে");

৭ · DevTools দিয়ে তদন্ত — Memory, Performance, Lighthouse আর আরও

Memory প্যানেল — heap snapshot তুলনা করে leak ধরা

Leak সন্দেহ হলে প্রথম প্রশ্ন: একটি কাজ বারবার করলে মেমরি কি শুধু বাড়ে? Chrome বা Edge-এর DevTools-এ Memory প্যানেলের heap snapshot হলো সেই মুহূর্তে heap-এর সব object-এর একটি ছবি — কোন ধরনের কয়টি object, কত বড়, আর কে কাকে ধরে রেখেছে। একটি snapshot একা খুব কিছু বলে না; শক্তি হলো দুটি snapshot-এর তুলনা। আগের অংশের খবরের অ্যাপের leak এভাবে ধরা পড়েছিল:

Memory প্যানেলের Allocation instrumentation on timeline মোড দেখায় কোন মুহূর্তে তৈরি object টিকে রইল — কোন ক্লিকে leak হয় তা ধরতে কাজের। আর প্রথম ধাপ হিসেবে Chrome-এর Task Manager (Shift+Esc) বা Performance প্যানেলের “Memory” চেকবক্স দিয়ে দেখতে পারেন, মেমরির রেখা করাতের দাঁতের মতো ওঠানামা করছে (স্বাভাবিক) নাকি সিঁড়ির মতো শুধু উঠছে (leak-এর লক্ষণ)।

Performance প্যানেল

Record চেপে পাতা ব্যবহার করুন, থামান — DevTools দেখাবে প্রতিটি মিলিসেকেন্ডে main thread কী করছিল। ওপরে সময়ের রেখা, তার নিচে Network, Frames, আর সবচেয়ে গুরুত্বপূর্ণ Main সারি — একটি flame chart: অনুভূমিক দিকে সময়, উল্লম্ব দিকে call stack (ওপরের ব্লক নিচের ব্লকগুলোকে ডেকেছে)। চওড়া ব্লক মানে বেশি সময়। হলুদ = JavaScript, বেগুনি = style আর layout, সবুজ = paint. Long task-এর ওপরের কোণে লাল ত্রিভুজ থাকে। নিচের Bottom-Up ট্যাব বলে কোন function নিজে সবচেয়ে বেশি সময় নিল। নতুন সংস্করণে প্যানেল খুললেই নিজের যন্ত্রে মাপা LCP, CLS আর INP দেখা যায়, পাশে CrUX-এর field data-ও। CPU throttling (৪× বা ৬× ধীর) দিয়ে কম দামের ফোনের মতো অবস্থা তৈরি করুন, আর extension এড়াতে Incognito-তে মাপুন।

আরও তিনটি দরকারি জায়গা

• Network প্যানেল আর throttling: প্রতিটি ফাইলের আকার (চাপা ও খোলা), সময়, ক্রম আর cache থেকে এল কি না। Network throttling-এর “Slow 4G” বা “3G” বাছলে দুর্বল মোবাইল নেটওয়ার্কে পাতা কেমন, তা নিজের চোখে দেখা যায়।
• Coverage ট্যাব: Command menu (Ctrl+Shift+P) থেকে “Coverage” খুলে record করলে প্রতিটি JS আর CSS ফাইলের কত অংশ আসলে চলল, তা লাল-সবুজ দাগে দেখায়। প্রথম লোডে ৭০% কোড না চললে সেটা code splitting-এর পরিষ্কার সুযোগ।
• Lighthouse: এক ক্লিকে performance, accessibility, SEO-র নিরীক্ষা, আর নির্দিষ্ট পরামর্শ — বড় ছবি, render-blocking resource, অব্যবহৃত JavaScript. শুরু করার ভালো জায়গা, তবে সাফল্যের মাপকাঠি field data.

DevTools-এ মাপলে নিজের কোডেও মাপার চিহ্ন বসাতে পারেন। performance.mark() আর performance.measure() দেওয়া অংশগুলো Performance প্যানেলের Timings সারিতে নাম ধরে দেখা যায়:

performance.mark("sort-start");
const sorted = products.toSorted((a, b) => a.price - b.price);
renderCards(sorted);
performance.mark("sort-end");
const m = performance.measure("sort-and-render", "sort-start", "sort-end");
console.log(m.name, Math.round(m.duration), "ms");
// আপনার মেশিনে প্রায়: sort-and-render 412 ms (যন্ত্র আর ডেটা অনুযায়ী বদলাবে)

৮ · Node.js-এ profiling আর CI-তে performance budget

সার্ভারেও একই চক্র — মাপুন, খুঁজুন, ঠিক করুন, আবার মাপুন — শুধু টুল আলাদা। সবচেয়ে সহজ পথ হলো Node-কে Chrome DevTools-এর সাথে জুড়ে দেওয়া:

# DevTools-এর সাথে জুড়ে চালান, তারপর Chrome-এ chrome://inspect খুলুন
node --inspect server.js

# পুরো চলার CPU profile ফাইলে লিখুন (.cpuprofile — DevTools-এ খোলা যায়)
node --cpu-prof server.js

# heap snapshot-এর জন্য: DevTools-এর Memory ট্যাব, বা কোডে v8.writeHeapSnapshot()

Node সার্ভারের স্বাস্থ্যের সবচেয়ে কাজের একটি সংখ্যা হলো event loop lag — একটি timer যখন চলার কথা, তার কত পরে আসলে চলল। পর্ব ৩১-এ দেখেছেন, একটি request-এ ভারী sync কাজ হলে বাকি সব request অপেক্ষা করে; lag বেড়ে যাওয়া তার সরাসরি লক্ষণ। Node-এর perf_hooks module-এর monitorEventLoopDelay() এই delay-র histogram দেয় — p99 মানটি নিয়মিত monitoring-এ পাঠান, আর হঠাৎ বেড়ে গেলে সতর্কবার্তা।

Performance budget — পারফরম্যান্স যেন ধীরে ধীরে না হারায়

পারফরম্যান্স এক দিনে খারাপ হয় না — প্রতি সপ্তাহে একটি “ছোট” library, এক বছর পর পাতা দ্বিগুণ ভারী। সমাধান হলো performance budget: আগে থেকে সীমা ঠিক করা — যেমন “প্রথম পাতার JavaScript সর্বোচ্চ ১৭০ KB (চাপা অবস্থায়)”, “মোবাইলে Lighthouse-এর LCP ২.৫ সেকেন্ডের কম” — আর প্রতিটি pull request-এ CI (স্বয়ংক্রিয় build ও test-এর ব্যবস্থা; টেস্টিং নিয়ে পর্ব ৪৮) সেটা যাচাই করে। size-limit-এর মতো টুল bundle-এর আকার মাপে, Lighthouse CI প্রতিটি build-এ Lighthouse চালায়; সীমা পার হলে build লাল। ফলে প্রশ্নটা রিভিউতেই ওঠে: “এই ৮০ KB-র library কি সত্যিই দরকার?”

৯ · AI-এর যুগে — অনুমানের পরামর্শ বনাম মাপা profile

“আমার পাতা ধীর, দ্রুত করো” — এই অনুরোধে AI সাধারণত একগাদা পরিচিত টিপস দেয়, কারণ আপনার যন্ত্র, ডেটা বা ব্যবহারকারী — কিছুই সে দেখেনি। নিচের ভুলগুলো চিনে রাখুন:

AI-এর পারফরম্যান্স পরামর্শ হাতে পেলে — যাচাইয়ের চেকলিস্ট

• পরিবর্তনের আগে field data বা profile দিয়ে সমস্যাটি মেপে রেখেছি
• পরামর্শটি profile-এর সবচেয়ে বড় বাধার দিকেই — ছোটখাটো জায়গায় নয়
• নতুন কোনো library যোগ হলে তার bundle size দেখেছি, আর বিকল্প ভেবেছি
• প্রতিটি setInterval, addEventListener আর cache-এর পাশে পরিষ্কার বা সীমার কোড আছে
• লুপের ভেতরে লুকানো লুপ (includes, find, filter) খুঁজে দেখেছি
• পরিবর্তনের পর একই অবস্থায় (throttling সহ) আবার মেপে উন্নতি নিশ্চিত করেছি