SSR, SSG, ISR আর partial prerendering — কখন কোনটি

১ · মানচিত্র থেকে মাঠে: Next.js কীভাবে কৌশল ঠিক করে

পর্ব ০৩-এ আপনি rendering-এর মানচিত্র দেখেছেন। সেখানে প্রশ্ন ছিল দুটি: HTML কোথায় তৈরি হয়, আর কখন। এবার একই প্রশ্ন Next.js-এর ভেতরে, হাতে-কলমে। Routing আর layout পর্ব ৫১-এ, Server Component পর্ব ৫২-এ, আর data fetching ও cache পর্ব ৫৩-এ আলাদা করে আসছে। এই পর্বের কাজ হলো পুরো পাতার কৌশল বেছে নেওয়া।

প্রথম বড় কথা: Next.js-এ আপনি সাধারণত “এই পাতা SSR হবে” বলে কোনো সুইচ টেপেন না। Framework আপনার কোড পড়ে সিদ্ধান্ত নেয়। কোনো component যদি cookies() পড়ে, তাহলে উত্তর নির্ভর করে কে অনুরোধ করছেন তার ওপর, তাই পাতাটি আগে থেকে বানানো যায় না। আর যদি কিছুই অনুরোধের ওপর নির্ভর না করে, Next.js পাতাটি build time-এ বানিয়ে রাখে। এই আগে থেকে বানানোকে বলে prerender.

Next.js 16-এর দুটি মডেল

লেখার সময়ে (নভেম্বর ২০২৬) npm-এ Next.js-এর স্থিতিশীল সংস্করণ 16.4.4. এই সংস্করণে rendering আর cache-এর দুটি মডেল পাশাপাশি আছে, আর পুরোনো টিউটোরিয়াল পড়তে গিয়ে এখানেই সবচেয়ে বেশি গোলমাল হয়:

নিজের প্রজেক্ট কোন মডেলে আছে তা জানতে next.config খুলুন, অথবা next build-এর শুরুর লাইন পড়ুন: Cache Components চালু থাকলে build নিজেই - Cache Components enabled লেখে। এই পর্বে দুটি মডেলই সত্যিকারের build দিয়ে দেখানো হবে, কারণ বাস্তবের অনেক প্রজেক্ট এখনো আগের মডেলে চলে। তাই পর্বের যেখানেই “ডিফল্টে” বলা হয়েছে, সাথে লেখা আছে কোন config-এ: অংশ ২, ৩ আর ৪-এর lab-এ next.config নেই, অর্থাৎ cacheComponents বন্ধ; অংশ ৫-এর lab-এ চালু; অংশ ৭-এর lab-এ শুধু output: 'export'.

এবার একটি পাতা build-এর সময়ে, আর আরেকটি অনুরোধের সময়ে কী করে, তা পাশাপাশি দেখুন। সংখ্যাগুলো আমাদের সত্যিকারের run থেকে, যার পুরো কোড পরের দুই অংশে আছে।

২ · SSG: generateStaticParams দিয়ে build-এ পণ্যের পাতা

“বাজারঘর”-এর পণ্যের পাতার ঠিকানা /products/[id]. বন্ধনীর ভেতরের id একটি dynamic অংশ, তাই Next.js নিজে থেকে জানে না কোন কোন id-র পাতা বানাতে হবে। এই তালিকা দেয় generateStaticParams: build-এর সময় একবার চলা একটি ফাংশন, যা প্রতিটি পাতার params ফেরত দেয়।

আমাদের ছোট lab-এ তিনটি পণ্য আছে, আর ডেটা আসে একটি JSON ফাইল থেকে, যাতে চলতি সার্ভারেও দাম বদলানো যায়। প্রতিটি ডেটা পড়ায় ইচ্ছা করে 50 ms দেরি রাখা হয়েছে, যেন একটি আসল ডেটাবেসের মতো লাগে। ধরা যাক জনপ্রিয় পণ্য মাত্র দুটি, তাই build-এ শুধু সেই দুটি বানাই:

import { notFound } from 'next/navigation';
import { getProduct, getProducts } from '../../../lib/data';

export const revalidate = 10; // শুধু demo-র জন্য ছোট; আসল দোকানে অনেক বড়

export async function generateStaticParams() {
  const all = await getProducts();
  return all.slice(0, 2).map((p) => ({ id: p.id })); // জনপ্রিয় ২টি build-এ
}

export default async function ProductPage({ params }) {
  const { id } = await params;           // Next.js 15 থেকে params একটি Promise
  const p = await getProduct(id);
  if (!p) notFound();                    // না থাকলে সত্যিকারের 404
  return (
    <main>
      <h1>{p.name}</h1>
      <p>price: {p.price} BDT</p>
      <p>generatedAt: {new Date().toISOString()}</p>
    </main>
  );
}

generatedAt লাইনটি শেখার জন্য রাখা, যাতে HTML দেখে বোঝা যায় পাতাটি ঠিক কখন তৈরি হয়েছিল। Next.js 15 থেকে params একটি Promise, তাই await লাগে; পুরোনো টিউটোরিয়ালে params.id সরাসরি পড়া দেখলে বুঝবেন সেটি আগের সংস্করণের। এবার পুরো অ্যাপের build (সত্যিকারের run; Next.js 16.4.4, React 19.3.1, Node 24, আগের মডেল):

~/bazarghar$ npx next build
▲ Next.js 16.4.4 (Turbopack)
…
✓ Generating static pages using 8 workers (8/8) in 519ms
  Finalizing page optimization ...

Route (app)          Revalidate  Expire
┌ ○ /                        1h      1y
├ ○ /_not-found
├ ƒ /api/revalidate
├ ƒ /cart
├   /products/[id]
│ ├ ● /products/1           10s      1y
│ └ ● /products/2           10s      1y
└ ƒ /search

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

তালিকার বাইরের পণ্য এলে কী হয়

ডিফল্টে dynamicParams সত্য, তাই অজানা id-র পাতা প্রথম অনুরোধে তৈরি হয়ে cache-এ যায়। সত্যিকারের run-এ /products/3-এর প্রথম অনুরোধে header ছিল x-nextjs-cache: MISS, পরেরগুলোতে HIT. Header-টির চারটি মান Next.js-এর নথিতে আছে: HIT (cache থেকে), STALE (cache থেকে, পেছনে নতুন তৈরি চলছে), MISS (cache-এ নেই, এখনই render), আর REVALIDATED (on-demand revalidation-এ নতুন করা)।

৩ · Dynamic rendering: কী জিনিস পাতাকে প্রতি অনুরোধে চালায়

Dynamic rendering মানে পাতাটি প্রতি অনুরোধে সার্ভারে তৈরি হয়, অর্থাৎ SSR. আগের মডেলে এটি সাধারণত আপনার বেছে নেওয়া নয়, বরং কোডের ফল। কোনো component যদি এমন তথ্য চায় যা শুধু অনুরোধের মুহূর্তে জানা যায়, তাহলে পুরো route dynamic হয়ে যায়। Next.js-এর নথি এদের বলে request-time বা runtime API:

কার্টের পাতা এমনই। কোড ছোট, কিন্তু একটি লাইন পুরো সিদ্ধান্ত বদলে দেয়:

import { cookies } from 'next/headers';

export default async function Cart() {
  const store = await cookies();   // এই লাইনই route-কে ƒ করে
  const items = Number(store.get('cart_items')?.value ?? 0);
  return <h1>Cart items: {items}</h1>;
}

এবার next start চালিয়ে আসল header দেখি (সত্যিকারের run, curl 8.18):

$ curl -sI http://127.0.0.1:3561/cart
HTTP/1.1 200 OK
Vary: rsc, next-router-state-tree, next-router-prefetch, next-router-segment-prefetch, Accept-Encoding
X-Powered-By: Next.js
Cache-Control: private, no-cache, no-store, max-age=0, must-revalidate
Content-Type: text/html; charset=utf-8
…

৪ · ISR: সময় ধরে আর দরকারমতো নতুন করা

SSG-এর পাতা দ্রুত, কিন্তু দাম বদলালে পুরোনো থেকে যায়। ISR এর মাঝামাঝি পথ: পাতা static থাকে, কিন্তু একটি নির্দিষ্ট সময় পরে প্রথম অনুরোধ এলে পেছনে নতুন করে তৈরি হয়। নীতিটির নাম stale-while-revalidate. Next.js-এর নথির ভাষায়, সময় পেরোনোর পর পরের অনুরোধ “still return the cached (now stale) page”, আর একই সাথে পেছনে নতুন সংস্করণ তৈরি শুরু হয়।

সত্যিকারের run: timestamp ধরে

আমরা /products/1-এ কয়েকবার অনুরোধ করেছি, আর মাঝপথে JSON ফাইলে চালের দাম 450 থেকে 470 করেছি। t হলো এই পরীক্ষা শুরুর পর কত সেকেন্ড; at হলো HTML-এর ভেতরের generatedAt সময় (UTC). পাতাটি এই পরীক্ষার ঠিক আগে 17:35:40-এ তৈরি হয়েছিল:

--- B. ISR timeline ---
  0.0s /products/1    200 HIT         h1=Rice 5kg price=450 at=17:35:40
  1.0s /products/1    200 HIT         h1=Rice 5kg price=450 at=17:35:40
  1.0s    [db] price of 1 set to 470
  3.0s /products/1    200 HIT         h1=Rice 5kg price=450 at=17:35:40
 12.0s /products/1    200 STALE       h1=Rice 5kg price=450 at=17:35:40
 13.0s /products/1    200 HIT         h1=Rice 5kg price=470 at=17:35:53
 13.0s /products/1    200 HIT         h1=Rice 5kg price=470 at=17:35:53

এই run থেকে তিনটি সত্য বেরিয়ে আসে, যা মুখস্থ সংজ্ঞায় প্রায়ই হারায়। প্রথমত, revalidate = 10 মানে “প্রতি 10 s-এ নতুন হবে” নয়; মানে “10 s পরের প্রথম অনুরোধে নতুন করার কাজ শুরু হবে”। কেউ না এলে পাতা যেমন আছে তেমনই থাকে। দ্বিতীয়ত, যিনি নতুন render চালু করলেন, তিনি নিজে পুরোনো পাতা পেলেন। তৃতীয়ত, দাম বদলের পর থেকে ক্রেতা নতুন দাম দেখা পর্যন্ত দেরি সর্বোচ্চ প্রায় window-এর সমান, তারপর আরও একটি অনুরোধ।

নিচের teaching model একই যুক্তি একটি নকল ঘড়িতে চালায়, আর SSG, SSR ও ISR-এ প্রতিটি দর্শক কী দেখেন তা পাশাপাশি দেখায়। এটি Next.js নয়, শুধু নিয়মটির সরল রূপ:

// Teaching model, not Next.js itself. Clock is fake and counted in seconds.
const priceAt = (t) => (t >= 20 ? 470 : 450);   // admin changes the price at t = 20 s
const visits = [5, 30, 61, 62, 125, 126];      // when visitors open /products/1

const strategies = {
  SSG() {                                       // built once, at t = 0
    const built = priceAt(0);
    return () => [built, 'built copy'];
  },
  SSR() {                                       // fresh render on every visit
    return (t) => { this.renders++; return [priceAt(t), 'rendered now']; };
  },
  ISR(win = 60, regenSeconds = 1) {             // revalidate = 60
    let page = { price: priceAt(0), at: 0 }, next = null;
    return (t) => {
      if (next && t >= next.ready) { page = next.page; next = null; }
      if (t - page.at < win) return [page.price, 'HIT'];
      if (!next) { this.renders++; next = { page: { price: priceAt(t), at: t }, ready: t + regenSeconds }; }
      return [page.price, 'STALE, regenerating in background'];
    };
  },
};

for (const [name, make] of Object.entries(strategies)) {
  const ctx = { renders: 1 };                   // the build itself is one render
  if (name === 'SSR') ctx.renders = 0;
  const serve = make.call(ctx);
  console.log(name);
  for (const t of visits) {
    const [price, note] = serve(t);
    const wrong = price !== priceAt(t) ? '  <- old price' : '';
    console.log(`  t=${String(t).padStart(3)}s  shows ${price}  ${note}${wrong}`);
  }
  console.log(`  renders: ${ctx.renders}`);
}

SSG
  t=  5s  shows 450  built copy
  t= 30s  shows 450  built copy  <- old price
  t= 61s  shows 450  built copy  <- old price
  t= 62s  shows 450  built copy  <- old price
  t=125s  shows 450  built copy  <- old price
  t=126s  shows 450  built copy  <- old price
  renders: 1
SSR
  t=  5s  shows 450  rendered now
  t= 30s  shows 470  rendered now
  t= 61s  shows 470  rendered now
  t= 62s  shows 470  rendered now
  t=125s  shows 470  rendered now
  t=126s  shows 470  rendered now
  renders: 6
ISR
  t=  5s  shows 450  HIT
  t= 30s  shows 450  HIT  <- old price
  t= 61s  shows 450  STALE, regenerating in background  <- old price
  t= 62s  shows 470  HIT
  t=125s  shows 470  STALE, regenerating in background
  t=126s  shows 470  HIT
  renders: 3

On-demand revalidation: সময়ের অপেক্ষা না করে

দাম বদলালে admin প্যানেল জানে ঠিক কোন পাতা পুরোনো হলো। তাহলে সময়ের অপেক্ষা কেন? On-demand revalidation-এ কোড থেকে নির্দিষ্ট পাতাকে বাতিল ঘোষণা করা হয়। নিচে একটি route handler, যা admin প্যানেল দাম বদলের পর ডাকবে। Route handler-এর বিস্তারিত পর্ব ৫৭-এ, আর Server Action থেকে একই কাজ পর্ব ৫৪-এ:

import { revalidatePath } from 'next/cache';

// Admin প্যানেল দাম বদলের পর ডাকে। Secret এখানে নকল demo মান।
export async function POST(request) {
  if (request.headers.get('x-revalidate-secret') !== process.env.REVALIDATE_SECRET) {
    return Response.json({ ok: false }, { status: 401 });
  }
  const { id } = await request.json();
  if (!/^\d+$/.test(String(id))) return Response.json({ ok: false }, { status: 400 });
  revalidatePath(`/products/${id}`);
  return Response.json({ ok: true, revalidated: `/products/${id}` });
}

Secret না মেলালে যে কেউ বারবার এই URL ডেকে আপনার সার্ভারকে অকারণ render-এ ব্যস্ত রাখতে পারত। Id-টিও যাচাই করা হয়েছে, যাতে ইচ্ছামতো path পাঠানো না যায়। Secret-টি আসে environment variable থেকে; run-এ মান ছিল example-secret. বাস্তবে আরও নিরাপদ হয় সময়-নিরপেক্ষ তুলনা আর rate limit যোগ করলে, যার তত্ত্ব আছে Cybersecurity-র API security পর্বে। একই সার্ভারে সত্যিকারের run:

--- C. on-demand ---
 13.0s    [db] price of 1 set to 480
 13.1s /products/1    200 HIT         h1=Rice 5kg price=470 at=17:35:53
 13.1s POST wrong secret -> 401 {"ok":false}
 13.1s POST right secret -> 200 {"ok":true,"revalidated":"/products/1"}
 13.1s /products/1    200 MISS        h1=Rice 5kg price=480 at=17:35:55
 13.1s /products/1    200 HIT         h1=Rice 5kg price=480 at=17:35:55

৫ · Partial prerendering: static shell আর dynamic গর্ত

আগের মডেলের সবচেয়ে বড় সীমা: একটি route হয় পুরো static, নয়তো পুরো dynamic. পণ্যের পাতায় নাম, ছবি আর দাম সবার জন্য এক, কিন্তু “স্টকে কতটি আছে” প্রতি মিনিটে বদলায়। শুধু স্টকের জন্য পুরো পাতা dynamic করলে সব ক্রেতাকে প্রতিবার পুরো render-এর দাম দিতে হয়।

Partial prerendering, সংক্ষেপে PPR, এই ভাগ ভাঙে। Build-এর সময় পাতার যতটা পারা যায় তৈরি হয়ে একটি static shell হয়। যে অংশ অনুরোধ ছাড়া বানানো যায় না, তা <Suspense>-এর ভেতরে থাকে; shell-এ যায় শুধু তার fallback, আর আসল অংশ অনুরোধের সময় একই উত্তরের ভেতরে stream হয়ে আসে।

নাম নিয়ে একটু ইতিহাস

PPR প্রথমে পরীক্ষামূলক flag হিসেবে আসে (Next.js 14, ২০২৩ সালের দিকে)। Next.js 15-এ এটি ছিল experimental.ppr. Next.js 16-এ নথি অনুযায়ী cacheComponents স্থিতিশীল হয়, আর PPR তার ডিফল্ট আচরণ হয়ে যায়; পুরোনো experimental.ppr flag আর route-এর experimental_ppr সরিয়ে দেওয়া হয়েছে। অর্থাৎ আজ “PPR চালু করা” মানে cacheComponents: true. লেখার সময়ের নথি এর সাথে partialPrefetching: true-ও স্পষ্ট করে লিখতে বলে; না লিখলে সতর্কবার্তা আসে।

/** @type {import('next').NextConfig} */
const nextConfig = {
  cacheComponents: true,
  partialPrefetching: true,
};

export default nextConfig;

পণ্যের পাতা এবার দুই ভাগে। পণ্যের তথ্য আসে 'use cache' দেওয়া একটি ফাংশন থেকে, যার আয়ু cacheLife('hours'). স্টক আসে একটি ধীর API থেকে, যেখানে ইচ্ছা করে 800 ms দেরি রাখা হয়েছে, আর connection() স্পষ্ট বলে দেয় “এখান থেকে অনুরোধের সময়”:

import { Suspense } from 'react';
import { connection } from 'next/server';
import { getProduct, getStock } from '../../../lib/data'; // getProduct-এ 'use cache'

export async function generateStaticParams() {
  return [{ id: '1' }, { id: '2' }];
}

async function ProductInfo({ params }) {
  const { id } = await params;
  const p = await getProduct(id);          // cache-করা: shell-এর অংশ
  return <h1>{p.name}: {p.price} BDT</h1>;
}

async function Stock({ params }) {
  const { id } = await params;
  await connection();                      // এখান থেকে প্রতি অনুরোধে
  const n = await getStock(id);            // ধীর API: 800 ms
  return <p>In stock: {n} (checked {new Date().toISOString()})</p>;
}

export default function ProductPage({ params }) {
  return (
    <main>
      <Suspense fallback={<h1>Loading product...</h1>}><ProductInfo params={params} /></Suspense>
      <Suspense fallback={<p>Checking stock...</p>}><Stock params={params} /></Suspense>
    </main>
  );
}

লক্ষ করুন, পাতার মূল ফাংশন নিজে params-এর await করে না, Promise-টি নিচে পাঠায়। নথি একে বলে static shell বড় করা: async কাজ গাছের যত গভীরে, তত বেশি অংশ আগে থেকে বানানো যায়। Build output (সত্যিকারের run, একই সংস্করণ):

~/bazarghar-ppr$ npx next build
▲ Next.js 16.4.4 (Turbopack)
✓ Running next.config.mjs took 18ms
- Cache Components enabled
- Partial Prefetching enabled
…
Route (app)
┌ ◐ /
├ ○ /_not-found
├ ◐ /cart
└   /products/[id]
  ├ ◐ /products/[id]
  ├ ◐ /products/1
  └ ◐ /products/2

○  (Static)             prerendered as static content
◐  (Partial Prerender)  prerendered as static HTML with dynamic server-streamed content

তারে কী আসে: chunk ধরে ধরে

একটি ছোট Node script দিয়ে /products/1-এর উত্তরের প্রতিটি টুকরো কখন এল তা মেপেছি। এটি দ্বিতীয় অনুরোধ, সার্ভার গরম হওয়ার পরে (এক local run):

GET /products/1  status 200  headers at     5 ms {"x-nextjs-stale-time":"300","x-nextjs-prerender":"1",
  "x-nextjs-postponed":"1","cache-control":"private, no-cache, no-store, max-age=0, must-revalidate",
  "transfer-encoding":"chunked"}
  chunk 1 at     6 ms    1038 bytes  Rice 5kg | Checking stock...
  chunk 2 at    11 ms    5050 bytes  …
  chunk 3 at    24 ms    4727 bytes  …
  chunk 4 at   824 ms     150 bytes  In stock
  …
  end at   824 ms

প্রথম টুকরোর HTML, script বাদ দিয়ে (সত্যিকারের run, একটু ছেঁটে):

<main><!--$--><h1>Rice 5kg<!-- -->: <!-- -->450<!-- --> BDT</h1><!--/$-->
<!--$?--><template id="B:0"></template><p>Checking stock...</p><!--/$--></main>
…
===== 800 ms পরের টুকরো =====
<div hidden id="S:0"><p>In stock: <!-- -->12<!-- --> (checked <!-- -->2026-11-02T17:37:08.104Z<!-- -->)</p></div><script>…</script>

একই ধারণা ব্রাউজারে নিজে চালিয়ে দেখুন। নিচের ব্লকে সত্যিকারের React 19 চলে। এটি Next.js নয়, সার্ভারও নেই; একটি Promise 800 ms পরে মান দেয়, আর use সেই Promise-এর অপেক্ষা করে। কিন্তু দেখার অভিজ্ঞতা PPR-এর মতোই: shell আগে, গর্ত পরে।

<div id="root"></div>
<script src="../course-kit/vendor/react-lab.js"></script>
<script type="text/jsx">
const t0 = performance.now();
const at = () => Math.round((performance.now() - t0) / 100) * 100 + ' ms';
const stock = new Promise((ok) => setTimeout(() => ok(12), 800)); // ধীর API

function Stock() {
  const n = use(stock);                 // তৈরি না হলে Suspense-এর fallback
  console.log('hole filled at about', at());
  return <p>স্টকে আছে: {n}টি</p>;
}

function ProductPage() {
  console.log('shell drawn at about', at());
  return (
    <main>
      <h1>Rice 5kg: 450 BDT</h1>
      <Suspense fallback={<p>স্টক দেখা হচ্ছে...</p>}>
        <Stock />
      </Suspense>
    </main>
  );
}
createRoot(document.getElementById('root')).render(<ProductPage />);
</script>

shell drawn at about 0 ms
hole filled at about 800 ms

তালিকার বাইরের পণ্য আর App Shell

/products/3 generateStaticParams-এ ছিল না। Cache Components মডেলে প্রথম অনুরোধে সত্যিকারের run-এ প্রথম টুকরোয় এল Loading product..., মানে App Shell; পণ্যের নাম এল 23 ms-এ, একই উত্তরে stream হয়ে। দেড় সেকেন্ড পরের অনুরোধে প্রথম টুকরোতেই Soybean oil: পেছনে পাতাটি “উন্নত” হয়ে cache-এ গেছে। নথি এটিকেই Cache Components-এর ISR বলে, আর জানায় এই App Shell আচরণ Next.js 16.3 থেকে।

৬ · Edge বনাম Node runtime: একটু সাবধানে

“Edge” শব্দটি দুই অর্থে ব্যবহৃত হয়, আর দুটি গুলিয়ে ফেলা খুব সাধারণ। প্রথম অর্থ: CDN-এর edge server, যা ব্যবহারকারীর কাছে ফাইল জমা রাখে। Static পাতা আর static shell এখান থেকে দিলে দূরত্ব কমে। দ্বিতীয় অর্থ: Next.js-এর Edge runtime, একটি হালকা JavaScript পরিবেশ, যেখানে শুধু Web API চলে আর Node.js-এর অনেক module (যেমন fs) নেই।

কয়েক বছর ধরে কথা ছিল: route-কে export const runtime = 'edge' দিলে কোড ব্যবহারকারীর কাছে চলবে, তাই দ্রুত হবে। লেখার সময়ের (16.4) Next.js নথি অবস্থান বদলেছে। নথিতে 'edge' মানটি “deprecated” বলে চিহ্নিত, আর পরামর্শ হলো runtime export মুছে ফেলা, কারণ Node.js-ই ডিফল্ট। Cache Components চালু থাকলে runtime export, এমনকি 'nodejs'-ও, রাখা যাবে না। ISR-ও নথি অনুযায়ী শুধু Node.js runtime-এ চলে।

কেন এই উল্টো যাত্রা, তা নিয়ে community-তে নানা মত আছে, আর ভাবনার প্রশ্ন ৪-এ বিস্তারিত আছে। মূল যুক্তিটি সহজ: পাতার কাজ যদি ডেটাবেস থেকে ডেটা আনা হয়, আর ডেটাবেস থাকে একটি অঞ্চলে, তাহলে কোড ব্যবহারকারীর কাছে চালালে প্রতিটি query-কে সেই দূরত্ব পার হতে হয়। কয়েকটি query হলে মোট সময় বরং বাড়ে। Proxy (আগের middleware) কোথায় চলে, তা পর্ব ৫৭-এর বিষয়।

৭ · Static export: shared hosting-এ সস্তায়

বাংলাদেশে অনেক ছোট ব্যবসা আর ফ্রিল্যান্সার cPanel-ওয়ালা shared hosting ব্যবহার করেন। সেখানে সাধারণত Apache আর PHP চলে, আর লম্বা সময় ধরে Node সার্ভার চালানোর সুবিধা প্রায়ই থাকে না বা সীমিত থাকে (প্রদানকারী ভেদে আলাদা; পর্ব ৮২-তে বিস্তারিত)। এমন জায়গায় Next.js চালানোর পথ হলো static export: build-এর সময় সব পাতা সাধারণ HTML, CSS আর JS ফাইল হয়ে একটি out ফোল্ডারে যায়, যা যেকোনো web সার্ভার দিতে পারে।

/** @type {import('next').NextConfig} */
const nextConfig = {
  output: 'export',
  trailingSlash: true, // /products/1/index.html: Apache-এর জন্য সুবিধাজনক
};

export default nextConfig;

এই প্রজেক্টে পণ্যের পাতায় dynamicParams = false, কারণ export-এ তালিকার বাইরের পাতা পরে বানানোর কোনো সার্ভার নেই। কার্ট এখানে একটি Client Component, যা ব্রাউজারের localStorage থেকে সংখ্যা পড়ে। সত্যিকারের build:

~/bazarghar-export$ npx next build
▲ Next.js 16.4.4 (Turbopack)
…
Route (app)
┌ ○ /
├ ○ /_not-found
├ ○ /cart
└   /products/[id]
  ├ ● /products/1
  ├ ● /products/2
  └ ● /products/3

○  (Static)  prerendered as static content
●  (SSG)     prerendered as static HTML (uses generateStaticParams)

~/bazarghar-export$ find out -type f | grep -v _next | sort
out/404.html
out/404/index.html
out/_not-found/index.html
out/_not-found/index.txt
out/cart/index.html
out/cart/index.txt
out/index.html
out/index.txt
out/products/1/index.html
out/products/1/index.txt
…
~/bazarghar-export$ du -sh out; find out -type f | wc -l
766K	out
44

সীমা: সত্যিকারের build কী বলে

নথিতে যা চলে না তার একটি তালিকা আছে: Server Action, ISR, cookie, rewrite, redirect, header config, proxy, ডিফল্ট image optimization, generateStaticParams ছাড়া dynamic route, আর আরও কিছু। কথাগুলো আমরা নিজে ভেঙে দেখেছি। প্রথমে একটি newsletter form-এ Server Action যোগ করলাম:

~/bazarghar-export$ npx next build
…
  Collecting page data using 7 workers ...

> Server Actions are not supported with static export.
Read more: https://nextjs.org/docs/app/building-your-application/deploying/static-exports#unsupported-features

তারপর একটি অ্যাকাউন্ট পাতায় cookies():

Error occurred prerendering page "/account". Read more: https://nextjs.org/docs/messages/prerender-error
Error: Route /account with `dynamic = "error"` couldn't be rendered statically because it used `cookies()`. …
Export encountered an error on /account/page: /account, exiting the build.

দুটিতেই build থেমে গেছে, যা ভালো: ভুল ধরা পড়ল আপনার মেশিনে, ক্রেতার কাছে নয়। কিন্তু তৃতীয় পরীক্ষাটি বিপজ্জনক। পণ্যের পাতায় export const revalidate = 60 যোগ করে build চালালাম: build সফল, কোনো সতর্কবার্তা নেই, route table-এ Revalidate কলামও নেই। অর্থাৎ ISR চুপচাপ উপেক্ষা হলো। পরের build না হওয়া পর্যন্ত পাতাগুলো চিরকাল একই থাকবে। যিনি ভাবছেন “60 সেকেন্ডে দাম ঠিক হয়ে যাবে”, তিনি ভুল ভাবছেন।

cPanel-এ তোলার পর

trailingSlash: true দিলে প্রতিটি পাতা নিজের ফোল্ডারের index.html, যা Apache কোনো বাড়তি নিয়ম ছাড়াই দেয়। বাকি দুটি কাজ .htaccess-এ করা যায়: নিজের 404 পাতা দেখানো, আর hash-ওয়ালা ফাইলকে লম্বা সময় cache করতে বলা। নিচেরটি উদাহরণ, আমরা চালাইনি; আপনার hosting-এ mod_headers চালু আছে কি না দেখে নিন:

ErrorDocument 404 /404.html

<IfModule mod_headers.c>
  # HTML: প্রতিবার যাচাই, যাতে নতুন upload সঙ্গে সঙ্গে দেখা যায়
  <FilesMatch "\.html$">
    Header set Cache-Control "no-cache"
  </FilesMatch>
  # _next/static-এর ফাইলের নামে hash আছে, তাই এক বছর নিরাপদ
  <If "%{REQUEST_URI} =~ m#^/_next/static/#">
    Header set Cache-Control "public, max-age=31536000, immutable"
  </If>
</IfModule>

৮ · মাপুন: TTFB আর CDN-এর header

কৌশলের তুলনা অনুমানে নয়, মেপে করুন। আমরা প্রতিটি পাতায় curl দিয়ে ২১ বার অনুরোধ পাঠিয়ে time_starttransfer, মানে TTFB, মেপেছি আর median নিয়েছি। কমান্ডটি এমন:

$ curl -s -o /dev/null -w "%{time_starttransfer} %{time_total}\n" http://127.0.0.1:3561/products/1

Header পড়া: CDN কী বুঝবে

$ curl -sI http://127.0.0.1:3561/products/2
HTTP/1.1 200 OK
Vary: rsc, next-router-state-tree, next-router-prefetch, next-router-segment-prefetch, Accept-Encoding
x-nextjs-cache: STALE
x-nextjs-prerender: 1
x-nextjs-prerender: 1
x-nextjs-stale-time: 300
X-Powered-By: Next.js
Cache-Control: s-maxage=10, stale-while-revalidate=31535990
ETag: "ya3s6rk6q14h8"
Content-Type: text/html; charset=utf-8
Content-Length: 5804
…

অর্থাৎ ISR পাতার header আসলে CDN-কেও একই stale-while-revalidate নিয়ম মানতে বলে। CDN সামনে থাকলে বেশিরভাগ অনুরোধ Next.js পর্যন্ত আসেই না। তবে কোনো CDN stale-while-revalidate মানে কি না, আর ডিফল্টে HTML cache করে কি না, তা প্রদানকারী আর সেটিং ভেদে আলাদা; তাই CDN-এর নিজের header (যেমন age বা cache-status ধরনের header) দেখে যাচাই করুন। এর তত্ত্ব Computer Networks-এর caching পর্বে আর System Design-এর CDN পর্বে।

খরচের হিসাব: build বনাম অনুরোধ

কৌশলের খরচ মাপার একটি সরল উপায়: দিনে মোট কতবার পাতা render হয়। নিচের মডেলের সব সংখ্যা ধরে নেওয়া, কোনো আসল দোকানের নয়:

// সব সংখ্যা ধরে নেওয়া (assumed), মাপা নয়। বদলে দেখুন।
const products = 20000;          // পণ্যের পাতা
const viewsPerDay = 500000;      // দিনে মোট পণ্য-পাতা দেখা
const priceChangesPerDay = 300;  // দিনে কতবার কোনো একটি পণ্যের দাম বদলায়
const msPerRender = 40;          // একটি পাতা render করতে CPU সময়

// ISR-এ একটি পাতা দিনে সর্বোচ্চ (86400 / window) বার নতুন হতে পারে,
// আর কখনোই দেখার সংখ্যার বেশি নয়, কারণ নতুন হওয়া শুরু হয় অনুরোধ থেকেই।
const isrMax = (windowSec) => Math.min(viewsPerDay, products * Math.floor(86400 / windowSec));

const plans = [
  ['SSR, প্রতিটি দেখায় render', viewsPerDay],
  ['SSG, প্রতিটি দাম বদলে পুরো build', priceChangesPerDay * products],
  ['ISR, revalidate 60 s (সর্বোচ্চ)', isrMax(60)],
  ['ISR, revalidate 1 h (সর্বোচ্চ)', isrMax(3600)],
  ['ISR, 1 দিন + on-demand', isrMax(86400) + priceChangesPerDay],
];

console.log(`গড়ে প্রতিটি পণ্য দিনে ${viewsPerDay / products} বার দেখা হয়`);
for (const [name, renders] of plans) {
  const cpuHours = (renders * msPerRender) / 3600000;
  console.log(name.padEnd(34), String(renders).padStart(8), 'render',
    cpuHours.toFixed(2).padStart(7), 'CPU-ঘণ্টা');
}

গড়ে প্রতিটি পণ্য দিনে 25 বার দেখা হয়
SSR, প্রতিটি দেখায় render           500000 render    5.56 CPU-ঘণ্টা
SSG, প্রতিটি দাম বদলে পুরো build    6000000 render   66.67 CPU-ঘণ্টা
ISR, revalidate 60 s (সর্বোচ্চ)      500000 render    5.56 CPU-ঘণ্টা
ISR, revalidate 1 h (সর্বোচ্চ)       480000 render    5.33 CPU-ঘণ্টা
ISR, 1 দিন + on-demand                20300 render    0.23 CPU-ঘণ্টা

৯ · “বাজারঘর”: পাতা ধরে সিদ্ধান্ত

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

// একটি পাতার চাহিদা থেকে কৌশল: শেখার ছক, চূড়ান্ত নিয়ম নয়
function choose(p, host) {
  if (host === 'static') {                       // output: 'export', সার্ভার নেই
    if (p.sharedPart || p.liveBit) return 'SSG + বদলানো অংশ ব্রাউজারে, আলাদা API থেকে';
    if (p.personal) return 'CSR: ব্রাউজারে আঁকা, ডেটা আলাদা API থেকে';
    return p.changesPerDay ? 'SSG: বদলালে আবার build ও upload' : 'SSG';
  }
  if (p.personal && !p.sharedPart) return 'Dynamic: প্রতি অনুরোধে, Cache-Control private';
  if (p.sharedPart && p.personal) return 'PPR: সবার shell + ব্যক্তিগত গর্ত';
  if (p.liveBit) return 'PPR: cache-করা পাতা + live গর্ত';
  if (!p.changesPerDay) return 'SSG';
  return 'ISR: লম্বা window + on-demand revalidation';
}

const pages = [
  { name: 'হোম',         sharedPart: true, personal: true, changesPerDay: 6 },
  { name: 'পণ্যের পাতা', liveBit: true, changesPerDay: 12 },
  { name: 'আমাদের কথা',  changesPerDay: 0 },
  { name: 'ব্লগ তালিকা',  changesPerDay: 2 },
  { name: 'কার্ট',        personal: true },
  { name: 'অ্যাকাউন্ট',   personal: true },
  { name: 'admin',       personal: true },
];

for (const host of ['node', 'static']) {
  console.log(`--- hosting: ${host} ---`);
  for (const p of pages) console.log(`${p.name}: ${choose(p, host)}`);
}

--- hosting: node ---
হোম: PPR: সবার shell + ব্যক্তিগত গর্ত
পণ্যের পাতা: PPR: cache-করা পাতা + live গর্ত
আমাদের কথা: SSG
ব্লগ তালিকা: ISR: লম্বা window + on-demand revalidation
কার্ট: Dynamic: প্রতি অনুরোধে, Cache-Control private
অ্যাকাউন্ট: Dynamic: প্রতি অনুরোধে, Cache-Control private
admin: Dynamic: প্রতি অনুরোধে, Cache-Control private
--- hosting: static ---
হোম: SSG + বদলানো অংশ ব্রাউজারে, আলাদা API থেকে
পণ্যের পাতা: SSG + বদলানো অংশ ব্রাউজারে, আলাদা API থেকে
আমাদের কথা: SSG
ব্লগ তালিকা: SSG: বদলালে আবার build ও upload
কার্ট: CSR: ব্রাউজারে আঁকা, ডেটা আলাদা API থেকে
অ্যাকাউন্ট: CSR: ব্রাউজারে আঁকা, ডেটা আলাদা API থেকে
admin: CSR: ব্রাউজারে আঁকা, ডেটা আলাদা API থেকে

১০ · AI-এর যুগে rendering কৌশল যাচাই

Next.js-এর rendering আর cache-এর API গত কয়েক বছরে যত দ্রুত বদলেছে, ওয়েবের অন্য খুব কম জায়গায় তা হয়েছে। AI-এর প্রশিক্ষণের ডেটায় সব সংস্করণের কোড মিশে আছে, তাই সে প্রায়ই তিন বছর আগের API আর আজকের API একই ফাইলে মিশিয়ে দেয়। কোড চলেও যেতে পারে, কিন্তু কৌশল হবে আপনার ভাবনার উল্টো।

AI-এর লেখা rendering কোড হাতে পেলে

• next build চালিয়ে route table পড়েছি; প্রতিটি পাতার চিহ্ন (○ ● ƒ ◐) আমার পরিকল্পনার সাথে মিলেছে
• ব্যবহৃত প্রতিটি API (revalidateTag, cacheLife, connection) আমার সংস্করণের অফিসিয়াল নথিতে মিলিয়েছি
• next start-এ curl -sI দিয়ে প্রতিটি ব্যক্তিগত পাতার Cache-Control দেখেছি; সেখানে public বা s-maxage নেই
• দাম বদলে নিজে ISR-এর ক্রম দেখেছি: HIT, STALE, তারপর নতুন দাম
• Revalidate route-এ secret আর ইনপুট যাচাই আছে; secret কোডে বা client bundle-এ লেখা নেই
• Diff পড়ে নতুন dependency বা লুকানো try/catch খুঁজেছি, যা ভুল চেপে রাখে