Next.js 16 সেই রিলিজ, যেখানে ফ্রেমওয়ার্কটি শেষ পর্যন্ত স্বীকার করে নিল যে তার ক্যাশিং বিভ্রান্তিকর ছিল — আর সে ব্যাপারে কিছু একটা করল।

শিরোনাম এটাই। Turbopack স্থিতিশীল হওয়া আর middleware.ts-এর নাম বদলানো — এই দুটি পরিবর্তনই আপনি আগে টের পাবেন, কিন্তু ক্যাশিং মডেলটিই আপনার কোড লেখার ধরন বদলে দেয়।

আমরা এই সাইটটি Next 16-এ চালাই, তাই নিচের কথাগুলো রিলিজ নোটের পুনরাবৃত্তি নয় — বাস্তবে যা গুরুত্বপূর্ণ হয়ে দাঁড়িয়েছিল, তাই।

Cache Components: গুরুত্বপূর্ণটি

কয়েকটি ভার্সন ধরে Next.js-এর ক্যাশিং ছিল অনুক্ত। কোনো fetch ক্যাশ হবে কি না তা নির্ভর করত আপনি কী অপশন দিয়েছেন, কোনো ডায়নামিক এপিআই ব্যবহার করেছেন কি না, আর কোন ভার্সনে আছেন তার ওপর। ডিফল্টগুলো রিলিজে রিলিজে বদলাত। "প্রোডাকশনে এই পেজ পুরোনো দেখাচ্ছে অথচ লোকালে ঠিক আছে কেন" — এই প্রশ্নের একক বৃহত্তম উৎস ছিল এটাই।

Next 16-এর উত্তর হলো এটিকে স্পষ্ট করে দেওয়া। কী ক্যাশ হবে তা আপনি একটি ডিরেক্টিভ দিয়ে চিহ্নিত করেন:

ts
async function getArticles(topic: string) {
  'use cache'
  const res = await fetch(`https://api.example.com/articles?topic=${topic}`)
  return res.json()
}

যা চিহ্নিত নয়, তা ডায়নামিক। মানসিক মডেলটা এটুকুই, আর এটি বড় একটি উন্নতি: কোথায় কোন ডিফল্ট খাটে তা মুখস্থ রাখার বদলে আপনি কোড পড়েন, আর উত্তরটা সেখানেই লেখা থাকে।

এর সঙ্গে জোড়া লাগে Partial Prerendering, যা একটি পেজকে আংশিক স্ট্যাটিক আর আংশিক ডায়নামিক হতে দেয়। স্ট্যাটিক খোলসটি — লেআউট, নেভিগেশন, শিরোনাম — এজ থেকে সঙ্গে সঙ্গে পরিবেশিত হয়, আর ব্যক্তিগত অংশগুলো ধীরে ধীরে এসে বসে। আগে পেজের যেকোনো জায়গায় একটিমাত্র ডায়নামিক কল গোটা পেজটিকেই ডায়নামিক করে দিত — এ কারণেই স্ট্যাটিক হওয়ার যোগ্য এত মার্কেটিং সাইট প্রতিটি রিকোয়েস্টে রেন্ডার হতো।

এখনই এটি গ্রহণ করবেন? নতুন প্রকল্প শুরু করলে হ্যাঁ। চালু অ্যাপ থাকলে Cache Components না নিয়েও ১৬-তে আপগ্রেড করতে পারেন, আর পরে ভেবেচিন্তে সরে আসতে পারেন।

Turbopack এখন ডিফল্ট

Turbopack স্থিতিশীল, আর next dev ও next build — দুটিরই ডিফল্ট বান্ডলার। Vercel জানাচ্ছে Fast Refresh ৫–১০ গুণ দ্রুত আর বিল্ড ৫ গুণ পর্যন্ত দ্রুত।

দৈনন্দিন ব্যবহারে ডেভ সার্ভারের পার্থক্যটাই চোখে পড়ে — ফাইল সেভ করা আর পরিবর্তন দেখতে পাওয়ার মাঝের ফাঁকেই কাজের দিনটা চুপচাপ খরচ হয়। বড় অ্যাপে কোল্ড স্টার্ট উল্লেখযোগ্যভাবে ভালো হয়।

দুটি বাস্তব সতর্কতা:

  • কাস্টম webpack কনফিগ সঙ্গে যায় না। নিজস্ব webpack ব্যবস্থা থাকলে সেটিই আপনার আপগ্রেডের কাজ। বেশিরভাগ অ্যাপেরই নেই।
  • কিছু ইকোসিস্টেম প্লাগইন পিছিয়ে আছে। কাজ করবে ধরে নেওয়ার আগে বিল্ড পাইপলাইনের অস্বাভাবিক কিছু থাকলে যাচাই করুন।

middleware.ts এখন proxy.ts

একটি নাম পরিবর্তন, আর সেটি স্পষ্টতা আনে। ফাইলটি প্রায় সর্বজনীনভাবে প্রমাণীকরণের জন্য ব্যবহৃত হতো, যা থেকে মানুষ ধরে নিতেন এটি Express middleware-এর মতো অ্যাপ্লিকেশন লজিকের সামনে প্রতি রিকোয়েস্টে চলে। তা চলে না — এটি চলে নেটওয়ার্ক এজে একটি প্রক্সি হিসেবে, ক্যাশের আগে।

এই পার্থক্যটা বরাবরই গুরুত্বপূর্ণ ছিল আর পুরোনো নামটি সক্রিয়ভাবে সেটি আড়াল করত। এর ভেতরের কোড ক্যাশিংয়ের আগে চলে, তাই সেটিকে দ্রুত হতে হবে, সেখানে আপনার পূর্ণ রানটাইমে প্রবেশাধিকার নেই — আর সেখানে ডেটাবেস কল বসানো এমন একটি ভুল, যা নামটিই উৎসাহ দিত।

মাইগ্রেশন যান্ত্রিক: ফাইলের নাম বদলান, এক্সপোর্ট করা ফাংশন আর matcher কনফিগ একই রাখুন। পনেরো মিনিট ধরে রাখুন, গোটা বিকেল নয়।

আপগ্রেডে আসলে কী ভাঙে

নিজে করার অভিজ্ঞতা থেকে, কোনটায় কত সময় যায় মোটামুটি সেই ক্রমে:

১. অ্যাসিঙ্ক params ও searchParams। Next 15-এ এগুলো Promise হয়ে গেছে, আর কোডমড প্রতিটি ক্ষেত্র ধরতে পারে না — বিশেষত generateMetadata-তে:

ts
export default async function Page({ params }: { params: Promise<{ slug: string }> }) {
  const { slug } = await params
}

২. Node ভার্সন। Next 16-এর জন্য হালনাগাদ Node লাগে। নিজের মেশিন সব ঠিক আছে বলার আগে ডিপ্লয় টার্গেটটি দেখে নিন।

৩. webpack কনফিগ, যদি থাকে। ওপরে দেখুন।

৪. ডিপেনডেন্সির peer রেঞ্জ। React 19.2 আর React ভার্সন পিন করে এমন যেকোনো কিছু। কোনো ইনস্টলে একই জিনিসের দুটি কপি রিজলভ হওয়ার সাধারণ উৎস এটাই।

⚠ মনোরিপোজুড়ে ফ্রেমওয়ার্কের ভার্সন হুবহু এক রাখুন। আমরা এটি দামি অভিজ্ঞতায় শিখেছি: রুট প্যাকেজে ছিল ^16.3.1 আর প্রতিটি সাইটে ^16.2.9, যাতে একই ট্রিতে Next-এর দুটি কপি রিজলভ হয়েছিল। লক্ষণটা ভার্সন সতর্কবার্তা ছিল না — ছিল next.config.ts-এর ভেতরে একটি টাইপ এরর, কারণ কাঠামোগতভাবে আলাদা দুটি NextConfig টাইপ একসঙ্গে ছিল। ওয়ার্কস্পেস চালালে রেঞ্জগুলো মিলিয়ে নিন, আর প্রতিটি প্যাকেজের ভেতর থেকে node -e "console.log(require('next/package.json').version)" চালিয়ে যাচাই করুন।

আপগ্রেড করবেন কি?

হ্যাঁ, মোটামুটি দ্রুত, যদি:

  • নতুন কিছু শুরু করছেন। ১৬ দিয়েই শুরু করুন।
  • বিল্ডের সময় বা ডেভ ফিডব্যাক লুপ কষ্ট দিচ্ছে। কেবল Turbopack-ই এটির যৌক্তিকতা দেয়।
  • ক্যাশিং বাগের সঙ্গে লড়ছেন। এই রিলিজটাই সমাধান।
  • আপনি ১৫-তে আছেন আর ডিপেনডেন্সি হালনাগাদ। ফাঁকটা ছোট।

অপেক্ষা করুন, যদি:

  • ভারী কাস্টম webpack কনফিগারেশন আছে আর সেটির জন্য সময় বরাদ্দ নেই।
  • Turbopack সমর্থন নেই এমন কোনো বিল্ড-পাইপলাইন প্লাগইনের ওপর নির্ভরশীল।
  • দুই বা তার বেশি মেজর ভার্সন পিছিয়ে আছেন। ১৪ → ১৫ → ১৬ যান, মাঝে পরীক্ষা করে। মেজর ভার্সন লাফিয়ে যাওয়াই আপগ্রেডকে সপ্তাহে পরিণত করে।
  • কোড ফ্রিজে আছেন। এটি নিরাপত্তা রিলিজ নয়।

একটি বাস্তব আপগ্রেড চেকলিস্ট

  1. ব্রাঞ্চ করুন। স্পষ্ট কথা, তবু main-এ আপগ্রেড করা মানুষের সংখ্যা শূন্য নয়।
  2. আগে Node। লোকালে আর ডিপ্লয় টার্গেটে হালনাগাদ করুন, আর টার্গেটটি সত্যিই সেটি সমর্থন করে কি না দেখুন।
  3. কোডমড চালান। npx @next/codemod@canary upgrade latest যান্ত্রিক কাজের বেশিরভাগ সামলায়।
  4. middleware.ts → proxy.ts নাম বদলান।
  5. কিছু চালানোর আগে টাইপ-চেক করুন। ক্লিক করে ঘোরার চেয়ে tsc --noEmit অ্যাসিঙ্ক params-এর ক্ষেত্রগুলো দ্রুত খুঁজে দেয়।
  6. কেবল dev নয়, build করুন। প্রোডাকশন বিল্ড এমন জিনিস ধরে যা dev ধরে না — বিশেষত প্রি-রেন্ডারিং এরর।
  7. সত্যিকারের রুটগুলো ঘুরে দেখুন। ডায়নামিক রুট, মেটাডেটা, সাইটম্যাপ, robots, ছবি, ফর্ম।
  8. তারপর, আলাদাভাবে, Cache Components নিন। একই পুল রিকোয়েস্টে নয়। আপগ্রেড আর গ্রহণ দুটি আলাদা পরিবর্তন, আর এরা আলাদাভাবে ব্যর্থ হয়।

পারফরম্যান্সের জন্য এর মানে কী

বাস্তব লাভটা নিছক রেন্ডারিংয়ের গতি নয়, আপনার পেজের কতটা স্ট্যাটিক হতে পারে সেটি।

Partial Prerendering মানে একটিমাত্র ব্যক্তিগত উপাদান আর গোটা পেজকে প্রতি রিকোয়েস্টে রেন্ডার করতে বাধ্য করে না। যে প্রোডাক্ট পেজের একমাত্র ডায়নামিক অংশ একটি স্টক ইন্ডিকেটর, সেটি তার খোলস সঙ্গে সঙ্গে পাঠিয়ে বাকিটা স্ট্রিম করতে পারে — যা সরাসরি LCP-তে, আর তাই Core Web Vitals-এ দেখা যায়।

কনটেন্ট সাইটে এর প্রভাব বড় হতে পারে। শুরু থেকে শেষ পর্যন্ত ডায়নামিক অ্যাপে সামান্য। কাউকে সংখ্যা প্রতিশ্রুতি দেওয়ার আগে মেপে নিন, আর নিজে না করে হাতে তুলে দিতে চাইলে আমরা এই কাজটাই করি।

এখনো Pages Router-এ থাকলে

Pages Router এখনো চলে আর এখনো সমর্থিত। কিন্তু এখানে আলোচিত প্রতিটি ফিচার — Cache Components, Partial Prerendering, Server Components — কেবল App Router-এ, আর প্রতিটি রিলিজে ব্যবধান বাড়ছে।

একবারেই সব সরাতে হবে না; একটি অ্যাপ্লিকেশনেই দুটি রাউটার পাশাপাশি চলে। নতুন রুটগুলো App Router-এ নিন, বাকিগুলো যখন হাত দেবেন তখন সরান — আর এটি এক ত্রৈমাসিকে নয়, এক বছরে হতে দিন।

কিছু না ভেঙে Cache Components গ্রহণ করা

১৬-তে গিয়ে স্থিতিশীল হওয়ার পর এই অংশটাই ঠিকভাবে করার মতো। ভুলটা হলো এটিকে খুঁজে-বদলে দেওয়ার কাজ ভাবা।

পাতা নয়, পাতার ডগা থেকে শুরু করুন। গোটা রুট সেগমেন্ট নয়, আলাদা আলাদা ডেটা ফাংশন চিহ্নিত করুন — যেটি আর্টিকেল আনে, যেটি সেটিং পড়ে। ভুলভাবে ক্যাশ করা পাতা সবাইকে বাসি কনটেন্ট দেয়; ভুলভাবে ক্যাশ করা ফাংশন নিয়ে ভাবা আর ফিরিয়ে আনা — দুটোই সহজ।

ক্যাশ করা ফাংশন কী কী ধরে রাখতে পারে তা জানুন। 'use cache'-এর ভেতরের কিছুই রিকোয়েস্ট-নির্দিষ্ট অবস্থার ওপর নির্ভর করতে পারবে না — কুকি, হেডার, বর্তমান ব্যবহারকারী। করলে আপনি এক ভিজিটরের ডেটা আরেকজনকে দেখাবেন, আর ডেভেলপমেন্টে সেটি নিখুঁতভাবে চলবে, যেখানে ভিজিটর একজন। ব্যর্থতার এই চেহারাটি নিয়েই সত্যিকারের সতর্ক থাকা দরকার।

মেয়াদ ভেবেচিন্তে বসান। মেয়াদহীন ক্যাশ করা ফাংশন মানে স্থায়ী ক্যাশ। কোনটি কতটা বাসি হতে পারে ঠিক করুন — প্রোডাক্ট তালিকা, পাঁচ মিনিট; আইনি পাতা, একদিন; নেভিগেশন মেনু, বদলানো পর্যন্ত — আর সেটি লিখে দিন।

কিছু ক্যাশ করার আগেই ইনভ্যালিডেশনের পথ রাখুন। ক্যাশে ট্যাগ দিন আর অন্তর্নিহিত ডেটা বদলালে সেগুলো নতুন করে যাচাই করান। ইনভ্যালিডেশন ছাড়া ক্যাশিংয়ের কারণেই একটি সিএমএস সম্পাদনা দেখাতে এক ঘণ্টা লাগে আর কেউ সেটি ঠিক করতে নতুন করে ডিপ্লয় করে।

প্রোডাকশন বিল্ড দিয়ে যাচাই করুন। next dev প্রোডাকশনের মতো ক্যাশ করে না। ক্যাশিংয়ের যে পরিবর্তন কেবল ডেভেলপমেন্টে দেখেছেন, সেটি পরীক্ষা করা হয়নি।

যে ক্রমটি কাজ করে: আপগ্রেড করুন, ছাড়ুন, এক সপ্তাহ অপেক্ষা করুন, তারপর একবারে একটি ফাংশন ক্যাশ করুন — সঙ্গে প্রতিটি সত্যিই কাজে দিল কি না মাপার উপায় রাখুন। দুটো একসঙ্গে করলে কিছু বাসি হলে বুঝবেন না কোন পরিবর্তনটি তার কারণ।

যা বদলায়নি, আর মনে রাখার মতো

আপগ্রেড নিয়ে লেখা পড়লে মনে হয় সবকিছুই বদলে গেছে। বেশিরভাগই বদলায়নি, আর সেটা জানলে কাজটা ছোট হয়ে আসে।

আপনার রাউটিংয়ে হাত পড়েনি। ফাইল-ভিত্তিক রুট, ডায়নামিক সেগমেন্ট, লেআউট, লোডিং ও এরর বাউন্ডারি — সবই হুবহু এক। ১৫-তে App Router-এ সড়গড় থাকলে ১৬-তেও সড়গড়।

Server Components আর Server Actions অপরিবর্তিত। Cache Components এদের ওপরে নয়, পাশে বসে। React Server Components-এর সবকিছু আগের মতোই প্রযোজ্য।

ছবি, ফন্ট আর মেটাডেটার এপিআই একই। next/image, next/font, generateMetadata, sitemap.ts, robots.ts — কোনো পরিবর্তন নেই, কেবল robots.ts-কে এখনো রুট গ্রুপের ভেতরে নয়, app/-এর রুটে থাকতে হয় — যা এই রিলিজের অনেক আগে থেকেই মানুষকে ভোগাচ্ছে।

ডিপ্লয়মেন্ট অপরিবর্তিত। ১৫-তে যা দিয়ে আপনার অ্যাপ বিল্ড ও পরিবেশিত হতো, ১৬-তেও তা-ই হবে।

তাই এই আপগ্রেডের সৎ পরিসরটি হলো: একটি ফাইলের নাম বদলান, কোডমড যে অ্যাসিঙ্ক params ধরেনি সেগুলো ঠিক করুন, Node ভার্সন দেখুন, আর — কেবল যদি থাকে — কাস্টম webpack কনফিগ সামলান। বেশিরভাগ আপগ্রেড সত্যিই এটুকুই। যে পরিবর্তনটি বড় শোনায়, Cache Components, সেটি ঐচ্ছিক আর আপগ্রেডটি এক সপ্তাহ স্থিতিশীল থাকা পর্যন্ত অপেক্ষা করতে পারে।

সচরাচর জিজ্ঞাসা

Next.js 16-এর সবচেয়ে বড় পরিবর্তন কী? Cache Components। ক্যাশিং এখন স্পষ্ট — কী ক্যাশ হবে তা 'use cache' ডিরেক্টিভ দিয়ে চিহ্নিত করেন, বাকি সব ডায়নামিক। এটি সেই মডেলের জায়গা নিল, যেখানে ডিফল্টগুলো অনুক্ত ছিল আর ভার্সনে ভার্সনে বদলাত।

Turbopack কি প্রোডাকশনের জন্য প্রস্তুত? হ্যাঁ, এটি স্থিতিশীল আর Next 16-এ dev ও build দুটিরই ডিফল্ট। প্রধান ঝুঁকি কাস্টম webpack কনফিগারেশন, যা সঙ্গে যায় না।

middleware.ts-এর নাম কি বদলাতেই হবে? হ্যাঁ, proxy.ts-এ। এটি যান্ত্রিক নাম পরিবর্তন — এক্সপোর্ট করা ফাংশন আর matcher কনফিগ একই থাকে। নতুন নামটি বোঝায় যে কোডটি অ্যাপ্লিকেশন middleware হিসেবে নয়, ক্যাশের আগে এজ প্রক্সি হিসেবে চলে।

Next.js 16 কি আমার অ্যাপ ভেঙে দেবে? সাধারণ ভাঙনগুলো হলো অ্যাসিঙ্ক params/searchParams, Node ভার্সনের শর্ত, আর কাস্টম webpack কনফিগ। অফিশিয়াল কোডমড চালান, টাইপ-চেক করুন, আর কেবল next dev নয়, প্রোডাকশন বিল্ড করুন।

১৪ থেকে সরাসরি ১৬-তে যাওয়া উচিত? মাঝে ১৫ হয়ে যান, দুই ধাপে পরীক্ষা করে। মেজর ভার্সন লাফিয়ে গেলে একসঙ্গে দুই সেট ব্রেকিং চেঞ্জ ডিবাগ করতে হয়, আর সেটাই এক বিকেল আর এক পক্ষকালের পার্থক্য।

Next.js 16-এ কি App Router বাধ্যতামূলক? না, Pages Router এখনো সমর্থিত। তবে Cache Components, Partial Prerendering আর Server Components কেবল App Router-এ, তাই Pages-এ থেকে যাওয়া মানে এই রিলিজের বেশিরভাগ সুবিধা থেকে সরে থাকা।