Rendering-এর মানচিত্র — CSR, SSR, SSG আর SPA, MPA

১ · HTML কোথায়, আর কখন তৈরি হয়

পর্ব ০২-এ আপনি একটি অনুরোধের পুরো যাত্রা দেখেছেন। সেখানে একটি প্রশ্ন বাকি ছিল: যে HTML ব্রাউজারে পৌঁছায়, সেটি আসলে কে বানাল? এই বানানোর কাজের নামই rendering. ব্রাউজারের কাছে শেষ পর্যন্ত একটি পাতা বানানোর মতো HTML বা DOM থাকতেই হবে। আলাদা হয় শুধু এটুকু: বানানোর কাজটি কে করছে, আর কোন মুহূর্তে করছে।

এখানে “চুলা” মানে ব্যবহারকারীর ফোনের CPU, আর “রান্নাঘর” মানে আপনার সার্ভার। পুরো পর্বের চাবি এই ছবিতে:

২ · MPA বনাম SPA, আর ওয়েব কীভাবে এখানে এল

এবার সম্পূর্ণ আলাদা একটি প্রশ্ন: ব্যবহারকারী একটি লিংকে চাপ দিলে কী হয়? MPA-তে ব্রাউজার সার্ভার থেকে নতুন একটি HTML document আনে; পর্দা সাদা হয়ে নতুন পাতা আসে। SPA-তে document একটিই থাকে। JavaScript ক্লিক ধরে, দরকারি ডেটা আনে, আর পাতার অংশ বদলে দেয়। ঠিকানা বদলাতে আর Back বোতাম ঠিক রাখতে সে History API ব্যবহার করে।

Rendering কীভাবে বদলেছে

ইতিহাসটি একটি দোলকের মতো: HTML প্রথমে সার্ভারে, তারপর ব্রাউজারে, এখন আবার দুই দিকে ভাগ করে।

৩ · CSR: ফোনই রান্নাঘর

CSR-এ সার্ভার পাঠায় প্রায় ফাঁকা একটি HTML, যাকে অনেকে app shell বলেন, আর একটি বড় JavaScript ফাইল। JavaScript ফোনে চলে, API থেকে ডেটা আনে, তারপর পাতা আঁকে।

এই পর্বের সব সময়ের হিসাব একই ধরে নেওয়া মানে করা, যাতে তুলনা করা যায়। এগুলো মাপা সংখ্যা নয়, একটি ধীর মোবাইল সংযোগের কাল্পনিক ছবি:

CSR-এর দুর্বলতা প্রথম লোডে। শক্তি পরের ক্লিকে: সার্ভারে HTML বানানোর খরচ নেই, shell আর JavaScript যেকোনো static hosting থেকে দেওয়া যায়, আর পরের পাতায় শুধু JSON আনলেই চলে। তাই লগইনের পেছনের ড্যাশবোর্ডে CSR এখনো খুব যুক্তিসঙ্গত।

৪ · SSR আর hydration: দেখা যায়, কিন্তু চাপ দিলে কাজ করে না

SSR-এ প্রতিটি অনুরোধে সার্ভার ডেটাবেস থেকে ডেটা আনে, পূর্ণ HTML বানায় আর পাঠায়। ব্রাউজার JavaScript ছাড়াই পাতা আঁকতে পারে। কিন্তু React-এ বানানো পাতা শুধু ছবি হয়ে থাকলে বোতাম কাজ করবে না। তাই একই JavaScript পরে আসে, আর HTML-এর সাথে নিজেকে জুড়ে নেয়।

খেয়াল করুন: SSR পাতা দেখানোর সময় কমিয়েছে, ক্লিকযোগ্য হওয়ার সময় প্রায় কমায়নি (CSR-এ 3030 ms, SSR-এ 3000 ms). JavaScript-এর আকার না কমালে এই ফাঁক থেকেই যায়। তা ছাড়া প্রতিটি অনুরোধে সার্ভারের CPU আর ডেটাবেস খরচ হয়।

৫ · SSG আর ISR: রান্না আগে, পরিবেশন কাছে

SSG-তে build-এর সময় একবার HTML তৈরি হয়, তারপর সেটি সাধারণ ফাইল। ফাইল হলে তা CDN-এ রাখা যায়। CDN-এর সবচেয়ে কাছের সার্ভারকে বলে edge, আর মূল সার্ভারকে origin. পাড়ার মুদি দোকানে মাল মজুত থাকলে যেমন প্রতিবার মূল গুদামে যেতে হয় না, তেমনি অনুরোধও origin পর্যন্ত যায় না। CDN আর cache-এর তত্ত্ব আছে System Design-এর CDN পর্বে।

SSG-র সমস্যা হলো পুরোনো হয়ে যাওয়া। দাম বদলালে আবার build? ৫০ হাজার পণ্যের দোকানে সেটি অসম্ভব রকম ধীর হতে পারে। এখানেই ISR: পাতা static থাকে, কিন্তু নির্দিষ্ট সময় পরে বা দরকারমতো একটি পাতাই পেছনে নতুন করে তৈরি হয়। নীতিটির নাম stale-while-revalidate: পুরোনো কপি এখনই দিন, নতুনটি পেছনে বানান।

দরকার হলে সময়ের অপেক্ষা না করে কোড থেকেও একটি পাতা বাতিল করা যায় (on-demand revalidation): Next.js-এ revalidatePath বা revalidateTag. এটি পর্ব ৫৩ আর পর্ব ৫৫-এর বিষয়।

৬ · Streaming, PPR, আর Next.js-এ সব একসাথে

SSR-এর একটি জ্বালা: পাতার সবচেয়ে ধীর অংশের জন্য পুরো পাতা আটকে থাকে। Streaming এটি ভাঙে। সার্ভার পাতার তৈরি অংশ আগে পাঠায়, ধীর অংশের জায়গায় একটি অপেক্ষার UI দেয়, আর সেটি তৈরি হলে একই সংযোগে বাকি HTML পাঠায়। থালিতে আগে ভাত দিয়ে দেওয়া, মাছ এলে পরে দেওয়ার মতো। React-এ এই সীমা টানে <Suspense>. এতে সাধারণত TTFB আর FCP কমে। একটি ফাঁদ: প্রথম টুকরো যাওয়ার পর HTTP status আর বদলানো যায় না, তাই পরে ভুল হলে 200 উত্তরের ভেতরেই তা দেখাতে হয়।

PPR আরেক ধাপ এগিয়ে: একই পাতার static অংশ আগেই তৈরি থাকে আর সঙ্গে সঙ্গে যায়, “গর্ত”গুলো অনুরোধের সময় stream হয়ে পূরণ হয়। পণ্যের নাম আর ছবি তৈরি থাকল, “আপনার জন্য সুপারিশ” পরে এল। Next.js 16-এ cacheComponents চালু করলে এটিই App Router-এর ডিফল্ট আচরণ; আগের experimental.ppr flag সরিয়ে দেওয়া হয়েছে। Next.js-এর বাইরে কিছু framework-এ একই ধারণা ভিন্ন নামে আছে।

একই অ্যাপে চারটি কৌশল: সত্যিকারের build

কথাগুলো কাল্পনিক নয়। “বাজারঘর”-এর ছোট একটি Next.js অ্যাপ আমরা সত্যিই build করেছি (সত্যিকারের run; লেখার সময়ে Next.js 16.4.3, React 19.3.1, Node 24). এই অ্যাপে cacheComponents বন্ধ ছিল, অর্থাৎ আগের মডেল। নতুন create-next-app (16.4.4) এটি নিজেই চালু করে দেয়, আর তখন নথি অনুযায়ী export const revalidate চলে না; তার বদলে 'use cache' আর cacheLife, যা পর্ব ৫৫-এ আছে। চারটি পাতার মূল অংশ:

export const revalidate = 60;              // ISR: 60 s পর পেছনে নতুন করে
export function generateStaticParams() {   // build-এ এই id-গুলোর পাতা তৈরি
  return Object.keys(PRODUCTS).map((id) => ({ id }));
}

import { cookies } from 'next/headers';
export default async function Cart() {
  const store = await cookies();           // cookie পড়া মানে প্রতি অনুরোধে render
  const items = store.get('cart_items')?.value ?? '0';
  return <h1>Cart items: {items}</h1>;
}

/admin পাতাটি 'use client' দিয়ে useEffect-এ ডেটা আনে, আর / ও /blog সাধারণ পাতা। next build নিজেই বলে দেয় কোন পাতা কী হলো:

$ npx next build
▲ Next.js 16.4.3 (Turbopack)
…
Route (app)
┌ ○ /
├ ○ /_not-found
├ ○ /admin
├ ○ /blog
├ ƒ /cart
└   /products/[id]
  ├ ● /products/1
  └ ● /products/2

○  (Static)   prerendered as static content
●  (SSG)      prerendered as static HTML (uses generateStaticParams)
ƒ  (Dynamic)  server-rendered on demand

এরপর next start চালিয়ে প্রতিটি পাতার header আর HTML-এর <h1> দেখেছি (এক local run, ছোট করে সাজানো):

৭ · গতি মাপার চারটি কাঠি, আর ধীর নেটওয়ার্ক

“দ্রুত” শব্দটি অস্পষ্ট। তাই আলাদা আলাদা মুহূর্তের নাম আছে। LCP, INP আর CLS মিলে Core Web Vitals; TTFB আর FCP তাদের বোঝার সহায়ক। মান বিচার হয় আসল ব্যবহারকারীদের ৭৫তম percentile ধরে (অর্থাৎ ১০০টি ভিজিটের মধ্যে ৭৫টি যত ভালো বা তার চেয়ে ভালো), মোবাইল আর ডেস্কটপ আলাদা করে। বিস্তারিত আছে পর্ব ৮৪-তে আর HTML & CSS-এর performance পর্বে।

এবার তিনটি কৌশল পাশাপাশি চালান। নিচের সিমুলেটর ৩ নম্বর অংশের ধরে নেওয়া মানগুলোই ব্যবহার করে। js: 300 কমিয়ে 100 করে, বা kBps কমিয়ে আবার চালিয়ে দেখুন।

// সব সংখ্যা ধরে নেওয়া, মাপা নয়। বদলে দেখুন।
const net = { kBps: 200, originRTT: 200, cdnRTT: 40, serverMs: 150, cpuKBps: 500 };
const size = { shell: 2, html: 30, json: 10, js: 300 };   // KB

const get = (rtt, serverMs, kb) => ({
  ttfb: 3 * rtt + serverMs,
  done: 3 * rtt + serverMs + kb / net.kBps * 1000,
});
const runJs = t => t + size.js / net.kBps * 1000 + size.js / net.cpuKBps * 1000;

function load(kind) {
  if (kind === 'CSR') {
    const doc = get(net.cdnRTT, 0, size.shell);
    const fcp = runJs(doc.done);                // এই মুহূর্তে "লোড হচ্ছে..." আঁকে
    const lcp = fcp + get(net.originRTT, net.serverMs, size.json).done;
    return { ttfb: doc.ttfb, fcp, lcp, ready: lcp };
  }
  const doc = kind === 'SSR' ? get(net.originRTT, net.serverMs, size.html)
                             : get(net.cdnRTT, 0, size.html);
  return { ttfb: doc.ttfb, fcp: doc.done, lcp: doc.done, ready: runJs(doc.done) };
}

for (const kind of ['CSR', 'SSR', 'SSG']) {
  const t = load(kind);
  console.log(kind, Object.entries(t).map(([k, v]) => `${k}=${Math.round(v)}ms`).join('  '));
  const cell = ms => Math.round(ms / 100);
  console.log('    ' + '.'.repeat(cell(t.lcp)) + '#'.repeat(cell(t.ready) - cell(t.lcp)) + '|');
}
console.log('. = মূল বিষয়বস্তুর অপেক্ষা   # = দেখা যায়, চাপ দিলে কাজ করে না');

CSR ttfb=120ms  fcp=2230ms  lcp=3030ms  ready=3030ms
    ..............................|
SSR ttfb=750ms  fcp=900ms  lcp=900ms  ready=3000ms
    .........#####################|
SSG ttfb=120ms  fcp=270ms  lcp=270ms  ready=2370ms
    ...#####################|
. = মূল বিষয়বস্তুর অপেক্ষা   # = দেখা যায়, চাপ দিলে কাজ করে না

ধীর মোবাইল নেটওয়ার্কে কী বদলায়

বাংলাদেশে অনেক ব্যবহারকারী ফোনে, সীমিত ডেটা প্যাকে, আর ভিড়ের সময়ে বা শহরের বাইরে দুর্বল সংকেতে ওয়েব দেখেন। অনেকের ফোনের CPU-ও দামি ফোনের মতো নয়। তাই গতি মাপুন নিজের অফিসের Wi-Fi আর ল্যাপটপে নয়। সিমুলেটরে গতি 50 KB/s ধরে দেখি (এটিও ধরে নেওয়া মান):

এখানে SSR-এর ফাঁক সবচেয়ে বেশি: ৬ সেকেন্ডের বেশি সময় পাতা দেখা যায় কিন্তু কাজ করে না, আর ব্যবহারকারী তখন বারবার বোতাম চাপেন। JavaScript 300 থেকে 100 KB করলে তিন কৌশলেই 4.4 s বাঁচে। কৌশল বদলানোর আগে অনেক সময় এটিই বড় লাভ। Chrome DevTools-এর network আর CPU throttling (ইচ্ছা করে গতি কমানো) দিয়ে আপনি নিজের পাতা এভাবে পরীক্ষা করতে পারেন। JavaScript কমানোর কৌশল আসবে পর্ব ২৩ আর পর্ব ৭৯-এ।

৮ · SEO আর শেয়ারের preview: কে কী দেখে

বাজারঘর-এর একটি পণ্যের লিংক কেউ Facebook বা WhatsApp-এ দিলে শিরোনাম আর ছবি কোথা থেকে আসে? একটি crawler পাতা আনে, আর সাধারণত HTML-এর Open Graph tag পড়ে। এই preview bot-গুলো সাধারণত JavaScript চালায় না বলে ব্যাপকভাবে দেখা যায়, যদিও প্রতিটি প্ল্যাটফর্ম আলাদা আর নিয়ম বদলাতে পারে। তাই নিরাপদ অভ্যাস: শিরোনাম, বিবরণ আর ছবির tag প্রথম HTML-এই রাখুন।

নিচের ব্লকে একটি আসল node:http সার্ভার একই পণ্যতালিকা দুভাবে দেয়: /ssr-এ পূর্ণ HTML, /csr-এ ফাঁকা shell আর আলাদা JSON. তারপর সেই ব্লকই JavaScript না চালানো crawler-এর মতো পাতা পড়ে।

const http = require('node:http');
const products = [
  { name: 'Rice 5kg', price: 450 }, { name: 'Lentil 1kg', price: 140 },
  { name: 'Soybean oil 2L', price: 390 }, { name: 'Tea 400g', price: 210 },
];
const esc = s => String(s).replace(/[&<>"]/g, c => '&#' + c.charCodeAt(0) + ';');
const page = (title, body) => `<!doctype html><html><head><title>${title}</title>` +
  `</head><body>${body}<script src="/app.js"></script></body></html>`;
const html = { 'content-type': 'text/html; charset=utf-8' };
const server = http.createServer((req, res) => {
  if (req.url === '/ssr') {
    const items = products.map(p => `<li>${esc(p.name)}: ${p.price} BDT</li>`);
    res.writeHead(200, html).end(page('4 products', `<ul>${items.join('')}</ul>`));
  } else if (req.url === '/csr') {
    res.writeHead(200, html).end(page('Loading...', '<div id="root"></div>'));
  } else if (req.url === '/api/products') {
    res.writeHead(200, { 'content-type': 'application/json' }).end(JSON.stringify(products));
  } else res.writeHead(404).end();
});
// A simple crawler: it reads the HTML and runs no JavaScript at all.
const seen = doc => doc.replace(/<script[\s\S]*?<\/script>/g, '')
  .replace(/<[^>]+>/g, ' ').replace(/\s+/g, ' ').trim();
server.listen(0, '127.0.0.1', async () => {
  const base = `http://127.0.0.1:${server.address().port}`;
  for (const path of ['/ssr', '/csr', '/api/products']) {
    const res = await fetch(base + path);
    const text = await res.text();
    console.log(path.padEnd(13), Buffer.byteLength(text) + ' bytes');
    if (path !== '/api/products') console.log('  crawler sees:', JSON.stringify(seen(text)));
  }
  server.closeAllConnections();
  server.close();
});

/ssr          231 bytes
  crawler sees: "4 products Rice 5kg: 450 BDT Lentil 1kg: 140 BDT Soybean oil 2L: 390 BDT Tea 400g: 210 BDT"
/csr          131 bytes
  crawler sees: "Loading..."
/api/products 137 bytes

Google-এর কথা একটু আলাদা। তাদের নথি অনুযায়ী Googlebot পাতা crawl করে, পরে সম্পদ পেলে headless Chromium-এ (পর্দা ছাড়া চলা ব্রাউজার) JavaScript চালিয়ে render করে, তারপর index করে। অর্থাৎ CSR পাতাও Google পড়তে পারে, তবে render-এর একটি সারিতে অপেক্ষা থাকে। নথিটি নিজেই বলে, SSR বা pre-rendering এখনো ভালো ধারণা, কারণ এতে ব্যবহারকারী আর crawler দুজনেরই সুবিধা, আর সব bot JavaScript চালাতে পারে না। Metadata, sitemap আর structured data আসবে পর্ব ৫৮-এ; <head>-এর ভিত্তি আছে HTML & CSS কোর্সে।

৯ · সার্ভারের খরচ, CDN, আর বাজারঘর-এর সিদ্ধান্ত

গতি ছাড়াও প্রশ্ন আছে: প্রতি অনুরোধে কে কাজ করছে? SSR-এ আপনার সার্ভার, SSG-তে প্রায় কেউ না, CSR-এ ব্যবহারকারীর ফোন আর আপনার API. হিসাব করে দেখি।

পথটি সরল: 1000000 ÷ 86400 = 11.57 req/s গড়, × 5 = 57.87, × 0.05 s = 2.89 core, ÷ 0.6 = 4.82. খেয়াল করুন, cache hit rate 95% থেকে 99% হলে শুধু ৪ শতাংশ বিন্দু বাড়ে, অথচ origin-এর চাপ ৫ ভাগের ১ হয়ে যায়। কারণ হিসাবটি হয় miss-এর ওপর: 5% থেকে 1%. এর অঙ্কের দিকটি আছে Computer Networks-এর caching পর্বে, আর নানা ধরনের অনুশীলন পর্ব ৮৯-এ।

ISR-ও বিনামূল্যে নয়। revalidate = 60 মানে একটি পাতা দিনে সর্বোচ্চ 86400 ÷ 60 = 1440 বার নতুন হতে পারে, আর ট্রাফিক থাকলে হয়ও। হাজার পণ্যে সীমাটি দিনে ১৪ লাখ ৪০ হাজার, যা উদাহরণের মোট ১০ লাখ ভিজিটের চেয়েও বেশি। অর্থাৎ ভিজিট সমানভাবে ছড়ানো থাকলে প্রায় প্রতিটি ভিজিটই পেছনে একটি render চালু করবে, আর সার্ভারের খরচে cache-এর লাভ প্রায় থাকবে না। তাই Next.js-এর নথিও ছোট সময়ের বদলে বড় সময় (যেমন ১ ঘণ্টা) আর দরকারে on-demand revalidation ব্যবহারের পরামর্শ দেয়।

পাতা ধরে সিদ্ধান্ত

চারটি প্রশ্ন করুন: (১) পাতাটি কি সবার জন্য এক? (২) কত ঘন ঘন বদলায়, পুরোনো হলে ক্ষতি কত? (৩) crawler বা preview-কে কি এটি পড়তে হবে? (৪) পাতায় কতটা ক্লিক-নির্ভর কাজ? নিচের সিদ্ধান্ত-সহায়ক এই যুক্তিকেই কোড করে। বৈশিষ্ট্য বদলে দেখুন।

function choose(p) {
  if (p.private && !p.seo && p.manyClicks) return ['CSR', 'লগইনের পেছনে, crawler লাগে না, ক্লিক অনেক'];
  if (p.private) return ['SSR', 'মানুষ ধরে আলাদা, ভাগ করা cache-এ রাখা যাবে না'];
  if (p.freshSeconds === 0) return ['SSR', 'প্রতি অনুরোধে নতুন তথ্য দরকার'];
  if (p.changesPerDay > 1) return ['ISR', 'সবার জন্য এক, তবে দিনে কয়েকবার বদলায়'];
  return ['SSG', 'সবার জন্য এক, কালেভদ্রে বদলায়'];
}

const pages = [
  { name: 'হোম',       seo: true,  private: false, changesPerDay: 6,  freshSeconds: 300 },
  { name: 'পণ্যের পাতা', seo: true,  private: false, changesPerDay: 12, freshSeconds: 60 },
  { name: 'ব্লগ',       seo: true,  private: false, changesPerDay: 0,  freshSeconds: 86400 },
  { name: 'কার্ট',      seo: false, private: true,  manyClicks: false, freshSeconds: 0 },
  { name: 'admin',     seo: false, private: true,  manyClicks: true,  freshSeconds: 0 },
];

for (const p of pages) {
  const [how, why] = choose(p);
  console.log(`${p.name} -> ${how} (${why})`);
}

হোম -> ISR (সবার জন্য এক, তবে দিনে কয়েকবার বদলায়)
পণ্যের পাতা -> ISR (সবার জন্য এক, তবে দিনে কয়েকবার বদলায়)
ব্লগ -> SSG (সবার জন্য এক, কালেভদ্রে বদলায়)
কার্ট -> SSR (মানুষ ধরে আলাদা, ভাগ করা cache-এ রাখা যাবে না)
admin -> CSR (লগইনের পেছনে, crawler লাগে না, ক্লিক অনেক)

১০ · AI-এর যুগে rendering যাচাই

Rendering-এর ভুল বিশেষ করে ধূর্ত, কারণ AI-এর দেওয়া পাতা নিজের ল্যাপটপে ঠিকই চলে। সমস্যা ধরা পড়ে ধীর নেটওয়ার্কে, CDN-এর পেছনে, বা Facebook-এ লিংক দিলে। Framework-এর API-ও দ্রুত বদলায়, তাই AI প্রায়ই পুরোনো সংস্করণের কথা বলে।

AI-এর লেখা পাতা হাতে পেলে

• next build-এর route table দেখেছি; প্রতিটি পাতার চিহ্ন আমার পরিকল্পনার সাথে মিলেছে
• Page Source-এ (DevTools-এর Elements নয়) পণ্যের নাম আর Open Graph tag আছে
• curl -I দিয়ে ব্যক্তিগত পাতার Cache-Control দেখেছি, সেখানে public নেই
• ধীর নেটওয়ার্ক আর CPU throttling চালু করে পাতা চালিয়েছি; বোতাম কখন কাজ শুরু করে দেখেছি
• ব্যবহৃত API আমার version-এর অফিসিয়াল নথিতে মিলিয়েছি, আর diff পড়ে নতুন dependency দেখেছি