React performance — memo, code splitting, Suspense আর error boundary

১ · আগে মাপুন: অনুমান নয়, একটি নির্দিষ্ট কাজ

পর্ব ১৪-এ useMemo, useCallback আর compiler-এর ভিত্তি দেখেছেন। পর্ব ১৫-এ দেখেছেন render, commit আর Profiler-এর আচরণ। সেগুলো এখানে আবার পড়াব না। এই পর্বের প্রশ্ন ব্যবহারিক: “বাজারঘর” একটি পুরোনো ফোনে কেন ধীর, আর কীভাবে তাকে দ্রুত ও ভাঙন-সহনশীল করা যায়।

ব্রাউজারের একটিমাত্র main thread JavaScript চালায়, layout করে, ছবি আঁকে। এখানে ৫০ ms-এর বেশি চলা কাজই long task. Long task চলার সময় ব্যবহারকারীর ক্লিক অপেক্ষায় থাকে। সেই অভিজ্ঞতার মাপ INP: একটি ক্লিক, ট্যাপ বা কী চাপ থেকে পরের ফ্রেম পর্দায় আসা পর্যন্ত সময়। পুরো পাতার জীবনে সবচেয়ে খারাপ দিকের একটি মান নেওয়া হয়। web.dev-এর সীমা: ২০০ ms বা কম ভালো, ৫০০ ms-এর বেশি খারাপ, মাঝেরটুকুতে উন্নতির জায়গা আছে। আসল ব্যবহারকারীদের ৭৫তম percentile ধরে বিচার হয়।

একটি interaction-এর সময় তিন ভাগে ভাঙে। কোন ভাগ বড়, সেটিই বলে দেয় কোথায় হাত দিতে হবে।

“বাজারঘর”-এর ২,০০০ সারির তালিকায় ঝুড়িতে পণ্য যোগ করা ধীর। Event Timing API দিয়ে সেই ক্লিক ধরি। ব্রাউজার নিজেই প্রতিটি ইভেন্টের ভাগ দেয়:

new PerformanceObserver((list) => {
  for (const e of list.getEntries()) {
    if (!e.interactionId) continue;        // শুধু আসল ইন্টারঅ্যাকশন
    console.log(e.name, {
      total: e.duration,
      input: e.processingStart - e.startTime,
      processing: e.processingEnd - e.processingStart,
      presentation: e.startTime + e.duration - e.processingEnd,
    });
  }
}).observe({ type: 'event', durationThreshold: 16, buffered: true });

plain   INP-like 240.0   input 5.8   proc 216.7   present 18.9   rows/click 2000

একটি ক্লিকে ২৪০ ms, ভালো সীমার বাইরে। ভাগগুলো দেখলেই পথ পরিষ্কার। ধাপে ধাপে দেখুন, DevTools-এর ফলকে কীভাবে কাজের সিদ্ধান্তে আনা যায়।

1function Row({ p, onAdd }) {2  const fmt = new Intl.NumberFormat('bn-BD', opts);3  return <li>{fmt.format(p.price)} …</li>;4}5<button onClick={() => onAdd(p.id)}>যোগ</button>6{products.map(p => <Row key={p.id} p={p} … />)}

২ · ধীর হওয়ার চার সাধারণ কারণ

বেশিরভাগ React অ্যাপের ধীরতা এই চারটির কোনো একটিতে পড়ে। প্রতিটির ওষুধ আলাদা। তাই আগের ধাপের মাপ দরকার।

একটি অদ্ভুত কিন্তু দামি ফল: আগের মাপের সারিগুলো পাশাপাশি রাখি। সব একই ২,০০০ সারি, একই ক্লিক। দুটি আলাদা run দিলাম, যাতে স্থানীয় ওঠানামা বোঝা যায়। compiler-এর সারি দুটি পরের অংশে ব্যাখ্যা করব।

দ্বিতীয় সারিটি দেখুন। memo লেখা হয়েছে, অথচ লাভ শূন্য। এটিই পরের অংশের বিষয়।

৩ · memo আর স্থির props, তারপর React Compiler

memo একটি component-কে মুড়ে দেয়। Parent render হলে React আগের আর নতুন props প্রতিটি Object.is দিয়ে মেলায়। সব এক হলে child-এর ফাংশন চলে না। একটি prop আলাদা হলেই পুরো লাভ শেষ। নিজের state বা context বদলালে memo করা component তবুও চলবে।

দর্জির দোকান ভাবুন। পুরোনো মাপ মিলে গেলে নতুন করে মাপতে হয় না। কিন্তু প্রতিবার নতুন খাতা হাতে দিলে দর্জি মিলাতেই পারেন না। Inline object আর function হলো সেই নতুন খাতা। নিচের ব্লক লোড হতেই parent-কে তিনবার render করে, আর দুটি একই রকম কার্ডের render গোনে।

<div id="root"></div>
<script src="../course-kit/vendor/react-lab.js"></script>
<script type="text/jsx">
const counts = { unstable: 0, stable: 0 };
const Card = memo(function Card({ name, style, onAdd }) {
  counts[name]++;
  return <button style={style} onClick={onAdd}>{name}</button>;
});
const box = { padding: 6 };            // বাইরে: সবসময় একই object
let bump;
function Shop() {
  const [n, setN] = useState(0);
  bump = setN;
  const add = useCallback(() => setN(c => c + 1), []);
  useEffect(() => { console.log('ঝুড়ি', n, JSON.stringify(counts)); });
  return (
    <div>
      <p>ঝুড়িতে {n}টি</p>
      <Card name="unstable" style={{ padding: 6 }} onAdd={() => setN(c => c + 1)} />
      <Card name="stable" style={box} onAdd={add} />
    </div>
  );
}
createRoot(document.getElementById('root')).render(<Shop />);
setTimeout(() => {
  for (const v of [1, 2, 3]) ReactDOM.flushSync(() => bump(v));
}, 50);
</script>

ঝুড়ি 0 {"unstable":1,"stable":1}
ঝুড়ি 1 {"unstable":2,"stable":1}
ঝুড়ি 2 {"unstable":3,"stable":1}
ঝুড়ি 3 {"unstable":4,"stable":1}

React Compiler কী বদলাল: আসল বিল্ড

পর্ব ১৪-এ React Compiler কী, তা দেখেছেন। এবার একই “বাজারঘর” কোড compiler সহ build করে মাপলাম। @vitejs/plugin-react 6-এ Babel option সরানো হয়েছে, তাই আলাদা plugin লাগে। সত্যিকারের config, compiler 1.0.0, @babel/core 8.0.10, @rolldown/plugin-babel 0.2.4:

import { defineConfig } from 'vite';
import react, { reactCompilerPreset } from '@vitejs/plugin-react';
import babel from '@rolldown/plugin-babel';

export default defineConfig({
  plugins: [react(), babel({ presets: [reactCompilerPreset()] })],
});

আগের টেবিলের শেষ দুই সারি এই build-এর। হাতে একটিও memo নেই। Handler-এ c => c + 1 থাকলে render শূন্য, মোট 24 ms, হাতে লেখা সেরা সংস্করণের সমান বা ভালো। Build ফাইলে (minify বন্ধ করে) কারণটি দেখা গেল:

function PlainUpd() {
	const $ = (0, import_compiler_runtime.c)(5);
	const [count, setCount] = (0, import_react.useState)(0);
	…
	let t1;
	if ($[2] === Symbol.for("react.memo_cache_sentinel")) {
		t1 = … ("ul", { children: products.map((p) => … (Row, {
			p,
			onAdd: () => setCount(_temp)
		}, p.id)) });
		$[2] = t1;
	} else t1 = $[2];

পুরো ul একবার বানিয়ে জমা রেখেছে। Handler নিজেই _temp নামে বাইরে সরে গেছে। পরের render-এ একই object, তাই React পুরো subtree বাদ দেয়।

কিন্তু অন্য সারিটি শিক্ষণীয়। Handler যখন setCount(count + 1) লেখে, function-টি count-এর ওপর নির্ভর করে। তাই প্রতি ক্লিকে সেটি সত্যিই বদলায়, আর ২,০০০ Row চলে। Compiler অর্থ বদলায় না, তাই সে এটি ঠিক করতে পারে না। তবু 48 ms এল, কারণ build ফাইলে দেখা গেল সে প্রতি Row-এ Intl.NumberFormat ডাকটি জমা রেখেছে। তাই কথাটি হলো: compiler অনেক হাতের কাজ বাঁচায়, মাপা বাঁচায় না। আর সে যা জমায় তা build ফাইল পড়েই নিশ্চিত হওয়া যায়।

৪ · ভারী তালিকার filter: useDeferredValue আর useTransition

পর্ব ১৪-এ useDeferredValue আর useTransition-এর তুলনা, আর পর্ব ১৫-এ time slicing দেখেছেন। এখন একটি পূর্ণ সমস্যা। “বাজারঘর”-এর খোঁজ বাক্সে টাইপ করলে ২,০০০ পণ্য থেকে ফল বদলায়। মেমো এখানে যথেষ্ট নয়, কারণ প্রতি অক্ষরে props সত্যিই বদলায়। কাজটি অনিবার্য; প্রশ্ন শুধু কখন হবে।

<div id="root"></div>
<script src="../course-kit/vendor/react-lab.js"></script>
<script type="text/jsx">
const names = ['dal', 'chal', 'tel', 'chini'];
const items = Array.from({ length: 100 }, (_, i) => names[i % 4] + '-' + i);
let rows = 0;
function Row({ text }) {               // ইচ্ছা করে ধীর component
  rows++;
  const end = performance.now() + 0.5;
  while (performance.now() < end);
  return <li>{text}</li>;
}
const List = memo(({ q }) =>
  <ul>{items.filter(x => x.includes(q)).map(x => <Row key={x} text={x} />)}</ul>);
const setters = [];
function Box({ defer }) {
  const [text, setText] = useState('');
  const late = useDeferredValue(text);
  setters.push(setText);
  return <><input value={text} onChange={e => setText(e.target.value)} />
    <List q={defer ? late : text} /></>;
}
const type = (set, mark) => { rows = 0;
  for (const t of ['c', 'ch', 'chi']) ReactDOM.flushSync(() => set(t));
  setTimeout(() => console.log(mark, 'Row render:', rows), 150); };
createRoot(document.getElementById('root')).render(
  <div><Box defer={false} /><Box defer={true} /></div>);
setTimeout(() => { type(setters[0], 'সাধারণ'); setTimeout(() => type(setters[1], 'deferred'), 200); }, 200);
</script>

সাধারণ Row render: 125
deferred Row render: 25

এবার আসল build, আসল কী-চাপ: chini, অক্ষরের ফাঁক 100 ms, ২,০০০ পণ্য, প্রতি সারিতে নতুন formatter. একই পরিবেশ, প্রতিটি ধরন ৩ বার চালানো। “সবচেয়ে ধীর কী-চাপ” হলো Event Timing-এর মান। সংখ্যাগুলো এক মেশিনের স্থানীয় মাপ।

দ্বিতীয় সারিটি সতর্কবার্তা। memo ছাড়া useDeferredValue দিলে অবস্থা আরও খারাপ হয়েছে। প্রতিটি অক্ষরে তালিকা দুবার চলেছে: একবার জরুরি render-এ, একবার পেছনে। তাই render প্রায় আড়াই গুণ। React-এর docs-ও বলে, এই কৌশলে memo আবশ্যক। সঠিকভাবে লাগালে long task শূন্যে নেমেছে, যদিও মোট কাজ প্রায় একই। ব্যবহারকারীর কাছে বাক্সটি হালকা থাকে, আর ফল একটু পরে আসে।

Virtualization-এর ছোট স্মরণ: পর্ব ১১-এ হিসাব করেছিলেন, ১০,০০০ সারিতে শুধু ২৫টি আঁকলে ৪০,০০১-এর জায়গায় ১০১টি element থাকে। Virtualization render আর DOM দুটোই কমায়। এখানে যে পদ্ধতি, তা শুধু সময়ে ছড়িয়ে দেয়। দুটি আলাদা হাতিয়ার, একসাথেও চলে। মনে রাখবেন, আঁকা হয়নি এমন সারি ব্রাউজারের Ctrl+F খুঁজে পায় না।

৫ · Code splitting: lazy আর আসল Vite chunk

এতক্ষণ ক্লিকের গতি দেখলাম। এবার পাতা খোলার গতি। অ্যাপের সব কোড এক ফাইলে থাকলে, যিনি শুধু ডাল কিনতে এসেছেন তিনিও অ্যাডমিনের চার্টের কোড নামান। Code splitting কোডকে কয়েকটি chunk-এ ভাগ করে, দরকার হলে তবেই আনে। ঠিক যেন গার্মেন্টসের পুরো গুদাম ট্রাকে না তুলে আজকের অর্ডারটুকু পাঠানো।

React-এ পথ দুটি জিনিসে তৈরি। JavaScript-এর dynamic import (import(), module আর Promise-এর ভিত্তিতে) আর React-এর lazy:

import { lazy } from 'react';

// component-এর বাইরে, ফাইলের ওপরে। default export হতে হবে।
export const Cart = lazy(() => import('./routes/Cart.jsx'));
export const Admin = lazy(() => import('./routes/Admin.jsx'));

React প্রথমবার Admin render করার চেষ্টা করলে তবেই import() চলে, আর ফল জমা থাকে, তাই ফাইল একবারই আসে। lazy component-এর ভেতরে লিখলে প্রতি render-এ নতুন component হয়ে state হারায়। Route-এর সাধারণ ব্যবহার পর্ব ২০-এ, এখানে শুধু bundle-এর প্রভাব।

“বাজারঘর”-এর ছোট সংস্করণ চারটি route নিয়ে build করলাম: হোম, পণ্য, ঝুড়ি, আর recharts (লেখার সময়ে 3.10.1) ব্যবহার করা অ্যাডমিন চার্ট। হোমে ইচ্ছা করেই একটি পরিচিত ভুল রেখেছি: শুধু debounce-এর জন্য পুরো lodash. সত্যিকারের run, Vite 8.3.5, React Router 8.5.1. প্রথমে সব route সাধারণ import-এ:

$ npx vite build
dist/index.html                  0.20 kB │ gzip:   0.16 kB
dist/assets/index-BuZp6n3r.js  665.47 kB │ gzip: 205.62 kB

(!) Some chunks are larger than 500 kB after minification. Consider:
- Using dynamic import() to code-split the application

একই কোড, চারটি route lazy করে:

$ npx vite build
dist/index.html                        0.28 kB │ gzip:  0.21 kB
dist/assets/Product-DKG2zWx5.js        0.19 kB │ gzip:  0.19 kB
dist/assets/Cart-DRcNoLy2.js           0.22 kB │ gzip:  0.21 kB
dist/assets/jsx-runtime-CeWad5y0.js    8.86 kB │ gzip:  3.38 kB
dist/assets/Home-Dg9zIpO4.js          71.69 kB │ gzip: 26.33 kB
dist/assets/index-BFnGO9Mb.js        249.97 kB │ gzip: 79.62 kB
dist/assets/Admin-CQZsPQtG.js        336.04 kB │ gzip: 98.07 kB

ফাইলের নামের মাঝের অংশটি content hash. Admin ও recharts এখন আলাদা, আর হোমে সে আসবেই না। হোমের জন্য নামে index + jsx-runtime + Home = 79.62 + 3.38 + 26.33 = 109.33 kB (gzip), আগে ছিল 205.62 kB. মানে প্রায় ৪৭% কম।

পাতায় আসলে কত সময় বাঁচল?

বাইট কমা আর সময় কমা এক কথা নয়। তাই ঠান্ডা cache-এ মাপলাম। ধরে নেওয়া নেটওয়ার্ক: 150 ms RTT, 200 kB/s (প্রায় 1.6 Mbps); CPU ৪ গুণ ধীর; ৭ বারের মধ্যমা, কয়েক দফা চালানো। স্থানীয় gzip server, এক মেশিনের মাপ।

তিনটি শিক্ষা, প্রতিটি মাপ থেকে এসেছে।

• দাম আছে। অ্যাডমিন চার্ট 160 ms থেকে 840 ms হলো। আগে যে কোড নামানো ছিল, এখন তা ক্লিকের পরে আসে। যে পাতায় প্রায় সবাই যান, সেটি আলাদা করে লাভ কম।
• প্রথম পাতা lazy করবেন না। Home নিজে lazy হলে আগে মূল chunk আসে, চলে, তারপর আরেকটি request. আমাদের মাপে তা প্রায় 380 ms বেশি।
• 25 kB কমলেও সময় বদলায়নি কেন? সারি ২ আর ৩-এ তালিকা প্রায় একই সময়ে এসেছে, অথচ ছোট Home chunk প্রায় 100–150 ms আগে পৌঁছেছিল। সম্ভাব্য কারণ: React-এর docs বলে, লুকানো content সে শেষ প্রকাশের পর অন্তত 300 ms ফাঁকে প্রকাশ করে। আমরা এটি আলাদা করে প্রমাণ করিনি, তাই অনুমান হিসেবেই নিন।

অপেক্ষা কমাতে, ব্যবহারকারী লিংকে আঙুল রাখার আগেই chunk আনা যায়। onPointerEnter-এ একই import() ডাকলেই চলে; ব্রাউজার module জমা রাখে, ক্লিকের সময় আর নামাতে হয় না। মাথায় রাখুন, ফোনে hover নেই, আর ধীর ডেটা-প্যাকে আগাম নামানো গ্রাহকের টাকা খরচ করে।

৬ · Suspense boundary আর skeleton

Suspense একটি অংশকে বলে, “নিচের কেউ অপেক্ষা করলে এই fallback দেখাও।” lazy কোড, আর use-এ পড়া Promise এটিকে চালু করে। মনে রাখুন, Effect-এর ভেতরে করা fetch Suspense টের পায় না। নিচের ব্লকে ৪০০ ms-এর “কোড” আনা সাজানো হয়েছে; লোড হতেই খোলে, বন্ধ হয়, আবার খোলে।

<div id="root"></div>
<script src="../course-kit/vendor/react-lab.js"></script>
<script type="text/jsx">
let loads = 0, toggle;
function CartPage() {
  useEffect(() => { console.log('ঝুড়ির পাতা পর্দায়'); }, []);
  return <p>ঝুড়ির পাতা</p>;
}
const Cart = lazy(() => {
  console.log('chunk আনা শুরু, বার', ++loads);
  return new Promise(done => setTimeout(() => done({ default: CartPage }), 150));
});
function Skeleton() {
  useEffect(() => {
    console.log('skeleton দেখা গেল');
    return () => console.log('skeleton সরল');
  }, []);
  return <div style={{ height: 40, background: '#e2e8f0' }} />;
}
function App() {
  const [open, setOpen] = useState(false);
  toggle = setOpen;
  return <Suspense fallback={<Skeleton />}>{open ? <Cart /> : <p>হোম</p>}</Suspense>;
}
createRoot(document.getElementById('root')).render(<App />);
setTimeout(() => toggle(true), 20);
setTimeout(() => toggle(false), 450);
setTimeout(() => { toggle(true); console.log('আবার খোলা'); }, 500);
</script>

chunk আনা শুরু, বার 1
skeleton দেখা গেল
skeleton সরল
ঝুড়ির পাতা পর্দায়
আবার খোলা
ঝুড়ির পাতা পর্দায়

Skeleton হলো পাতার ধূসর কাঠামো। ঘুরন্ত spinner শুধু বলে “অপেক্ষা করুন”; skeleton বলে “এখানে এমন কিছু আসছে”। আকার আসল content-এর সমান রাখলে পাতা লাফায় না, মানে CLS বাড়ে না। Boundary-র জায়গাটিই আসল নকশা। ধরুন পণ্যের পাতা: শিরোনাম আর দাম আগে, রিভিউ পরে।

<Suspense fallback={<PageSkeleton />}>
  <ProductInfo />                       {/* একসাথে আসে */}
  <BuyBox />
  <Suspense fallback={<ReviewsSkeleton />}>
    <Reviews />                         {/* ধীর হলেও ওপরেরটা আটকায় না */}
  </Suspense>
</Suspense>

একই boundary-র ভাইবোনেরা একসাথে আসে। প্রতিটি component-এ আলাদা boundary দিলে পাতায় একের পর এক ঝলক লাগে। Boundary বসান ব্যবহারকারীর দেখার ক্রম অনুযায়ী, কোডের গঠন অনুযায়ী নয়।

আসল run-এর একটি চমক: fallback দেখা গেল না

আগের মাপে অ্যাডমিন ক্লিকে একবারও “লোড হচ্ছে…” পর্দায় আসেনি, পুরো 840 ms পুরোনো পাতা ঝুলে ছিল। কারণ BrowserRouter navigation startTransition-এ মোড়ে, আর transition আগে দেখানো content লুকায় না। React-এর এই আচরণ নথিবদ্ধ। সমাধানও নথিতে: ভিন্ন content হলে boundary-তে key দিন। key বদলালে সেটি নতুন boundary, তাই fallback সঙ্গে সঙ্গে আসে। আমাদের run-এ fallback এল ক্লিকের প্রায় 16–24 ms পরে।

function Page({ children }) {
  const { pathname } = useLocation();
  return <Suspense key={pathname} fallback={<PageSkeleton />}>{children}</Suspense>;
}

কোনটি ভালো, তা পাতার ওপর নির্ভর করে। দ্রুত chunk-এ পুরোনো পাতা ধরে রাখলে ঝলক কম হয়। ধীর নেটওয়ার্কে কিছু না দেখালে মানুষ ভাবেন ক্লিক হয়নি। তখন skeleton বা ওপরের সরু লোডিং-রেখা ভালো।

URL বদলাল: /admin
React নতুন route render করছে

<Admin /> → lazy → load() প্রথমবার ডাকা হলো
Promise এখনো pending
নিকটতম Suspense খোঁজা শুরু

মেনু       থাকল
PageSkeleton দেখা গেল
হোম পাতা সরে গেল

GET Admin-CQZsPQtG.js
Body 97,095 bytes (gzip)
এক run-এ সময়: 656 ms

Promise resolved, .default = Admin
React আবার render করল
Skeleton সরে চার্ট এল
পরের ক্লিকে: chunk আর আনতে হবে না

৭ · Error boundary: একটি অংশ ভাঙলে পুরো দোকান নয়

Suspense অপেক্ষা সামলায়, error boundary ব্যর্থতা সামলায়। React-এর docs স্পষ্ট বলে, render-এর সময় error হলে এবং কেউ না ধরলে React তার UI পর্দা থেকে সরিয়ে দেয়। মানে রিভিউর একটি ছোট ভুলে পুরো “বাজারঘর” সাদা পাতা। ক্রেতার ঝুড়ি, মেনু, কিছুই থাকে না।

Boundary আজও class component ছাড়া লেখা যায় না। Docs অনুযায়ী এর function সংস্করণ নেই। দুটি method নিয়ে এটি হয়:

<div id="root"></div>
<script src="../course-kit/vendor/react-lab.js"></script>
<script type="text/jsx">
class Boundary extends Component {
  state = { error: null };
  static getDerivedStateFromError(error) { return { error }; }
  componentDidCatch(error) {
    console.log(this.props.name, 'ধরেছে:', error.message);
  }
  render() {
    if (this.state.error) return <p>{this.props.name}: দেখানো গেল না</p>;
    return this.props.children;
  }
}
function Reviews({ list }) {
  return <p>গড় রেটিং {list.length}</p>;   // list না এলে throw
}
function Page() {
  return (
    <Boundary name="পাতা">
      <h3>মসুর ডাল</h3>
      <Boundary name="রিভিউ"><Reviews /></Boundary>
      <button>ঝুড়িতে যোগ করুন</button>
    </Boundary>
  );
}
createRoot(document.getElementById('root'), { onCaughtError() {} }).render(<Page />);
setTimeout(() => console.log('পর্দা:', document.getElementById('root').innerText), 50);
</script>

রিভিউ ধরেছে: Cannot read properties of undefined (reading 'length')
পর্দা: মসুর ডাল

রিভিউ: দেখানো গেল না

ঝুড়িতে যোগ করুন

App
├ Nav
└ Boundary[পাতা]
  └ ProductPage
    ├ ProductInfo   ✓
    ├ Boundary[রিভিউ]
    │ └ Reviews   ← এখন চলছে
    └ BuyBox

Boundary[রিভিউ]
└ Reviews
  TypeError: reading 'length'
এই render বাতিল, DOM এখনো বদলায়নি

Reviews          boundary নয়
Boundary[রিভিউ]  ✓ এটিই নিকটতম
Boundary[পাতা]   খোঁজা হলো না

getDerivedStateFromError(error)
→ state = { error }
→ render(): <p>রিভিউ: দেখানো গেল না</p>

ProductInfo   ✓ আছে
“রিভিউ: দেখানো গেল না”
BuyBox        ✓ আছে
componentDidCatch → log পাঠানো

Reviews → Boundary[পাতা]
পুরো পাতার fallback
Nav          ✓ টিকে থাকে
কোনো boundary না থাকলে: পুরো অ্যাপ পর্দা থেকে সরে যেত

react-error-boundary আর route-প্রতি সহনশীলতা

নিজে class না লিখে অনেকে react-error-boundary (লেখার সময়ে 6.1.6) নেন; React-এর docs-ও এটিকে উদাহরণ হিসেবে উল্লেখ করে। এটি বাধ্যতামূলক নয়, আপনার ছোট class-ও একই কাজ করে। বেছে নেওয়া সুবিধার প্রশ্ন, আর API version ধরে বদলাতে পারে, তাই নিজের version-এর নথি দেখুন। ৬ নম্বর version শুধু ES Module-এ আসে।

import { ErrorBoundary, getErrorMessage } from 'react-error-boundary';

function RouteError({ error, resetErrorBoundary }) {
  return (
    <div role="alert">
      <p>পাতাটি দেখানো গেল না: {getErrorMessage(error)}</p>
      <button onClick={resetErrorBoundary}>আবার চেষ্টা করুন</button>
    </div>
  );
}
export function RouteShell({ children }) {
  const { pathname } = useLocation();
  return (
    <ErrorBoundary FallbackComponent={RouteError} resetKeys={[pathname]}
      onError={(error, info) => reportError(error, info)}>
      <Suspense key={pathname} fallback={<PageSkeleton />}>{children}</Suspense>
    </ErrorBoundary>
  );
}

resetKeys-এ pathname দিলে অন্য route-এ গেলে error মুছে যায়, ব্যবহারকারী আটকে থাকেন না। reportError এখানে আপনার নিজের log ফাংশনের নাম। কোনো গোপন তথ্য বা পূর্ণ error ব্যবহারকারীকে দেখানো ঠিক নয়; আসল অ্যাপে সাধারণ বার্তা দিন, বিস্তারিত log-এ পাঠান।

Chunk নামতে ব্যর্থ হলে: একটি আসল ফাঁদ

lazy-র Promise reject হলে React সেটি নিকটতম error boundary-তে throw করে। নেটওয়ার্ক কাটলে, অথবা নতুন deploy-এ পুরোনো chunk মুছে গেলে এমন হয়। ফাঁদটি “আবার চেষ্টা করুন” বোতামে। আমরা Report chunk-এর প্রথম request ইচ্ছা করে ব্যর্থ করে পরীক্ষা করলাম। সত্যিকারের run, Edge 156, Vite 8.3.5 build, react-error-boundary 6.1.6. নিচে ফল সংক্ষেপে সাজানো, বাংলা লাইনগুলো আমাদের script-এর:

vite:preloadError fired
onError: Failed to fetch dynamically imported module: …/assets/Report-BXfUWlhL.js
মেনু: মেনু ঠিক আছে               ← boundary কাজ করেছে
নেটওয়ার্ক ফিরল, "আবার চেষ্টা" চাপা হলো:
report পর্দায়? 0   একই error    server-এ request: মোট 1
reset-এ নতুন lazy() বানিয়ে আবার চেষ্টা:
report পর্দায়? 0   একই error    server-এ request: মোট 1
পাতা reload করে:
report পর্দায়? 1

দুটি জিনিস ব্যর্থ ফল মনে রেখেছে। lazy নিজের Promise জমা রাখে, তাই reset-এ কিছু বদলায় না। আর নতুন lazy() বানিয়েও এই browser-এ request-ই যায়নি: একই URL-এর ব্যর্থ import() সে আগের ফলই দিয়েছে। Abort আর 404, দুই ক্ষেত্রেই একই ফল। অর্থাৎ এই ক্ষেত্রে আমাদের পরীক্ষায় সৎ সমাধান ছিল পাতা reload.

Vite-এর docs এজন্য vite:preloadError ইভেন্ট দেয়, আর উদাহরণে পাতা reload করে। একটি সতর্কতা যোগ করুন: chunk সত্যিই না থাকলে reload-এর চক্র চলতে পারে, তাই sessionStorage-এ একবারের চিহ্ন রাখা ভালো। Vite HTML-এ Cache-Control: no-cache রাখতেও বলে, নইলে পুরোনো HTML পুরোনো chunk খুঁজবে।

window.addEventListener('vite:preloadError', () => {
  if (sessionStorage.getItem('chunk-reloaded')) return;  // একবারই
  sessionStorage.setItem('chunk-reloaded', '1');
  window.location.reload();
});

৮ · ছবি: প্রায়ই সবচেয়ে বড় বোঝা

অনলাইন দোকানে সবচেয়ে বেশি বাইট অনেক সময় JavaScript নয়, ছবি। “বাজারঘর”-এর হোমের বড় ব্যানার সম্ভবত LCP element. ছবির ভিত্তি আছে responsive images পর্বে; এখানে React-এ চারটি নিয়ম।

// ওপরের ব্যানার: LCP-র প্রার্থী
<img src="/img/banner-800.webp"
     srcSet="/img/banner-400.webp 400w, /img/banner-800.webp 800w"
     sizes="100vw" width="800" height="400"
     alt="ঈদের বিশেষ ছাড়" fetchPriority="high" />

// তালিকার নিচের দিকের ছবি
<img src={p.thumb} width="200" height="200" alt={p.name}
     loading="lazy" decoding="async" />

• LCP ছবিতে loading="lazy" নয়। এটি সবচেয়ে প্রচলিত ভুল। AI প্রায়ই সব ছবিতে বসিয়ে দেয়, আর আসল ছবিটিই দেরি করে।
• fetchpriority শুধু ১–২টি ছবিতে। সবাইকে জরুরি বললে কেউ জরুরি নয়। স্বাভাবিক ছবিতে attribute-টি বাদ দিন। JSX-এ লিখুন fetchPriority.
• width আর height দিন। ব্রাউজার আগে থেকে জায়গা রাখে, তাই পাতা লাফায় না।
• srcset দিন। ব্রাউজার পর্দা অনুযায়ী মাপ বাছে। WebP বা AVIF-ও বিবেচনা করুন।

হিসাব: ৩৬০ CSS px চওড়া ফোন, device pixel ratio ২, মানে দরকার ৭২০ px চওড়া ছবি। আপনি পাঠালেন ১৬০০ px. পিক্সেল বেশি (১৬০০ ÷ ৭২০)² ≈ ৪.৯ গুণ। ধরে নিই ১৬০০ px ছবি 400 kB আর ৭২০ px ছবি 90 kB. 200 kB/s-এ 2 s বনাম 0.45 s. শুধু এই একটি ছবিতেই আমাদের পুরো JavaScript-এর চেয়ে বড় ক্ষতি। ছবির সাইজগুলো ধরে নেওয়া, মাপা নয়। Next.js-এর image component আর অন্যান্য বিষয় পর্ব ৮৪-এ।

৯ · Bundle বিশ্লেষণ আর ধীর ফোনের বাজেট

Build-এর শেষে শুধু chunk-এর আকার দেখা যায়, ভেতরে কী আছে তা নয়। rollup-plugin-visualizer (লেখার সময়ে 7.1.1) একটি treemap বানায়: প্রতিটি module একটি বাক্স, বড় বাক্স মানে বড় কোড। Vite 8-এর সাথেও আমাদের run-এ এটি চলেছে।

import { visualizer } from 'rollup-plugin-visualizer';

export default defineConfig({
  plugins: [react(), visualizer({ filename: 'stats.html', gzipSize: true })],
});

npx vite build চালালে stats.html তৈরি হয়, ব্রাউজারে খুলুন। এখানে একই ডেটা template: 'raw-data' দিয়ে JSON-এ নিয়ে package ধরে যোগ করেছি। সত্যিকারের run, বড়গুলো (rendered মানে minify-এর আগের আকার, তাই build-এর লাইন থেকে বড়):

assets/index-BFnGO9Mb.js
   react-dom      524.1 kB rendered    99.0 kB gz
   react-router    80.3 kB rendered    24.3 kB gz
   scheduler        9.0 kB rendered     2.4 kB gz
assets/Home-Dg9zIpO4.js
   lodash         177.2 kB rendered    38.3 kB gz
   (app src)        0.9 kB rendered     0.5 kB gz
assets/Admin-CQZsPQtG.js
   recharts       469.0 kB rendered   149.0 kB gz
   es-toolkit      30.0 kB rendered    13.6 kB gz
   d3-scale        26.6 kB rendered    10.1 kB gz

ধরা পড়ল। Home-এর নিজের কোড 0.9 kB, অথচ lodash 177 kB, একটি ছোট debounce-এর জন্য। import _ from 'lodash' পুরো library আনে, কারণ tree shaking এই CommonJS-ধাঁচের package থেকে অব্যবহৃত অংশ বাদ দিতে পারে না। পর্ব ১৪-এর মতো তিন লাইনের নিজের debounce দিতেই Home chunk 26.33 kB থেকে 0.42 kB (gzip) হলো। React আর router-এর 80 kB সব পাতায় লাগবেই, এটিই ভিত্তির খরচ।

হিসাব করা বাজেট

“দ্রুত করুন” কোনো লক্ষ্য নয়। Performance budget হলো সংখ্যায় লেখা সীমা। ধরুন লক্ষ্য: ধীর ফোনে ৩ সেকেন্ডে প্রথম পাতা কাজের। এখানে সব সংখ্যা ধরে নেওয়া।

1. নেটওয়ার্ক 200 kB/s, RTT 150 ms. সংযোগে ৩ RTT আর HTML-এ ১ RTT: ৪ × 150 = 600 ms. বাকি 3000 − 600 = 2400 ms.
2. নামানোর খরচ: 1 kB ÷ 200 kB/s = 5 ms/kB.
3. চালানোর খরচ: আমাদের run-এ 203 kB gzip-এর chunk পৌঁছানোর প্রায় 200 ms পর তালিকা এল, ≈ 1 ms/kB (৪ গুণ ধীর CPU). আসল সস্তা ফোন আরও ধীর হতে পারে, তাই নিরাপত্তার জন্য ধরি 3 ms/kB.
4. মোট 8 ms/kB, তাই 2400 ÷ 8 = 300 kB সব সম্পদ মিলিয়ে।
5. অর্ধেক ছবি, CSS আর font-এর জন্য রাখলে প্রথম পাতার JavaScript 150 kB (gzip).

আমাদের 82 kB-র build এই সীমার ভেতরে। প্রথম 205 kB-র build বাইরে ছিল। তবে 3 ms/kB একটি অনুমান, তাই নিজের লক্ষ্য ফোনে মেপে সংখ্যাটি বসান।

প্রকাশের আগের তালিকা

• Production build-এ, ৪ গুণ ধীর CPU-তে প্রধান তিনটি কাজ মেপেছি
• Input-এর state নিচে নামিয়েছি; অকারণে পুরো পাতা render হয় না
• Render-এর ভেতরে formatter, বড় sort বা ভারী হিসাব নেই
• memo শুধু মাপা জায়গায়, আর তার props স্থির
• ভারী filter-এ useDeferredValue + memo; network-এ debounce
• শত শত সারি হলে pagination বা virtualization
• ভারী, কম-ব্যবহৃত route lazy; প্রথম পাতা সরাসরি import
• প্রতি route-এ error boundary আর Suspense; মেনু তার বাইরে
• Chunk ব্যর্থ হলে reload-এর পথ আছে; HTML no-cache
• LCP ছবি lazy নয়; সব ছবিতে width, height, alt
• Visualizer চালিয়ে বাড়তি package ছেঁটেছি
• আসল গ্রাহকের INP আর LCP মাপার ব্যবস্থা আছে

১০ · AI-এর যুগে: performance কোড মেপে নিন

AI performance পরামর্শে খুব আত্মবিশ্বাসী, আর কথাগুলো শুনতে ঠিক লাগে। কিন্তু AI আপনার গ্রাহকের ফোন দেখে না। এই পর্বের প্রতিটি শিক্ষা একটি মাপ থেকে এসেছে, আর অন্তত দুটি মাপ অনুমান ভেঙেছে। AI-এর পরামর্শকেও একইভাবে পরীক্ষা করুন।

AI-এর performance বদল নেওয়ার আগে

• একই কাজ, একই build-এ বদলের আগে ও পরে মেপেছি, একবার নয়, কয়েকবার
• API আর option আমার version-এর official docs-এ আছে
• নতুন package সত্যিই আছে, বিশ্বস্ত, আর bundle কতটা বাড়াল দেখেছি
• Error boundary কোনো error চুপচাপ গিলে ফেলছে না; log যাচ্ছে
• Client bundle-এ কোনো secret ঢোকেনি; fallback-এ ভেতরের তথ্য নেই
• Diff পড়েছি, আর গুরুত্বপূর্ণ আচরণের জন্য একটি test লিখেছি