Hydration — server থেকে client-এ, mismatch আর খরচ

১ · Hydration কী: ছবির মতো পাতায় প্রাণ জোড়া

পর্ব ০৩-এ rendering-এর মানচিত্র দেখেছেন: CSR, SSR, SSG আর মাঝখানে hydration-এর একটি ছোট ঝলক। পর্ব ৫২-তে server আর client component-এর ভাগ, আর পর্ব ৫৫-তে কোন পাতা কখন তৈরি হয়, সেটি আলাদা পর্বে আছে। এই পর্বে আমরা ঠিক জোড়ার জায়গাটিতে নামব: HTML পৌঁছানোর পর ব্রাউজারে কী ঘটে, কোথায় ভাঙে, আর কত খরচ হয়।

যান্ত্রিকভাবে তিনটি ধাপ। প্রথমে server component tree চালিয়ে HTML বানায়, যেমন <button>কার্টে যোগ (0)</button>. HTML-এ শুধু চেহারা থাকে; onClick-এর function HTML-এ লেখা যায় না। দ্বিতীয়ত, ব্রাউজার HTML আঁকে, আর পাশাপাশি JavaScript নামায়। তৃতীয়ত, JavaScript চলে, React একই component আবার render করে। তবে এবার নতুন DOM বানায় না। পর্দায় যে DOM আছে, তার প্রতিটি node-এর সাথে নিজের element মেলায়, আর মিলে গেলে সেই node-এ handler জোড়ে।

React-এ এই কাজের API হলো hydrateRoot, যা react-dom/client থেকে আসে। পর্ব ০৭ থেকে যে createRoot চেনেন, সেটি খালি জায়গায় নতুন DOM বানায়। hydrateRoot আগে থেকে থাকা DOM গ্রহণ করে।

import { hydrateRoot } from 'react-dom/client';
import App from './App';

const root = hydrateRoot(document.getElementById('root'), <App />, {
  onRecoverableError(error, info) {
    // React নিজে সামলেছে, তবু বাগ: log পাঠান
    reportToServer(error.message, info.componentStack);
  },
});

react.dev অনুযায়ী স্বাক্ষর hydrateRoot(domNode, reactNode, options?). Option-এর মধ্যে onRecoverableError গুরুত্বপূর্ণ: React নিজে থেকে কোনো error সামলে নিলে এটি ডাকা হয়, আর hydration mismatch ঠিক এই দলে পড়ে। identifierPrefix server আর client-এ এক হতে হয়, কারণ পর্ব ১৪-এর useId দুই দিকে একই id বানাতে এটি ব্যবহার করে। Next.js-এ এই ফাইল আপনি লেখেন না; framework নিজেই hydrateRoot ডাকে। কিন্তু আচরণটি একই, তাই ভেতরটা জানা দরকার।

২ · মৃত মুহূর্ত: ধীর CPU-তে মাপা

কথায় নয়, মেপে দেখি। আমরা “বাজারঘর”-এর একটি পণ্যের পাতা বানালাম: জামদানি শাড়ি, দাম, একটি “কার্টে যোগ” বোতাম আর ৬০০টি রিভিউ। সত্যিকারের run: Next.js 16.4.4, React 19.3.1, next build তারপর next start, ব্রাউজার Microsoft Edge, Playwright দিয়ে চালানো। Chrome DevTools Protocol দিয়ে CPU ৬ গুণ ধীর, আর নেটওয়ার্ক 150 ms latency ও 1.6 Mbps. প্রতিবার নতুন context, তাই cache খালি। Script পাতা খোলার সাথে সাথে বোতামে বারবার ক্লিক করে, যতক্ষণ না সংখ্যা বাড়ে।

$ python measure.py 6 net
/product  CPU 6x throttle, net=150ms/1.6Mbps, 5 runs (median)
  first-contentful-paint : 520 ms
  hydrated (effect ran)  : 1360 ms
  long tasks run 1       : [[1079, 196], [1282, 114]]
  first successful click : 1418 ms
  clicks lost before that: [11, 14, 14, 10, 10]
  HTML transfer/decoded  : 16811 / 249956 bytes
  JS files, transfer/decoded: 6, 137277 / 457458 bytes
  each run fcp/click: [(496, 1418), (496, 1432), (520, 1408), (520, 1404), (576, 1459)]

এটি একটি local run, সাধারণ ফল নয়; আপনার যন্ত্রে সংখ্যা আলাদা হবে। তবু ছবিটি পরিষ্কার। পাঁচবারের মধ্যমায় প্রথম লেখা পর্দায় আসে 520 ms-এ, যাকে বলে FCP. Component-এর useEffect-এ রাখা performance.mark('hydrated') চলে 1360 ms-এ। প্রথম সফল ক্লিক 1418 ms-এ। প্রায় 900 ms ধরে বোতাম দেখা যায়, কিন্তু কাজ করে না। এই সময়ে আমাদের script প্রতিটি run-এ ১০ থেকে ১৪ বার ক্লিক করেছে, একটিও গোনা হয়নি।

Long task-এর তালিকা দেখুন: 1079 ms-এ শুরু হয়ে 196 ms চলা একটি, আর 1282 ms-এ 114 ms-এর আরেকটি। JavaScript নামা শেষ হলে main thread এই সময়ে parse, চালানো আর hydration-এ ব্যস্ত। এর আগে thread প্রায় ফাঁকা ছিল, কিন্তু তখন বোতামে কোনো listener-ই ছিল না।

হারানো ক্লিক বনাম লাইনে দাঁড়ানো ক্লিক

একই পাতা নেটওয়ার্ক ধীর না করে, শুধু CPU ৬ গুণ ধীর করে চালালাম। তখন clicks lost হলো [0, 0, 0, 0, 0]. প্রথম ক্লিকটিই শেষ পর্যন্ত কাজ করেছে, যদিও দেরিতে। কারণ JavaScript দ্রুত এসেছে, ক্লিক পড়েছে এমন সময়ে যখন main thread hydration-এ ব্যস্ত। ব্রাউজার ব্যস্ত thread-এর জন্য input event লাইনে রাখে, task শেষ হলে পাঠায়। ততক্ষণে React handler জুড়ে ফেলেছে।

অর্থাৎ hydration-এর আগে ক্লিকের তিন রকম ভাগ্য হতে পারে। নিচের ব্লকটি একটি শিক্ষণ মডেল: সংখ্যাগুলো ওপরের run থেকে নেওয়া, গোল করা।

// শিক্ষণ মডেল: hydration-এর আগে ক্লিকের ভাগ্য (সময় ms-এ)
// সংখ্যাগুলো একটি local run-এর মধ্যমা থেকে নেওয়া, গোল করা
const t = { paint: 520, rootAttached: 1080, hydrated: 1360 };
const busy = [[1080, 1280], [1280, 1360]];   // long task: [শুরু, শেষ]
function busyUntil(ms) {
  const task = busy.find(([s, e]) => ms >= s && ms < e);
  return task ? task[1] : ms;
}
function fate(click) {
  if (click.at < t.paint) return 'পাতা তখনো সাদা, বোতামই নেই';
  if (click.at < t.rootAttached) {
    return click.native ? 'browser নিজে চালাল (link বা form)' : 'হারিয়ে গেল: listener নেই';
  }
  const start = busyUntil(click.at);           // ব্যস্ত থাকলে event লাইনে দাঁড়ায়
  const handled = Math.max(start, t.hydrated);  // React hydrate শেষে replay করে
  if (handled === click.at) return 'সঙ্গে সঙ্গে handler চলল';
  return `লাইনে ছিল, handler চলল ${handled} ms-এ (দেরি ${handled - click.at} ms)`;
}
const clicks = [
  { at: 300, what: 'কার্টে যোগ' },
  { at: 700, what: 'কার্টে যোগ' },
  { at: 900, what: 'পণ্যের link', native: true },
  { at: 1150, what: 'কার্টে যোগ' },
  { at: 1300, what: 'কার্টে যোগ' },
  { at: 1500, what: 'কার্টে যোগ' },
];
for (const c of clicks) console.log(`${String(c.at).padStart(4)} ms  ${c.what}: ${fate(c)}`);
console.log(`\nক্লিক হারায়: ${t.paint}–${t.rootAttached} ms (${t.rootAttached - t.paint} ms)`);
console.log(`ক্লিক দেরিতে চলে: ${t.rootAttached}–${t.hydrated} ms (${t.hydrated - t.rootAttached} ms)`);

 300 ms  কার্টে যোগ: পাতা তখনো সাদা, বোতামই নেই
 700 ms  কার্টে যোগ: হারিয়ে গেল: listener নেই
 900 ms  পণ্যের link: browser নিজে চালাল (link বা form)
1150 ms  কার্টে যোগ: লাইনে ছিল, handler চলল 1360 ms-এ (দেরি 210 ms)
1300 ms  কার্টে যোগ: লাইনে ছিল, handler চলল 1360 ms-এ (দেরি 60 ms)
1500 ms  কার্টে যোগ: সঙ্গে সঙ্গে handler চলল

ক্লিক হারায়: 520–1080 ms (560 ms)
ক্লিক দেরিতে চলে: 1080–1360 ms (280 ms)

৩ · Mismatch: Next.js dev-এর আসল error

Hydration-এর চুক্তি ভাঙলে কী হয়, দেখতে আমরা ছয়টি ছোট পাতা বানালাম। প্রতিটি একটি client component, কারণ server component ব্রাউজারে আবার চলে না, তাই তার ভেতরে এই সমস্যা এভাবে আসে না। সত্যিকারের run: Next.js 16.4.4 next dev (Turbopack), Edge-এ locale bn-BD আর time zone Asia/Dhaka. Console থেকে ধরা error নিচে; Next.js-এর ভেতরের লম্বা component stack “…” দিয়ে ছাঁটা।

'use client';
export default function Clock() {
  return <p>এখন: {Date.now()}</p>;
}

Hydration failed because the server rendered text didn't match the client. As a result this tree will be regenerated on the client. This can happen if a SSR-ed Client Component used:

- A server/client branch `if (typeof window !== 'undefined')`.
- Variable input such as `Date.now()` or `Math.random()` which changes each time it's called.
- Date formatting in a user's locale which doesn't match the server.
- External changing data without sending a snapshot of it along with the HTML.
- Invalid HTML tag nesting.

It can also happen if the client has a browser extension installed which messes with the HTML before React loaded.

https://react.dev/link/hydration-mismatch

  …
                        <Page>
                          <Clock>
                            <p>
+                             1793640742674
-                             1793640742507
  …

বার্তাটি পড়তে শিখুন। প্রথম লাইন বলে কী মেলেনি (text) আর React কী করেছে: this tree will be regenerated on the client, মানে মেলেনি এমন অংশ client-এ নতুন করে বানানো হয়েছে। নিচের diff-এ + মানে client যা বানাল, - মানে server-এর HTML-এ যা ছিল। দুটি সময়ের পার্থক্য 167 ms: server-এর render আর ব্রাউজারের render-এর মাঝের সময়। Diff-এর ওপরের component-এর পথ (Page → Clock → p) বলে দেয় কোন ফাইল খুলবেন।

বাকি পাঁচটি পাতার diff-এর মূল অংশ এক টেবিলে। প্রতিটি সারি একই run-এর।

কয়েকটি সারি আলাদা করে বোঝা দরকার।

Locale. toLocaleString()-এ locale না দিলে চলমান পরিবেশের ডিফল্ট নেয়। আমাদের Node server-এর ডিফল্ট en-US, তাই 1,250; Edge-এর locale bn-BD, তাই ১,২৫০. একই কোড, দুই রকম অঙ্ক।

Time zone. এখানে locale দুই দিকেই bn-BD, বাংলা অঙ্কও দুই দিকে এসেছে। তবু মেলেনি, কারণ server-কে TZ=UTC দিয়ে চালিয়েছিলাম, যেমন অনেক cloud server চলে। একই মুহূর্ত (2026-11-02T20:30:00Z) UTC-তে ২ নভেম্বর রাত সাড়ে আটটা, ঢাকায় ৩ নভেম্বর রাত আড়াইটা। তারিখই বদলে গেছে। Bangla অঙ্ক নিয়ে বিস্তারিত পর্ব ৫৯-এ।

HTML nesting. <p>-এর ভেতরে <div> HTML-এর নিয়মে বৈধ নয়। Server যে HTML পাঠিয়েছে, তাতে লেখা ছিল <p>পণ্যের বিবরণ<div>…</div></p>. কিন্তু ব্রাউজারের HTML parser <div> দেখেই <p> বন্ধ করে দেয়, আর শেষের </p> থেকে একটি খালি <p> বানায়। DOM আর React-এর tree তাই আলাদা। প্রথম বার্তাটি dev-এর সতর্কতা; Playwright যেভাবে ধরেছে সেভাবেই দেখানো, যেখানে %s-এর জায়গার মানগুলো শেষে বসেছে। HTML-এর বিষয়বস্তুর নিয়ম HTML ও CSS কোর্সে আছে।

Browser extension. এখানে আমরা একটি সত্যিকারের extension চালাইনি। Playwright-এর init script দিয়ে React আসার আগেই <body>-এ একটি attribute বসিয়েছি, যেমন কিছু লেখা-সংশোধনের extension করে বলে জানা যায়। এবার বার্তা আলাদা: A tree hydrated, মানে hydration চলেছে, শুধু attribute মেলেনি, আর This won't be patched up, মানে React বাড়তি attribute সরাবে না। আপনার কোডে বাগ নেই, কিন্তু ব্যবহারকারীর ব্রাউজারে এই বার্তা আসবে।

Production-এ কী দেখায়

একই পাতা next build আর next start-এ চালালে বার্তা ছোট হয়ে যায়, কারণ production React-এ লম্বা বার্তা ফেলে দেওয়া থাকে:

Minified React error #418; visit https://react.dev/errors/418?args[]=text&args[]= for the full message or use the non-minified dev environment for full errors and additional helpful warnings.

আরেকটি চমক: build-এর route তালিকায় /date ছিল ○ (Static). মানে HTML build-এর সময়েই তৈরি। Server-এর HTML-এ সংখ্যাটি 1793641069503, ব্রাউজারে 1793641097552: পার্থক্য প্রায় ২৮ সেকেন্ড, কারণ build আর পাতা খোলার মাঝে ততটা সময় গেছে। আসল সাইটে এই পার্থক্য দিন বা মাস হতে পারে। Static পাতায় “এখন” মানে “build-এর সময়”, এটি পর্ব ৫৫-এর বিষয়ের সাথে জড়িত।

শিক্ষণ মডেল: React কী মেলায়

এই কোর্সের live React ব্লকে createRoot আছে, hydrateRoot export করা নেই। তাই নিচে একটি ছোট JavaScript মডেল: একই render function দুই পরিবেশে চলে, server-এর ফল HTML string হয়, আর “hydrate” সেই string-এর প্রতিটি node-এর লেখা client-এর লেখার সাথে মেলায়। আসল React element-এর ধরন, attribute আর আরও অনেক কিছু দেখে; এখানে শুধু লেখা।

// শিক্ষণ মডেল: server HTML আর client-এর প্রথম render মেলানো
function render(env) {
  return [
    { tag: 'h1', text: 'জামদানি শাড়ি' },
    { tag: 'p', text: 'দাম: ' + env.fmt(4500) },
    { tag: 'p', text: 'বানিয়েছে: ' + env.where },
  ];
}
function toHtml(tree) {
  return tree.map(n => `<${n.tag}>${n.text}</${n.tag}>`).join('');
}
function hydrate(html, tree) {
  const dom = [...html.matchAll(/<(\w+)>(.*?)<\/\1>/g)]
    .map(m => ({ tag: m[1], text: m[2] }));
  for (let i = 0; i < tree.length; i++) {
    if (dom[i].text !== tree[i].text) {
      console.log(`  node ${i} <${tree[i].tag}> mismatch`);
      console.log('  + client: ' + tree[i].text);
      console.log('  - server: ' + dom[i].text);
      return 'tree regenerated on client';
    }
    console.log(`  node ${i} <${tree[i].tag}> ok`);
  }
  return 'hydrated, handlers attached';
}
const en = n => n.toLocaleString('en-US');
const bn = n => n.toLocaleString('bn-BD');
console.log('১) server-এ en-US, browser-এ bn-BD:');
const html1 = toHtml(render({ fmt: en, where: 'server' }));
console.log('  →', hydrate(html1, render({ fmt: bn, where: 'browser' })));
console.log('২) দুই দিকে একই locale, একই লেখা:');
const html2 = toHtml(render({ fmt: bn, where: 'বাজারঘর' }));
console.log('  →', hydrate(html2, render({ fmt: bn, where: 'বাজারঘর' })));

১) server-এ en-US, browser-এ bn-BD:
  node 0 <h1> ok
  node 1 <p> mismatch
  + client: দাম: ৪,৫০০
  - server: দাম: 4,500
  → tree regenerated on client
২) দুই দিকে একই locale, একই লেখা:
  node 0 <h1> ok
  node 1 <p> ok
  node 2 <p> ok
  → hydrated, handlers attached

৪ · সমাধান: আগে একই জিনিস, তারপর client-এর জন্য আলাদা ধাপ

দর্জির কথা ভাবুন। দোকানে মাপ নিয়ে কাপড় কাটা হলো (server), বাড়িতে গিয়ে আরেকজন একই মাপের খাতা দেখে সেলাই করবেন (client), এমন ব্যবস্থা। খাতায় যদি “আজকের তারিখ অনুযায়ী লম্বা” লেখা থাকে, দুই দিন দুই রকম ফল আসবে। ভালো খাতায় মাপ নির্দিষ্ট সংখ্যায় লেখা থাকে। Mismatch-এর সমাধানও সেই ক্রমে ভাবুন।

চারটি পথ একটি পাতায় একসাথে চালালাম। সত্যিকারের run, Next.js 16.4.4. পাতার client component:

'use client';
import { useEffect, useState, useSyncExternalStore } from 'react';
import dynamic from 'next/dynamic';

const MapWidget = dynamic(() => import('./MapWidget'), {
  ssr: false,
  loading: () => <p>ম্যাপ লোড হচ্ছে…</p>,
});

function subscribe(cb) {
  window.addEventListener('online', cb);
  window.addEventListener('offline', cb);
  return () => {
    window.removeEventListener('online', cb);
    window.removeEventListener('offline', cb);
  };
}

export default function Fixes() {
  const [now, setNow] = useState(null);
  useEffect(() => { setNow(Date.now()); }, []);
  const online = useSyncExternalStore(subscribe, () => navigator.onLine, () => true);
  return (
    <div>
      <p>এখন: {now === null ? '—' : now}</p>
      <p suppressHydrationWarning>রেন্ডারের সময়: {Date.now()}</p>
      <p>নেটওয়ার্ক: {online ? 'অনলাইন' : 'অফলাইন'}</p>
      <MapWidget />
    </div>
  );
}

MapWidget সরাসরি window.innerWidth পড়ে, যা server-এ নেই। Production build-এর HTML থেকে <body>-এর অংশ (script বাদে):

<div><p>এখন: <!-- -->—</p><p>রেন্ডারের সময়: <!-- -->1793641069482</p><p>নেটওয়ার্ক: <!-- -->অনলাইন</p><!--$!--><template data-dgst=""></template><p>ম্যাপ লোড হচ্ছে…</p><!--/$--></div>

আর hydration-এর পরে পর্দায়, কোনো error ছাড়া:

এখন: 1793640766588
রেন্ডারের সময়: 1793640766589
নেটওয়ার্ক: অনলাইন
ম্যাপ: পর্দার প্রস্থ 1280px

চারটি লাইন, চারটি শিক্ষা। প্রথম লাইনে server আর hydration দুই জায়গাতেই —, তাই মিলেছে; effect পরে আসল সময় বসিয়েছে। দ্বিতীয় লাইনে suppressHydrationWarning warning চুপ করিয়েছে। খেয়াল করুন, dev run-এ এই লাইনে পর্দায় নতুন সময় এসেছে, কারণ একই component-এর প্রথম লাইনের effect-এর state বদলে পুরো component আবার render হয়েছে। Docs-এর ভাষায় React অমিল লেখা ঠিক করার চেষ্টা করবে না; একা থাকলে পুরোনো লেখাই থেকে যেতে পারে। তৃতীয় লাইন useSyncExternalStore-এর, পরের অংশে। চতুর্থটি ssr: false: HTML-এ <!--$!--> চিহ্ন মানে এই Suspense boundary server-এ বাদ দিয়ে client-এ render করতে বলা হয়েছে, আর জায়গায় loading লেখা।

Two-pass rendering নিজে চালিয়ে দেখুন

নিচের ব্লকে React 19 চলে, তবে createRoot দিয়ে, তাই এটি hydration নয়। এখানে দেখার বিষয় শুধু render-এর ক্রম: প্রথম render-এ client-only মান নেই, effect চলার পরে দ্বিতীয় render-এ আসে। hydrateRoot-এর সাথে ঠিক এই ক্রমেই প্রথম render server-এর HTML-এর সাথে মেলে।

<div id="root"></div>
<script src="../course-kit/vendor/react-lab.js"></script>
<script type="text/jsx">
let renders = 0;
function ScreenBadge() {
  // server-এ window নেই, তাই প্রথম render-এ null
  const [size, setSize] = useState(null);
  renders++;
  console.log(`render ${renders}: size = ${size === null ? 'null' : 'মাপা হয়েছে'}`);
  useEffect(() => {
    console.log('effect: এখন browser-এ, window পড়া নিরাপদ');
    setSize(window.innerWidth >= 600 ? 'বড় পর্দা' : 'ছোট পর্দা');
  }, []);
  return <p>{size === null ? 'পর্দা মাপা হচ্ছে…' : size}</p>;
}
createRoot(document.getElementById('root')).render(<ScreenBadge />);
</script>

render 1: size = null
effect: এখন browser-এ, window পড়া নিরাপদ
render 2: size = মাপা হয়েছে

1'use client';2export default function Price() {3  const text = (1250).toLocaleString();4  return <p>দাম: {text}</p>;5}6// সমাধান: toLocaleString('bn-BD')

৫ · useSyncExternalStore আর getServerSnapshot

React-এর বাইরের কোনো উৎস থেকে মান পড়তে পর্ব ১৮-এ useSyncExternalStore দেখেছেন। এর তৃতীয় argument getServerSnapshot ঠিক hydration-এর জন্য বানানো। react.dev অনুযায়ী এটি চলে মাত্র দুই জায়গায়: server-এ HTML বানানোর সময়, আর client-এ hydration-এর সময়। Hydration শেষ হলে React getSnapshot-এর আসল মানে চলে যায়, আর দরকার হলে আবার render করে।

export function useOnline() {
  return useSyncExternalStore(
    subscribe,                 // online/offline ইভেন্টে কান পাতা
    () => navigator.onLine,    // ব্রাউজারে আসল মান
    () => true,                // server আর hydration-এ নির্দিষ্ট মান
  );
}

নিয়ম দুটি। এক, getServerSnapshot server-এ যা দিয়েছিল, hydration-এ client-এও হুবহু তাই দিতে হবে। Store-এ server থেকে আসা ডেটা থাকলে সেটি HTML-এর সাথে পাঠাতে হয়, যাতে client-এ একই মান পাওয়া যায়। দুই, argument-টি বাদ দিলে server-এ render করতে গেলে error হয়। Docs বলে, server-এ অর্থপূর্ণ মান না থাকলে বাদ দিয়ে সেই অংশকে client-এ render হতে দেওয়াই পথ।

useEffect-এর পথের সাথে তফাত কী? ফল প্রায় এক: প্রথমে নির্দিষ্ট মান, পরে আসল মান। কিন্তু useSyncExternalStore পরের বদলগুলোতেও (নেট চলে গেলে) সঠিকভাবে সাড়া দেয়, আর একই store অনেক component পড়লে সবাই একই মান দেখে। Zustand-এর মতো library ভেতরে এটিই ব্যবহার করে।

৬ · Selective hydration: Suspense আর hydration-এর ক্রম

পুরো পাতা এক টানে hydrate হলে বড় পাতায় long task লম্বা হয়। React 18 থেকে Suspense boundary hydration-এর ভাগও ঠিক করে। প্রতিটি boundary আলাদা টুকরো হিসেবে hydrate হতে পারে, আর streaming-এ যে boundary-র HTML পরে আসে, সেটি পরে hydrate হয়।

প্রথম পরীক্ষা: একটি পাতায় হেডারের বোতাম, আর দুটি Suspense boundary. ভেতরের server component connection() ডেকে পাতাকে dynamic করে, তারপর একটি 800 ms, অন্যটি 1600 ms অপেক্ষা করে। Production build-এর route তালিকায় পাতাটি ƒ /suspense. Server-এর প্রথম HTML টুকরো:

<main><button>header<!-- --> (<!-- -->0<!-- -->)</button><!--$?--><template id="B:0"></template><p>রিভিউ লোড হচ্ছে…</p><!--/$--><!--$?--><template id="B:1"></template><p>পণ্য লোড হচ্ছে…</p><!--/$--></main>
…
<div hidden id="S:1"><section><p>মিল আছে এমন পণ্য</p><button>related…</button></section></div><script>$RC("B:1","S:1")</script>

<!--$?--> মানে অপেক্ষমাণ boundary, ভেতরে fallback. পরে একই সংযোগে লুকানো <div hidden id="S:1">-এ আসল HTML আসে, আর ছোট $RC script fallback-এর জায়গায় সেটি বসায়। প্রতিটি client component-এর useEffect সময় লিখে রাখে। ব্রাউজারের console, সত্যিকারের run:

hydrated: header 98ms
hydrated: reviews 835ms
hydrated: related 1636ms

হেডার আগে সচল, রিভিউ বা অন্য পণ্যের জন্য অপেক্ষা করেনি। প্রতিটি অংশ তার HTML আসার পরপরই hydrate হয়েছে।

ক্লিক অগ্রাধিকার পায়

দ্বিতীয় পরীক্ষা আরও আকর্ষণীয়। দুটি boundary-ই প্রথম HTML-এ আছে, কিন্তু প্রতিটির ভেতরে ২০টি ধীর component, প্রত্যেকটি render-এ ইচ্ছা করে 15 ms ব্যস্ত থাকে। মানে প্রতিটি boundary hydrate করতে প্রায় 300 ms. Boundary দুটি পাতায় এই ক্রমে: reviews তারপর related. দুটি run: একবার কিছু না করে, একবার JavaScript আসার সাথে সাথে related-এর “কিনুন” বোতামে ক্লিক।

$ python probe_selective.py
--- no click
hydrated: reviews 710ms
hydrated: related 710ms
--- with early click on related
user clicked related at ~271ms
hydrated: related 664ms
click handled: related 666ms
hydrated: reviews 969ms

ক্লিক না করলে React পাতার ক্রমে কাজ করেছে, আর দুটির effect একসাথে চলেছে। ক্লিক করলে ক্রম উল্টে গেল: related আগে hydrate হলো, আর 2 ms পরে সেই পুরোনো ক্লিকের handler চলল। ক্লিকটি হারায়নি, React সেটি ধরে রেখে পরে আবার চালিয়েছে, একে বলে event replay. তারপর প্রায় 305 ms পরে reviews, যা প্রায় ২০ × 15 ms-এর সমান। একবার চালানোয় দ্বিতীয় run-এর সংখ্যা ছিল 649, 651 আর 955 ms; ক্রম একই।

৭ · বড় পাতার খরচ আর server component

Hydration-এর খরচ তিন ভাগে: JavaScript নামানো, সেটি parse করে চালানো, আর tree-র প্রতিটি element DOM-এর সাথে মেলানো। পর্ব ৫২-তে দেখবেন, server component-এর কোড ব্রাউজারে যায় না। তাহলে কি server component ব্যবহার করলে hydration কমে যায়? মেপে দেখি।

একই পণ্যের পাতা দুইভাবে বানালাম। /product: পাতা server component, শুধু “কার্টে যোগ” একটি ছোট client component. /product-all: পুরো পাতা একটি client component, ৬০০টি রিভিউ JSON import করে। দুটিই ○ (Static). Build-এর ফাইলের মাপ আর একই শর্তের Edge run (CPU ৬ গুণ, ধীর নেটওয়ার্ক, পাঁচবারের মধ্যমা):

ফলটি অনেকের প্রত্যাশার চেয়ে ছোট, তাই সৎভাবে পড়ুন। Server component-এর পাতায় 93,682 bytes-এর একটি JS chunk কমেছে, যাতে রিভিউর ডেটা আর component ছিল। কিন্তু gzip-এর পরে পার্থক্য মাত্র প্রায় 6 kB, আর HTML উল্টো বড় হয়েছে। কারণ RSC payload: server component-এর ফল একটি বিশেষ বিন্যাসে HTML-এর ভেতরেই script হিসেবে আসে, যাতে client-এ React পুরো tree জানে। তাই ৬০০টি রিভিউ দুবার এসেছে: একবার HTML হিসেবে, একবার payload হিসেবে। আমরা গুনেছি, “রহিম” নামটি server পাতার HTML ফাইলে ১০০ বার, অন্যটিতে ৫০ বার।

সময়ের পার্থক্য এই run-এ মাত্র 40 থেকে 70 ms. কেন এত কম? দুই পাতাতেই প্রায় 450 kB-র framework JavaScript আছে, যা মোট খরচের বড় অংশ। আর App Router-এ client-এ React পুরো tree ধরে, server component-এর বানানো element-গুলোও DOM-এর সাথে মেলায়। Server component বাঁচায় সেই component-এর কোড নামানো আর চালানোর খরচ, element মেলানোর কাজ পুরো নয়।

৮ · অন্য পথ: islands আর resumability

সব framework hydration-কে একইভাবে দেখে না। দুটি বিকল্প ধারণা জানা থাকা দরকার, কারণ ইন্টারভিউতে প্রায়ই তুলনা আসে। নিচের তথ্য এই পর্বে চালিয়ে যাচাই করা হয়নি; ধারণা হিসেবে পড়ুন, আর ব্যবহারের আগে নিজ নিজ docs দেখুন।

Islands. পাতার বেশিরভাগ অংশ স্থির HTML, যাতে কোনো JavaScript জোড়া হয় না। শুধু ছোট ছোট interactive “দ্বীপ” আলাদাভাবে hydrate হয়। নামটি ২০১৯ সালে Etsy-র Katie Sylor-Miller-এর ধারণা থেকে আসে বলে জানা যায়, আর ২০২০ সালে Jason Miller-এর একটি লেখায় জনপ্রিয় হয়। Astro (1.0 এসেছে ২০২২ সালে) এই পথের পরিচিত উদাহরণ: component-এ client:load, client:idle বা client:visible-এর মতো নির্দেশ দিলে তবেই সেটি hydrate হয়। রিভিউর মতো স্থির তালিকা তখন hydration-এর খরচে ঢোকেই না। দাম: দ্বীপগুলো একে অন্যের state সহজে ভাগ করতে পারে না, আর পুরো অ্যাপের মতো client-side navigation-এর জন্য বাড়তি কাজ লাগে।

Resumability. Qwik (Angular-এর স্রষ্টাদের একজন Miško Hevery-র নেতৃত্বে, 1.0 এসেছে ২০২৩ সালে) আরও এক ধাপ যায়। Server তার অবস্থা আর কোন event-এ কোন handler, সেই তথ্য HTML-এ লিখে দেয়। ব্রাউজার শুরুতে component আবার চালায় না; ক্লিক হলে তবেই সেই handler-এর ছোট কোড নামিয়ে চালায়, যেন server যেখানে থেমেছিল সেখান থেকে “আবার শুরু”। দাম: প্রথম ক্লিকে কোড নামানোর দেরি হতে পারে, যা এই framework prefetch দিয়ে কমানোর চেষ্টা করে, আর চিন্তার ধরন React থেকে আলাদা।

সম্প্রদায় এখানে একমত নয়। একদল বলে, React-এর server component আর selective hydration মিলে islands-এর বেশিরভাগ লাভ দেয়, আর পূর্ণ অ্যাপের সুবিধা রাখে। অন্যদল বলে, যতক্ষণ পুরো tree মেলাতে হয়, ততক্ষণ বড় পাতায় খরচ থেকেই যায়। আমাদের মাপে দ্বিতীয় দলের কথায় কিছু সত্য আছে। সিদ্ধান্ত নিন পাতার ধরন দেখে: “বাজারঘর”-এর কার্ট আর চেকআউট অ্যাপের মতো, ব্লগ আর সাহায্যের পাতা লেখা-প্রধান।

৯ · বাজারঘর-এর পণ্যের পাতা: একটি hydration বাজেট

পর্ব ২৩-এ performance budget-এর ধারণা পেয়েছেন। এখানে hydration-এর জন্য একটি সরল হিসাব। মূল সূত্র:

ধরুন নেটওয়ার্ক 200 kB/s (প্রায় 1.6 Mbps), RTT 150 ms. Paint-এর আগে সংযোগ, অনুরোধ আর HTML মিলিয়ে ৩টি RTT. সস্তা ফোনে decoded JavaScript-এর প্রতি kB-তে 1.0 ms, আর প্রতি element মেলাতে 0.1 ms. এই সংখ্যাগুলো অনুমান, শেখার জন্য বেছে নেওয়া; নিজের লক্ষ্য-ফোনে মেপে বদলে নিন। মডেলটি সরলও: বাস্তবে JavaScript HTML-এর সাথে সমান্তরালে নামতে শুরু করে। বাজেট: interactive ≤ 2500 ms, মৃত সময় ≤ 1500 ms. KB-র সংখ্যা ওপরের build থেকে।

// বাজারঘর পণ্যের পাতা: hydration বাজেটের সরল হিসাব
// KB-র সংখ্যা একটি local build থেকে; নেটওয়ার্ক আর CPU ধরে নেওয়া
const net = { kBps: 200, rtt: 150 };        // ধীর মোবাইল সংযোগ, অনুমান
const cpu = { msPerKB: 1.0, msPerEl: 0.1 }; // সস্তা ফোন, অনুমান
const budget = { interactive: 2500, dead: 1500 };
const plans = [
  { name: 'সব client component', html: 6.7, js: 143, jsRaw: 551, els: 1205 },
  { name: 'server + ছোট client', html: 16.8, js: 137, jsRaw: 457, els: 1205 },
  { name: 'server, ২০টি রিভিউ', html: 2.5, js: 137, jsRaw: 457, els: 45 },
  { name: 'islands (ধরে নেওয়া)', html: 6.7, js: 8, jsRaw: 20, els: 1 },
];
const down = kb => (kb / net.kBps) * 1000;
for (const p of plans) {
  const paint = 3 * net.rtt + down(p.html);   // সংযোগ, অনুরোধ, HTML
  const jsReady = paint + net.rtt + down(p.js);
  const run = p.jsRaw * cpu.msPerKB;           // parse আর চালানো
  const hyd = p.els * cpu.msPerEl;             // DOM মিলিয়ে handler জোড়া
  const ready = jsReady + run + hyd;
  const dead = ready - paint;
  const ok = ready <= budget.interactive && dead <= budget.dead;
  console.log(`${p.name}\n  paint ${paint.toFixed(0)}  JS ${jsReady.toFixed(0)}` +
    `  চালানো +${run.toFixed(0)}  hydrate +${hyd.toFixed(0)}` +
    `\n  interactive ${ready.toFixed(0)} ms, মৃত সময় ${dead.toFixed(0)} ms → ${ok ? 'বাজেটে' : 'বাজেটের বাইরে'}`);
}

সব client component
  paint 484  JS 1349  চালানো +551  hydrate +121
  interactive 2020 ms, মৃত সময় 1537 ms → বাজেটের বাইরে
server + ছোট client
  paint 534  JS 1369  চালানো +457  hydrate +121
  interactive 1947 ms, মৃত সময় 1413 ms → বাজেটে
server, ২০টি রিভিউ
  paint 463  JS 1298  চালানো +457  hydrate +5
  interactive 1759 ms, মৃত সময় 1297 ms → বাজেটে
islands (ধরে নেওয়া)
  paint 484  JS 674  চালানো +20  hydrate +0
  interactive 694 ms, মৃত সময় 210 ms → বাজেটে

এই হিসাব থেকে “বাজারঘর”-এর পণ্যের পাতার সিদ্ধান্ত:

• পাতা server component; শুধু কার্টের বোতাম, পরিমাণ বাছাই আর ছবির গ্যালারি client component
• প্রথম HTML-এ ২০টি রিভিউ, বাকিগুলো “আরও দেখুন”-এ, যা পর্ব ৩৪-এর cursor pagination ব্যবহার করে
• “সম্পর্কিত পণ্য” আলাদা Suspense boundary-তে, যাতে কার্টের অংশ আগে সচল হয়
• কার্টে যোগ একটি <form>, যা JavaScript আসার আগেও কাজ করে (পর্ব ৫৪-এর server action)
• দাম আর তারিখ server-এ bn-BD ও Asia/Dhaka দিয়ে লেখা; client-এ আবার হিসাব নয়
• CI-তে JS-এর আকারের সীমা, আর প্রতি release-এ ধীর CPU-তে প্রথম ক্লিকের মাপ

১০ · AI-এর যুগে: hydration error AI-কে দেখানোর আগে

Hydration error-এ AI-এর সবচেয়ে প্রিয় উত্তর দুটি: “suppressHydrationWarning দিন” আর “ssr: false দিন”। দুটিই error সরায়, কারণ সরায় না। একটি চোখ বন্ধ করে, অন্যটি পাতার অংশ server থেকে সরিয়ে দেয়। একটি মজার বাস্তব তথ্য: আমাদের next dev run-এ Next.js 16.4.4 নিজেই প্রজেক্টে একটি AGENTS.md ফাইল লিখেছে, যার প্রথম শিরোনাম “This is NOT the Next.js you know”, আর বলে কোড লেখার আগে node_modules/next/dist/docs/-এর guide পড়তে। Framework নিজেই জানে, AI পুরোনো version মনে রাখে।

AI-এর hydration সমাধান নেওয়ার আগে

• Dev-এ error চলে গেছে, আর production build-এ console-এ #418-এর মতো minified error নেই
• Build-এর HTML-এ গুরুত্বপূর্ণ লেখা (নাম, দাম) এখনো আছে; ssr: false তা সরায়নি
• API আর option আমার version-এর official docs-এ আছে
• নতুন package নেই, বা থাকলে সত্যিই আছে আর bundle কতটা বাড়াল দেখেছি
• Client component-এ কোনো secret বা server-only কোড ঢোকেনি
• Diff পড়েছি, আর ধীর CPU-তে প্রথম ক্লিক আবার মেপেছি